On Wed, 2012-05-16 at 09:47 -0600, JD wrote: > On 05/16/2012 03:33 AM, Ed Greshko wrote: > I've seen cases where the > TTL has been set to as low as 300 seconds. > Interesting point. Hard to believe that most domain controllers would that. > Must be a small percentage? As a DNS administrator, I can say that there are a lot of things that go into determining a good setting for the TTL. There is a default TTL for the entire zone, and you can also set the TTL on individual records. As we all presumably know, the DNS is a caching system. This was originally done to lower the amount of DNS traffic on the net. But the drawback to having your data cached all over the net is that it is hard to change it. And sometimes DNS data does need to change, so it is fairly common practice to lower the TTL to values like 300 seconds (5 minutes) when you know that a given record is going to be changed, and you need the change to propagate quickly (e.g. the IP address of your web site, which is a real-life example from my workplace recently). There are also domains that set a very low TTL for their entire zone. Sometimes this is justified; consider something like dyndns.org, which exists specifically to resolve addresses that can change unexpectedly (e.g. gregandeva.dyndns.org points to my home firewall/router, and it can change whenever the Comcast DHCP server feels like changing it, and does change pretty much every time the router is rebooted, which also happens every time I change certain settings; it would be a royal pain if my IP address could not always be accurately resolved). dyndns.org sets the TTL so low that caching is effectively disabled for any records in their domain, but customers subscribe to their service because this is exactly what they want. Sometimes also domain administrators who don't really understand the purpose of caching or how it works will lower the TTL for their entire domain just so that the occasional change they need to make will always propagate quickly. I don't recommend that because it more-or-less defeats the purpose of having caching in DNS servers in the first place. It is no substitute for a little advance planning (as I have told sysadmins at work who fail to think about this ahead of time and are now upset because a change they need to make is not going to propagate for a day or two). As a (possibly) interesting aside: in the early days of NSFnet, which is when the IP net as it existed expanded from government and defense contractors only (the old ARPAnet) to include universities and research institutions (but before the Internet became what it is now where nearly everybody in the world is on it), there was a traffic study done, and it showed that 60% of the packets on the net were DNS queries or responses. This was before DNS servers would cache non-authoritative data. That's probably what we would have now were it not for DNS caching. --Greg -- 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
