Dynamic IP & cache DNS

Kevin Darcy kcd at daimlerchrysler.com
Mon Sep 10 23:31:12 UTC 2001


Cricket Liu wrote:

> > Unfortunately, gratuitously-low TTLs are detrimental to the public
> > DNS infrastructure. If a node is going to have a particular IP address
> > continuously for, say, 24 hours, why force other nameservers to re-lookup
> the
> > name as often as every 60 seconds? In a more perfect world, of course, a
> > dynamic client would set the TTL to *exactly* as long as it was going to
> have
> > the IP address, no more, no less. This is, of course assuming that it
> knows
> > exactly how long it is going to have that address, that nothing breaks,
> etc.
> > etc. In short, it's unrealistic.
>
> Well, I suppose gratuitously low TTLs are *unnecessary*, but why are
> they detrimental to the public DNS infrastructure?  If I made the TTL
> on www.nxdomain.com's A RR five seconds, your name server might
> query my name server as often as every five seconds, but what effect
> does that have on any other name servers?  Or are you counting every
> name server that might query mine as "the public DNS infrastructure"?

I meant it in the Kantian sense, i.e. if adopted as a general practice (as it
increasingly seems to be). The fundamental DNS design usage-assumption that
"Most of the data in the system will change very slowly" (RFC 1034) seems to
be straining at the seams these days...

FWIW, the A records for www.microsoft.com and www.yahoo.com and www.google.com
have a 5-minute TTL. Even www.msn.com and www.aol.com have a 1-hour TTL.
www.amazon.com has a 1-minute TTL. www.4adodge.com (which is on a Cisco load
balancer) has a 15-minute TTL (this was recently a 0-second TTL, but we raised
it because DNS was becoming a performance bottleneck for some clients).
A 1-day TTL used to be somewhat standard, but now just about everyone sets an
hour or less on anything they care about. We're just as guilty of this as
anyone -- I typically set a 1-hour TTL on our external zones because change
requests from our Web Group tend to be both unpredictable and urgent. I've
even been getting complaints about that setting, that one hour is too long to
wait for a change to propagate. There is a lot of pressure to reduce TTLs. Web
developers and admins want DNS changes to be reflected *immediately*, or as
close to it as possible. So TTL values plummet, and the query volume and the
loads on nameservers keeps going up and up and up. I'm just trying to think of
a way of getting the best of both worlds, i.e. dynamism without so much wasted
resources.


- Kevin





More information about the bind-users mailing list