“Help! I’ve changed something in my domain and now it’s all funky! How long is it going to take before it all works again??!?”
I just spent the last week slowly moving over several domains to a new server. I’m worn out by it all… but now it’s done. Here’s some things I’ve learned from the experience. Make use of them.
When you register a domain name you take control of it for a small fee. But just because you have the domain registered doesn’t mean it’s capable of doing anything. In order for the domain to be useful it has to point somewhere… it has to point to a hosting service of some kind.
Every domain has something called a “domain zone file.” A zone file is where all of these pointers are stored. In this zone you can specify that your domain will point to a particular server, or that a particular subdomain will point to a particular IP and your main domain will point to another IP. You can specify that a domain points to another, or that a domain is nothing more than an alternate name for another. You can add text records like SPF, you can do a lot of stuff.
Zone files are hosted on “name servers.” When you register a domain name you need to provide name servers, or use the registrar’s. That’s where your zone file will be kept.
A typical record set looks like:
skepticalmarketer.com. 14400 A 70.47.127.0
skepticalmarketer.com. 14400 MX 0
www 14400 CNAME skepticalmarketer.com.
ftp 14400 CNAME skepticalmarketer.com.
This says that skepticalmarketer.com points to 70.47.127.0 (A typical “A” record). It says that skepticalmarketer.com is the primary mail transfer server for incomming mail (so that other servers know which server to connect to) and that www and ftp.skepticalmarketer.com both point to the main domain’s IP.
The number, 14400 is a special number called the “TTL” number. TTL, or time to live, specifies the maximum duration (in seconds) that it should be allowed to stay in a cache. 14400 seconds = 240 minutes = 4 hours.
Additionally, the information about which name server is the “authority” is cached as well. Technically this is called the “authority record” or “SOA” (start of authority) resource. It contains the main name server that will be responsible for delivering this zone file to those that ask for it. It, too, has a TTL. Usually it’s a bit longer, 86400 is a typical number. 86400 seconds is 1 day.
What’s a cache?
How many times do you visit warriorforum during the course of a day? Once? Twice? 10 times? How many pages do you load during that visit? 5? 10? 20? Think about all of the images and all of the sub-files that load. Each of these are loaded by domain.
Now your local ISP is a lot closer to you, net-wise, than some all powerful centralized server. And that central server might not even be available due to internet traffic or other problems. If every time you loaded a page you had to make a dozen queries to some all powerful central server, that server would get overloaded and your connection would drop to a crawl. The people that designed the internet realized this, so they decided to decentralize the domain name system by using caches. Your ISP, and all ISPs, maintain a cache of domain names. The cache is checked and updated anytime someone makes a name server lookup.
It works like this:
Your lookup -> Your ISP’s domain name server -> Looks at the TLD (top level domain, ie: .com, .biz, .org) record -> Queries the name server listed in the TLD (the authority record) -> gets the information from that server and saves it.
This way whenever you want to make a domain request you only need to go as far as your local ISP. When the TTL is up, that entry is purged from the cache. If you visit that domain again your ISP will simply cache the info again.
Since windows 98, most operate systems have also kept a small local cache. So the chain goes even deeper. First your OS will ask itself “Do I know this already? before asking your ISP. This speeds up the process too and helps to keep you running smoothly.
Now that you understand why and what a cache is, you can begin to understand what happens when you change domain information.
So what would happen if you suddenly changed, say, the A record above:
skepticalmarketer.com. 14400 A 70.47.127.0
To something like:
skepticalmarketer.com. 14400 A 127.99.57.104
Well first the change would have to happen within the server. That usually only takes a few minutes, if that. Now any server that hasn’t already asked for the record, or that is working on an expired cache, will now receive the new information from the authorized zone the next time they ask for it. So there’d be no delay there. But on any system that has a cache… the old cache will continue to be used until it expires.
In this case the recommended expiration was 4 hours. Local cache servers are free to change this value if they want and some do have minimums or maximums in order to improve performance. Imagine if the cache expired every second, the traffic that’d generate could slow the entire system down quite a bit. Still, the recommended amount was 4 hours, and that’s probably what it’ll be on most servers. So in this situation the old A record cache should expire in just a matter of hours and the new one will be ready to go. Pretty sweet, eh?
Consider this with a semi-static IP. If you have an IP address that changes some you could point a subdomain to that semi-static IP, set a low TTL (like 3600 seconds, 1 hour) and merely update the zone file if things change. This is how “dynamic DNS” services work, except they combine the zone update server with a program that runs on your machine. You can emulate that behavior even without a program like that, tho, if you want.
But that’s just the beginning.
So what if you’re moving hosts? Or if your domain is registered at namecheap and you want to pass zone control off to your host and have it run the DNS service?
Well first, it has to get a completely new authority record. It gets this from the top level domain record, like .com, .biz, .org, .net, etc. Each of those have designated central registries that maintain these records. Those records must be updated (which can take time), individually cached SOA records also must expire, along with local caches.
As you’ve probably guessed, this takes quite a bit more time. This is why some DNS changes can happen almost instantly, while others can take hours or even days.
So how can I put this to good use?
If you’re moving servers, start by lowering the TTL ahead of time. A day or 2 if you can, this will make sure that cached entries don’t stick around very long. You can always change it back when you’re done, or if you’re changing name servers just lower the old zone’s TTLs and keep the new one at the default.
Next, consider whether or not you really need to change name servers. If you’ve registered your domains with a service that provides it’s own name servers you might never need to change them. This will tremendously speed up the change-over.
If you absolutely must change name servers then keep the old zone file around for a little while. You can edit the old zone file and point all of the entries to the new server without completely removing the old zone. This means that queries to the old name server will still resolve to the new records. Meanwhile the new zone will be coming into effect. As the old caches expire the new one will take over. After a few days you can then remove the old zone completely and still benefit from the lowered TTL.
Old zone, new zone? How can I setup a new server if it’s not resolving yet?!?!
The answer is… the HOSTS FILE. Remember how I said that all operating systems these days have their own local DNS cache? Well you can override this cache by using a “hosts file.”
The hosts file looks like:
70.127.88.122.123 www.skepticalmarketer.com
70.127.88.122.123 skepticalmarketer.com
70.127.88.122.123 ftp.skepticalmarketer.com
It’s just IP address and the name. Wildcards are not supported so if you’re working with a lot of subdomains you may need to setup an entry for each.
The location of the hosts file is different in each operating system. If you’re a linux user you probably already know where your’s is (/etc/hosts usually).
Other operating systems:
Windows XP/Vista = C:\WINDOWS\SYSTEM32\DRIVERS\ETC\hosts
Windows NT/2k = C:\WINNT\SYSTEM32\DRIVERS\ETC\hosts
Win 98/ME = C:\WINDOWS\hosts
You can put the new IP address in this file along with your domain name. You may need to refresh your network or reboot your system for this to take effect (depends on your OS), but once it does you’ll now be set to use the new system. This allows you to make fixes on the new server before it goes live to the world.
Well, that’s what I’ve learned. I hope it helps someone. Make use of it, it can save you quite a bit of headache.
(c) 2007, Aaron Colman
