Domain name records include a TTL (Time To Live) value, which allows the domain publisher to give hints about how frequently domain data may change. It's common to set this value to several hours normally, but to push it down 5 minutes when changes to DNS are expected. The longer TTL means faster resolution times because of caching, but also means the data may be stale for longer.

However, it's common knowledge that places like AOL ignore this TTL value and instead force TTLs to be fairly large values such as 1 week. As with much common knowledge, however, this seems to largely be an urban legend...

I've never been able to figure out why someone would force a week minimum TTL. While I don't agree with it, I could see why you might override the hint and force the TTL to be minutes or even hours. However, requiring it to take up to 7 days for a change in DNS to be noticed by your clients I don't see any legitimate reason for. And in practice I haven't seen this to be widespread. I'd be inclined to say that an ISP which does this is intentionally providing broken service to their clients.

I mean, the recommendations in RFC2308 (negative TTL) is to use a TTL value of 1 to 3 hours. STD13 recommends a value "on the order of days" unless a change is imminent in which case it should be pushed down. I personally feel that having a TTL that allows DNS changes to propagate within the same business day offers a good balance between caching and responsiveness.

For our own zone, I typically set the TTL to 4 hours, and push it down to 5 minutes when I expect to move something around.

So, an ISP pushing the minimum TTL to 1 week is at best making the minimum be at the upper bounds of where a normal TTL should be, and well beyond what one would need to see if making a DNS change (say, moving to a new server).

While the problem of ISPs pinning the TTL is probably an urban legend (and a resource I'll link to below claims to have specifically researched whether AOL does it and found they do not), there is another problem that is much more real. Client side resolver implementations and applications may not properly pick up updates to a name...

In particular, there may be buggy applications that do not do name resolution as frequently as they should. Client resolvers may also have issues where they don't properly expire their cached values, or explicitly override the minimum TTL. One particular implementation is nscd (the Name Service Cache Daemon0, which may default to 1 hour as the minimum TTL.

Evelyn found this reference to a great thread on the NANOG mailing list about this exact topic. This includes the reference that AOL does not do such caching, but references some CPE devices and nscd which push this limit way up.

Evelyn also found a fairly dated (2003) PDF report on an investigation of response to changes made with respect to honoring the TTL.

That said, it's probably a good practice, when possible, to set up either a redirect on an old server, or a proxy from the old server to the new, if moving servers around.
(Post Reply)