There are two different default DNS/BIND TTL settings you need to switch when moving domains to a different IP address. One is the negative caching setting in the SOA record, and the other is the default ttl at the top of the file ($ttl).. If you have different TTL settings for your indidual record, you will need to set those as well. We are assuming BIND version 9 for this article, but the concept should work with any DNS. The negative cache setting is the last entry in your SOA record. Typically, the default TTL is set to a day, which is 86400 seconds. If both the negative cache TTL and default TTL are set to 86400, it means that both negative responses and positive queries are cached for a day. For more info about negative caching, see rfc2308. In the following example, we have switched the TTLs to 600:
$ttl 600 domain.com. IN SOA ns1.domain.com. webmaster.domain.com. ( 1026305462 10800 3600 432000 600 ) |
When moving a domain to a different IP, switch the TTLs to a lower number (10 minutes in the above example), change your serial number, reload your zones (restart DNS), and wait until your previous TTL has expired. Verify the TTL for your records by using dig. Notice that the ttl records decrement on repeated uses of dig:
dig website.com ;; ANSWER SECTION: website.com. 86400 IN A 128.242.82.47 dig website.com ;; ANSWER SECTION: website.com. 86398 IN A 128.242.82.47 |
On the first query the result was cached. On the second query, the cached result was used, but the ttl decremented by two seconds. When it gets to zero, the nameserver will look up the answer again. Now, if you are changing the IP address or name of the nameserver authoritative for your domain, then you have to wait an extra long time, since the IP address of the authoritative server has to propogate first to the root servers, and then back down again. You can actually dig results directly from the root servers. First, let’s find out what servers are authoritative for the top level com, org, and to domains:
u-1@srv-1 u-1 $ dig com ; <<>> DiG 9.2.2rc1 <<>> com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52593 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN A ;; AUTHORITY SECTION: com. 172800 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 2003031300 1800 900 604800 86400 ;; Query time: 119 msec ;; SERVER: 199.181.164.1#53(199.181.164.1) ;; WHEN: Thu Mar 13 13:42:45 2003 ;; MSG SIZE rcvd: 94 u-1@srv-1 u-1 $ dig org ; <<>> DiG 9.2.2rc1 <<>> org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21056 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;org. IN A ;; AUTHORITY SECTION: org. 86400 IN SOA A7.NSTLD.COM. DOMADMIN.ULTRADNS.NET. 2003048475 1800 900 604800 86400 ;; Query time: 104 msec ;; SERVER: 199.181.164.1#53(199.181.164.1) ;; WHEN: Thu Mar 13 13:42:52 2003 ;; MSG SIZE rcvd: 90 u-1@srv-1 u-1 $ dig to ; <<>> DiG 9.2.2rc1 <<>> to ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36182 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;to. IN A ;; AUTHORITY SECTION: to. 600 IN SOA tonic.to. hostmaster.tonic.to. 2003031401 43200 7200 2592000 600 ;; Query time: 65 msec ;; SERVER: 199.181.164.1#53(199.181.164.1) ;; WHEN: Thu Mar 13 13:42:54 2003 ;; MSG SIZE rcvd: 73 |
Pretty cool. Since we want website.com, we will use a.gtld-servers.net. Notice that the named.ca file is actually for the . domain. You can dig . as well, and it will give you the same info as named.ca, or as much as is needed to resolve the top level domains. OK. Back to our original task. We want to find out directly from the servers that handle the .com top level domain, what the authoritative server is for website.com:
u-1@srv-1 u-1 $ dig @a.gtld-servers.net website.com ; <<>> DiG 9.2.2rc1 <<>> @a.gtld-servers.net website.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37195 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;website.com. IN A ;; AUTHORITY SECTION: website.com. 172800 IN NS ns15a.boca15-verio.com. website.com. 172800 IN NS ns15b.boca15-verio.com. ;; ADDITIONAL SECTION: ns15a.boca15-verio.com. 172800 IN A 208.55.91.50 ns15b.boca15-verio.com. 172800 IN A 208.55.91.51 ;; Query time: 85 msec ;; SERVER: 192.5.6.30#53(a.gtld-servers.net) ;; WHEN: Thu Mar 13 13:57:11 2003 ;; MSG SIZE rcvd: 114 u-1@srv-1 u-1 $ |
After the root servers have the correct info, you can watch the data propagate down to the second level:
u-1@srv-1 u-1 $ dig @NS.AUSTIN.IBM.COM website.com ; <<>> DiG 9.2.2rc1 <<>> @NS.AUSTIN.IBM.COM website.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42691 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;website.com. IN A ;; ANSWER SECTION: website.com. 86400 IN A 128.242.82.47 ;; AUTHORITY SECTION: website.com. 86400 IN NS ns15a.boca15-verio.com. website.com. 86400 IN NS ns15b.boca15-verio.com. ;; ADDITIONAL SECTION: ns15a.boca15-verio.com. 139853 IN A 208.55.91.50 ns15b.boca15-verio.com. 139853 IN A 208.55.91.51 ;; Query time: 404 msec ;; SERVER: 192.35.232.34#53(NS.AUSTIN.IBM.COM) ;; WHEN: Thu Mar 13 14:04:13 2003 ;; MSG SIZE rcvd: 141 u-1@srv-1 u-1 $ |
Of course, the second level queries just mean that this is the first time that the nameserver has looked up the hostname. If you do it again, the TTL will decrement like we showed you above. The point is, if you are changing your nameserver, you have to get the root servers to have the correct info first, then all of the other second level servers that cache results will have the correct info when the TTL expires.
After you have finished your migration, make sure you set the TTLs higher again, or your server will have a higher load and cause unnecessary network traffic.
