What happens when you update your DNS

What happens when you update your DNS

Translated from: https://jvns.ca/blog/how-updating-dns-works/

For the basic knowledge of DNS, please refer to Mr. Ruan's: Getting Started with DNS Principles .

The following is the text:

---

I've seen a lot of people get confused about updating their site's DNS records to change IP addresses. Why so slow? Are you really going to spend 2 days waiting for all the data to be updated? Why do some people see the new IP and some people see the old IP? In the end what happened?

So I wanted to quickly explore what's going on behind the scenes when you update your DNS.

How DNS Works: Recursive Resolvers vs Authoritative Name Servers

First, we need to know a little about DNS. There are two types of DNS servers: authoritative domain name server (authoritative) and recursive resolver (recursive).

An authoritative domain name DNS server (also called a root domain name server) has a database of IP addresses for the domains it is responsible for. For example, the current authoritative domain name server for github.com is ns-421.awsdns-52.com. You can get the IP address of github.com like this:

$ dig @ns-421.awsdns-52.com github.com

A recursive DNS resolver itself does not know what address a certain domain name corresponds to. They obtain the corresponding IP address by asking the correct authoritative domain name DNS server, and then cache this IP address so that they can access it again. 8.8.8.8 is a recursive parser.

When people visit your website, they may query on a recursive resolver. So how does it work? Let's see together!

How does a recursive DNS resolver query github.com?

An example of what a recursive resolver (say 8.8.8.8) does when you access the IP address (A record) of github.com. First, if it has cached the data, it will use the cached data directly. But what if all caches are invalidated? It will do the following work:

1. It has the IP addresses of the root DNS servers in its source code. You can refer to [unbound's source code here]( unbound's source code here ). If 198.41.0.4start . Here are some official sources for hardcoding IP addresses: official source , also known as the "root hint file".

2. Ask the root nameservers github.com.

   We can roughly reproduce what happens digwhen , which tells us a new authoritative nameserver, a nameserver192.5.6.30 with the IP address ..com

   $ dig @198.41.0.4 github.com
   ...
   com.			172800	IN	NS	a.gtld-servers.net.
   ...
   a.gtld-servers.net.	172800	IN	A	192.5.6.30
   ...
   

   The details of the DNS response are a little more complicated, one authority part contains some NS (name server) records, and the other part contains A records, so you can get the IP address without additional lookups.

   (In reality, 99.99% of the time it already caches the content from the .comnameservers , but let's pretend we're really starting from scratch)

3. Query the .comnameservers github.comfor information about .

   $ dig @192.5.6.30 github.com
   ...
   github.com.		172800	IN	NS	ns-421.awsdns-52.com.
   ns-421.awsdns-52.com.	172800	IN	A	205.251.193.165
   ...
   

   We have a new IP address to look up! These are the name servers github.comfor .

4. Look up information about from github.comthe name servers.github.com

   It's almost over!

   $ dig @205.251.193.165 github.com
   
   github.com.		60	IN	A	140.82.112.4
   

   It worked! We github.comgot Athe record! Now the recursive name server has taken the IP address github.comof and returned it to you. It does all of this by just hardcoding a few IP addresses (ie, the root nameservers).

How to view the process of all recursive DNS servers: dig +trace

When I want to see what a recursive server does when resolving a domain name, I run:

$ dig @8.8.8.8 +trace github.com

It will print out all the DNS records requested (starting from the root DNS server, going through the 4 steps we just discussed).

Let's update some DNS records

Now that we know the basic workflow of DNS, let's update some DNS records and see what happens.

When you update your DNS records, you have two main options:

1. Do not modify nameservers
2. modify nameservers

Talk about TTLs (time to live)

We forgot something important! TTLs! Do you remember saying that a recursive DNS server will cache records until they expire? A server should look at its TTL or "time-to-live" to determine whether a record is expired.

In the example below, the TTL of the A record returned by the github nameserver for the DNS record is 60, meaning 60 seconds:

$ dig @205.251.193.165 github.com

github.com.		60	IN	A	140.82.112.4

This is a very short TTL, and in theory, if everyone's DNS implementation follows the DNS standard, it means that if Github decides to github.comchange address, everyone should get the new IP address within 60 seconds. Let's see how it actually works.

Option 1: Update a DNS record on the same nameserver

First, I updated my nameserver (Cloudflare) with a new DNS record: the one that maps test.jvns.cato 1.2.3.4.

$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca.		299	IN	A	1.2.3.4

