Changing nameservers?
Click here to read more about SpamStopsHere, the e-mail security company that brings you this blog.
If you’re going to change the authoritative nameservers for your domain, you need to know the proper procedure to do it. If you don’t follow these simple procedures when changing nameservers, and you aren’t familiar with the way that DNS caching works, you will end up with unexpected results.
Authoritative nameservers
When you register a domain under a Top Level Domain (TLD), the administrator of that TLD (i.e. “com”, “net”, or “org”) will ask you for the authoritative namservers for your domain. For example, if you register the domain “example.com” your domain name registrar will ask you for the authoritative namservers for “example.com”, and you might indicate these to be:
ns1.example.com
ns2.example.com
With the names of these authoritative nameservers on hand, whenever someone makes a public DNS query for resource records in your domain, the top level domain will refer the query maker to these authoritative nameservers. The top level domaind does this with “NS” type resource records.
Usually you will then manage the zone for your domain on these nameservers. You will also put “NS” type resource records in the zone for your domain, but these will be authoritative instead of delegating authority. when people want to resolve a resource record like “www.example.com”, they will consult the nameservers at ns1.example.com and ns2.example.com. This is how that query would play out:
Requestor: “Hey .com, what is the IP address of www.example.com?”
Dot Com Nameservers: “I don’t know, but ask ns1.example.com or ns2.example.com. By the way, here are the IP addresses of ns1.example.com and ns2.example.com.”
Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”
ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com.”
DNS caching
DNS caching allows us to temporarily store DNS information from a previous DNS query in our virtual rolodex, so that we can save the time of having to do a full search the next time we need the IP address of the hostname ”www.example.com”. However, to allow a DNS administrator to change records in their zone when they need, the owner of the zone is able to specify how long someone should temporarily store this information without doing a full search again. This length of time for caching an entry is is called the Time To Live (TTL) and the value is specified in seconds.
To illustrate this setting, here is the previous example including the TTL:
Requestor: “Hey .com, what is the IP address of www.example.com?”
Dot Com Nameservers: “I don’t know, but ask ns1.example.com or ns2.example.com. By the way, here are the IP addresses of ns1.example.com and ns2.example.com. When you write these down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”
Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”
ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”
Our rolodex card would then say:
www.example.com = 1.2.3.4 (discard after 60 seconds)
ns1.example.com is authoritative for example.com (discard after 172800 seconds)
ns2.example.com is authoritative for example.com (discard after 172800 seconds)
One second later, our rolodex card should say:
www.example.com = 1.2.3.4 (discard after 59 seconds)
ns1.example.com is authoritative for example.com (discard after 172799 seconds)
ns2.example.com is authoritative for example.com (discard after 172799 seconds)
For 59 more seconds, we wouldn’t need to search the Internet when we wanted the IP address of “www.example.com”. However, after 59 more seconds had passed, we would discard the cached information for “www.example.com” and our rolodex card would only contain:
ns1.example.com is authoritative for example.com (discard after 172740 seconds)
ns2.example.com is authoritative for example.com (discard after 172740 seconds)
At this point, if we wanted to get the IP address of ”www.example.com”, we would need to do an Internet search, but we wouldn’t need to start at the nameservers for the “com” TLD because we know the authoritative nameservers for example.com. The query would skip an unneeded question and go like this:
Requestor: “Hey .com, what is the IP address of www.example.com?”
Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”
ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”
Changing nameservers
Due to DNS caching, the proper steps to change nameservers for a domain are:
- Set up the zone on the new nameservers.
- Update the NS records on the old nameservers
- Update the NS records on the TLD nameservers.
- Wait the TTL of the old NS records (or a week).
- Remove the zone from the old nameservers.
A common mistake
Step 2 and 4 is required because the DNS protocol allows old nameservers to continue controlling the domain due to DNS caching behavior. DNS caches are under no obligation to ask TLD nameservers when they have the authoritative nameservers for a domain cached.
If you skip steps 2 and 4, but perform the rest of the steps, your domain will be unresolvable to anyone using a DNS caching server that has the old nameservers cached until one or more of the following occurs:
- The cache on the DNS caching server is flushed
- The TTL of the old nameservers passes before another DNS query is made to those old nameservers (this may never happen, depending on how often queries to the old nameservers are made)
For example, we may be trying to change the nameservers from “ns1.example.com” and “ns2.example.com” to “ns3.example.com” and “ns4.example.com” and due to caching our rolodex card might read:
ns1.example.com is authoritative for example.com (discard after 1 seconds)
ns2.example.com is authoritative for example.com (discard after 1 seconds)
Then at the last second, before these expire, we need the IP address of “www.example.com” so we make this query:
Requestor: “Hey ns1.example.com, what is the IP address of www.example.com?”
ns1.example.com: “I know the answer to that. The IP address is 1.2.3.4. If you write this down, make sure and discard this information after 60 seconds because it may no longer be correct after that. By the way, the authoritative nameservers for example.com are ns1.example.com and ns2.example.com in case you have any other questions about my domain example.com. When you write that second part down, make sure and discard this information after 172800 seconds because it may no longer be correct after that.”
Our rolodex card would be back to reading:
www.example.com = 1.2.3.4 (discard after 60 seconds)
ns1.example.com is authoritative for example.com (discard after 172800 seconds)
ns2.example.com is authoritative for example.com (discard after 172800 seconds)
Although the nameservers for “com” may now be referring queries for “example.com” to “ns3.example.com” and “ns4.example.com”, we will never ask for that information until our old data has expired or the cache is flushed.