dingman - 10:40 pm on Sep 28, 2002 (gmt 0)

DNS information - the data used to translate www.yourdomain.tld to the numerical addresses the software uses to connect - gets cached for varying ammounts of time depending on your server configuration. This configurable timeout defines how long non-authoritative DNS servers keep sending the IP you were on last time they checked before checking again, and hence the maximum ammount of time it will take for everyone to start getting the new information. I feel like I'm probably sounding confusing here, so here's an example: (These are unroutable IPs, by the way)

Suppose I have a website at www.mysite.tld, on a server with IP address 192.168.55.20. Either I, my ISP, my hosting provider, or my registrar, depending on the service agreements I have, maintains the "authoritative" DNS servers for this domain. Suppose I have three people who want to visit the site. One of them is me, another is my father at home several states away, and the third is an old college friend in yet another state.

For the sake of this example, we'll pretend that my computer is configured to use the same DNS server that is authoritative for mysite.tld. (call it ns.mysite.tld - though this is certainly not required. The name could be anything.) I type [mysite.tld...] into my browser. The browser then consults the DNS server. The DNS server in this case is authoritative, so it doesn't have to ask any further to determine that www.mysite.tld means 192.168.55.20, and it tells the browser so. The browser then asks 192.168.55.20 for the web page. If I then click on a link to another page on the same site, the process is repeated.

Now that I know things work, I call up my father and ask him to take a look. He types the same thing into his browser, but he has his system configured to use his ISP's DNS server (call it ns.dadsisp.tld). His browser asks ns.dadsisp.tld what the IP address for www.mysite.tld is. Since ns.dadsisp.tld is *not* authoritative for mysite.tld, it asks one of the 'root' name servers for the answer. The 'root' nameserver doesn't know either, but it knows who is authoritative for .tld, and referrs ns.dadsisp.tld to that server (often, especially for .com, the 'root' servers are also the top-level doman authoritative servers, but not necessarily.), which then referrs ns.dadsisp.tld to ns.mysite.tld, which reports that www.mysite.tld means 192.168.55.20. It also includes a timeout value for how long this inoformation should be cached (say 4 days), and ns.dadsisp.com remembers what the answer was. Now, when Dad clicks on a link to another page on my site, his browser asks ns.dadsisp.tld the same question again. Since the it hasn't been four days since the last time someone asked ns.dadsisp.tld that same question, it just answers without checking.

The next day I decide that I want to move the site from 192.168.55.20 to a different server, 192.168.128.3. I make the change in the authoritative records on ns.mysite.tld, and replace the site on 192.168.55.20 with a page that says "we've moved to a new IP". This time I'm a little nervous about the change, so instead of just calling Dad to make sure it works, I call Dad and my friend in another state.

When I look, my browser again asks ns.mysite.tld for the IP address, and since ns.mysite.tld is authoritative, it knows the new IP, and sends me to the site on its new server at 192.168.128.3.

When my friend looks, her browser asks ns.friendsisp.tld for the IP address. Ns.friendsisp.tld has never been asked for this before, so it goes through the same steps that ns.dadsisp.tld did yesterday. Since those steps culminate in asking ns.mysite.tld, she gets the new answer, 192.168.128.3.

When Dad looks, though, his browser asks ns.dadsisp.tld again. Ns.dadsisp.tld knows that someone asked it that question just yesterday, and that the timeout was four days. Since it has checked more recently than the timeout value, it skips the other steps and tells Dad's browser that www.mysite.tld means 192.168.55.20. Dad gets the "we've moved to a new IP" page. Oops. Dad will keep getting that page for the next 3 days, too, until ns.dadsisp.tld expires the answer from its cache and goes through the whole set of inquiries and referrals again.

This caching is generally a good thing. Even with caching in place, the root name servers handle a phenomenal number of requests per second. Without it DNS just plain wouldn't be practical. However, it does make changing DNS information slow, which is particularly fristrating when you are setting up DNS for the first few times and aren't absolutely certain you'll get it right. When I have the control, which so far has been most of the time, I set the timeouts short while I'm initially configuring a domain, and then longer once I think I've got a stable configuration. The only way to be sure you have a smooth transition, though, is to leave an indentical copy of the site on the old server (at the old IP) until longer than the longest timeout affected by the change.