28

Some years ago I had to do several DNS changes over the course of several weeks as I moved bits of equipment from one data center to the other. At the time that I did this, about 95% of the nameservers in the world seemed to respect the TTL value, and about 5% ignored ours and made up their own. In other words, 95% of the traffic moved within the 15-minute TTL that we defined. Another 3% made it in the first hour, 1% in the first day, and a few stragglers took up to three days.

(Yes, OK, I'm confusing percentage of traffic with percentage of nameservers. Please insert handwaving.)

This was in about 2001, though, and we were using dinosaurs to transmit packets through the tubes. My guess is that today's nameservers are better-behaved, and there will be less of a problem with stragglers. Does anyone have a feel for what percentage of traffic will switch within the defined TTL these days? Are there still many nameservers out there that ignore TTL?

  • 4
    I have no idea, but my gut feeling is that today it will be even worse then in the past. – Zoredache Oct 8 '09 at 0:19
  • I would've loved to have them all done in 3 days! I did a major change about that time (might've been 2002), and after two weeks, we finally realized that 1/3 of the root name servers were looking at a couple of development DNS servers that one of the other sysadmins had exposed to the outside world. (I still have no idea how the root servers knew about them). – Joe H. Oct 8 '09 at 19:12
  • Something to consider in this is: It isn't just edge DNS recursors that cache records. Sometimes people chain recursors and this adds time. Also, some operating systems cache records. Some browsers also cache records. Java and other apps cache DNS as well. This can easily turn a 15 min TTL into 60+ minutes. – Aaron Jul 5 '17 at 21:58
15

We moved recently and had all sorts of problems with DNS.

When we did the swing over most customers started hitting the new IPs right away. But some were still hitting the old IPs for weeks. We left a server up for a month or so. Eventually we went through the IIS logs on the old machine and called the customers telling them to flush DNS on there company or ISP DNS servers. That got the last of them moved over.

It was a small number of people that kept with the old IPs. Out of 20k customers, maybe 50 had issues after the first day.

  • 1
    Thanks! That's about what I expected. A quarter of a percent isn't too bad for some types of traffic, though it's certainly very bad for others. – user10501 Oct 8 '09 at 19:05
  • 1
    A more recent estimate: 13 hours into a DNS servers change, a total of 17/500 (3.4%) of customers contacted us because they were still being served the old site instead of the new one. WhatsMyDNS comes in handy to check the status of the propagation (in our case, 4/140 = 2.85% of servers in their sample are still using the old/wrong IP – I wished I'd used this earlier to better communicate with customers and track the DNS' propagation.) – Fabien Snauwaert Sep 6 '17 at 17:11
  • If I was to perform a DNS change again, I'd set up a backup domain name in advance, to serve the new site while the old one is still propagating. – Fabien Snauwaert Sep 6 '17 at 17:12
8

(Very) long TTL values of weeks are in May 2011 honoured by most DNS resolving nameservers up to 2 weeks.

In a test using just-dnslookup.com, having 50 global distributed active measuring point, with an A record TTL set to 99.999.999 = 165 weeks (precise: 165 weeks 2 days 9 hours 46 minutes 39 seconds), and a default TTL of 2 weeks (= SOA + NS TTL).

First lookup returns:

  • a TTL of 1 week, for 3 out of 50 measuring points
  • a TTL of 165 weeks, for 47 out of 50 measuring points

Consecutive lookups return (converted in to original TTL value):

  • a TTL of 1 week, for 3 out of 50 measuring points
  • a TTL of 2 weeks, for 46 out of 50 measuring points
  • a TTL of 165 weeks, for 1 out of 50 measuring points

A second test (using a different domain) where default TTL is set to 4 weeks (= SOA + NS TTL) results are below.

First lookup returns:

  • a TTL of 1 week, for 3 out of 50 measuring points
  • a TTL of 2 weeks, for 1 out of 50 measuring points
  • a TTL of 165 weeks, for 46 out of 50 measuring points

Consecutive lookups return (converted to full TTL length):

  • a TTL of 1 week, for 3 out of 50 measuring points
  • a TTL of 2 weeks, for 47 out of 50 measuring points
  • a TTL of 165 weeks, for 0 out of 50 measuring points

