On 05/17/2012 10:49 PM, Ed Greshko wrote:
On 05/18/2012 01:35 PM, Ed Greshko wrote:
There should not be a configuration for that. If there is, then dnsmasq would be
going against the recommendations of the DNS RFCs. The response to a DNS request
includes a TTL (Time To Live). According to the RFC.... TTL which is the time to
live of the RR. This field is a 32 bit integer in units of seconds, an is primarily
used by resolvers when they cache RRs. The TTL describes how long a RR can be
cached before it should be discarded. So, dnsmasq is dropping the records from its
cache according to when the owner of the record wants it. This is how the DNS
system is supposed to work.
And, FWIW, the definition for "should" with regards to RFCs is....
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
So, what's to prevent someone from simply modifying dnsmasq
(or any other open source caching name resolver) to change
the expiration time to a value greater than what the owner
of the domain wants? Sure it may result in using stale
ip addresses once in a while. I think that's more tolerable than
having to wait anywhere from 10 to 30 seconds to resolve every
new name browsed to; (new relative to contents of the cache).
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org