nscd and DNS cache

Greg Woods woods at ucar.edu
Wed May 16 16:20:44 UTC 2012


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




More information about the users mailing list