From the most well known/best connected public resolver services:

  • Google public DNS [8.8.8.8 and 8.8.4.4] reduce to 1 day.
  • UltraDNS [rdns(1|2).ultradns.net] honour full 165 weeks.
  • Sprintlink [ns(1|2|3).sprintlink.net] honour full 165 weeks.
  • 11
    Personally, I would be much more concerned about whether short TTL settings are honored. Have you done similar research on this? For example, if TTL is set to 3600 seconds, will the cached records really expire after an hour? This is highly relevant to a cutover situation. The thought that a 165-week TTL would be honored is actually pretty scary, particularly when thinking about situations wherein I've been called in to clean up after someone else's mistakes. – Skyhawk May 8 '11 at 17:04
  • I think 8.8.8.8 completely ignores ttl and just uses 24h. It certainly doesn't honor at least some lower ttls. Now I gotta find something to do for 24h. – Steven Parkes Jul 23 '11 at 2:30
3

I recently moved DNS for a few domains that host my personal site and project sites from GoDaddy to in-house DNS (yeah, literally my house). Overall, every site that I have remote access to respected the TTL and made the transition well. The same was reported by every friend I could ask to check, both via landline and mobile. The only problem, ironically, were the main caching DNS servers at $University where I work, which seemed to totally disregard TTL for cached queries (and even disregard the TTL value they were assigning to the cached result).

Seems like, overall, TTL should be well-respected. 56% of servers authoritative for .com and .net domains are running BIND, which obviously plays well with the standards. Cablevision/Optimum (at least in NJ) seems to be using Nominum CNS, which also respects TTLs.

0

This is not an answer to your question specifically; but rather, additional things to consider that play into your testing:

Chained DNS Recursors and Caching Daemons

It isn't just edge DNS recursors that cache records. Sometimes people chain recursors and this adds time. Whether this should be done or not could be a lengthy discussion based on what people were trying to solve. I've seen 3 levels of recursion in a data-center. Mixing recursors can have mixed results, as the TTL decrements are not always preserved. Some operating systems cache records. Some systems also use things like nscd, dnsmasq and other methods to minimize impact of local recursor issues and to reduce load on their recursors. The characteristics at the OS vary based on release version, caching daemons, version of caching daemons, etc...

[ Edit ] To reiterate, this is not a normal behavior of a recursor or caching daemon. I am not going to shame the buggy ones, but one of them is considered to be unmaintained, even though it is bundled with many linux distros.

Application DNS Cache

Some browsers also cache records. Java and other apps cache DNS as well. You can sometimes cap the max ttl within applications.

End Results Can Be Skewed

The above items can easily turn a 15 min TTL into 60+ minutes or even longer.

This is why I often suggest that applications or web sites should consider having multiple active nodes in their fault tolerance design, so that the client can determine faster when one entry point into your site has failed and automatically handle the issue in a graceful and predictable manor, when feasible. Anycast is one method that some companies use to make failover somewhat transparent and not rely so heavily on DNS changes. There are also some clever methods of load balancing that can be done in javascript using multiple DNS records.

  • The TTL doesn't reset just because the record is sent from one DNS server to the next. A 15 minute TTL means 15 minutes no matter how many layers of caches it is going through. The only way it could become more is if some of the software is buggy and doesn't implement DNS correctly. – kasperd Jul 5 '17 at 23:42
  • I agree. I have run into a bit of buggy recursors. – Aaron Jul 6 '17 at 1:01
-1

Old question, but new answers (2017, 6 years later):

  1. Seems like nearly all worldwide DNS servers update in 5 minutes
  2. Google and OpenDNS allow you to manually flush a DNS record, speeding propagation updates

Before the experiments below I had previously changed my TTL from 14400 (seconds = 4 hours) to 300 (seconds = 5 minutes) but I did that 2 hours before the experiments and since the previous TTL was 4 hours I'm not sure my change would have gotten out if DNS servers didnt have their own minimum TTL.

My experiments:

Experiment 1:

I changed a name-to-IP translation (A record) in the authoritative server then checked:

After 5 minutes (300 seconds) about half of the global servers checked by those sites had been udpated.

After 7 minutes, all had been updated except 1.

Experiment 2:

Google and OpenDNS allow you manually flush their DNS cache for a particular domain. Links:

I updated another A-record, and then immediately flushed Google's DNS cache. They have a captcha that made me "click on all squares with signs" 3 times, so it took 1-2 min before I could complete the flush.

After 4 minutes, only 1 DNS server checked by those sites had the old IP address. All others had been updated.

So clearing Google's DNS cache, and forcing it to re-query the authoritative server, appears to have sped up global DNS propagation, perhaps by triggering cache updates throughout the world's servers.

However even without the Google flush, it appears propagation is in minutes, not hours or days.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.