Then it worked! There is no need to wait at all, because it has not been cached before test.jvns.ca. But new records are cached for about 5 minutes (299 seconds).

What happens if you try to change this IP? I changed the IP address to 5.6.7.8and then executed the same DNS lookup command:

$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca.		144	IN	A	1.2.3.4

It looks like DNS is still cached for 144 seconds 1.2.3.4. Interestingly, if I query multiple times 8.8.8.8I get different results: sometimes the new IP is returned, sometimes the old IP, I guess 8.8.8.8 is actually load balanced to different backends, each Each end server has its own cache.

After waiting for 5 minutes, all of 8.8.8.8them returned the newly cached 5.6.7.8IP records. Awesome, this is really fast!

You can't always rely on TTL

Like most Internet protocols, not all of them follow the DNS specification. Some ISP DNS servers cache longer than the TTL stipulated time, such as two days instead of 5 minutes. People can always hardcode old IP addresses in their /etc/hosts.

In actual use, I hope that when I update the DNS records with a TTL of 5 minutes, most clients will migrate to the new IP quickly (say within 15 minutes), and then the remaining clients will follow in the next few days Update to new IP.

Option 2: Update your nameservers

We just learned that when you update an IP address without changing your nameservers, many DNS servers will quickly update to the new IP addresses. But what happens when you update your nameservers? Let's try it!

I don't want to update my blog's nameservers, so I use another domain name of mine and use it in the HTTP zineexamplecat.com example: .

Previously my nameservers were dns1.p01.nsone.net. I decided to switch to Google's nameservers -- ns-cloud-b1.googledomains.cometc.

When I made the change, my domain registrar popped up with a somewhat displeased message - "examplecat.com has been changed and will take effect within 48 hours". Next I set up a new A record for the domain name, pointing to 1.2.3.4.

ok let's see if it works

$ dig @8.8.8.8 examplecat.com
examplecat.com.		17	IN	A	104.248.50.87

No change. If I ask another DNS server, it knows the new IP:

$ dig @1.1.1.1 examplecat.com
examplecat.com.		299	IN	A	1.2.3.4

But 8.8.8.8 is still unknown. Even though I just changed it 5 minutes ago, 1.1.1.1 gets the new IP, presumably because no one has ever queried examplecat.com from 1.1.1.1 before, so it doesn't have that data in its cache.

Longer name server TTLs

The reason my domain registrar says "this will take effect within 48 hours" is because the TTLs in the NS records (which the recursive server uses to know which nameservers to query) are much longer.

The new nameservers will definitely return the new IP address examplecat.comof

$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com.		300	IN	A	1.2.3.4

But remember what happened to the name servers we github.comqueried ?

$ dig @192.5.6.30 github.com
...
github.com.		172800	IN	NS	ns-421.awsdns-52.com.
ns-421.awsdns-52.com.	172800	IN	A	205.251.193.165
...

172800 seconds is 48 hours! So nameserver updates usually take longer to expire from cache and propagate than just updating the IP address without changing your nameservers.

How are your nameservers updated?

When I examplecat.comupdate , this .comdomain gets a new NSrecord . like this:

$ dig ns @j.gtld-servers.net examplecat.com

examplecat.com.		172800	IN	NS	ns-cloud-b1.googledomains.com

But how did the new NS record get there? The process goes like this: I tell my domain registrar what I want the new nameservers to be. The domain name registrar then .comtells the nameservers to make the update.

.comFor , updates are very fast (within a few minutes), but I think for some other TLDs (top-level domains), the TLD nameservers may not respond as quickly.

Your project's DNS resolver library may also cache DNS records

Another reason why TTLs are not honored in practice is that many programs need to resolve DNS names, and some programs cache DNS records in memory indefinitely (until the program is restarted).

For example, AWS has an article: Setting the JVM TTL for DNS Name Lookups . I haven't written much JVM code for DNS lookups yet. But searching around for JVM and DNS a bit, it seems possible to configure the JVM to cache every DNS lookup indefinitely (like this elasticsearch issue ).

That's all!

I hope this article helps you understand what happens when updating your DNS!

Again as a disclaimer - TTLs don't say absolutely everything about DNS - some recursive servers apparently won't honor TTLs, even for primary addresses like 8.8.8.8. So even if you just updated an A record with a short TTL, it's actually quite possible to still get the old IP address for a day or two.

Also, after posting this post, I changed the nameservers examplecat.comfor to back to their original values.