Fenix by Takeda11
Many people get confused about updating DNS records when they change the IP address of their site. Why are these records slowly updating? Do you really need to wait two days for everything to update? Why do some visitors see the new IP, while others see the old one?
The Mail.ru Cloud Solutions team hastranslated an article by developer and author of articles Julia Evans, where she answers these questions and popularly tells what happens during a DNS update from a front-end perspective.
Here's a quick exploration of what happens behind the scenes when you update a DNS record.
How DNS Works: Recursive and Authoritative DNS Servers
First, we need to explain a little about the DNS system. There are two types of DNS servers: authoritative and recursive .
Authoritative DNS servers (also known as name servers ) maintain a database of IP addresses for each domain they are responsible for. For example, right now the authoritative DNS server for github.com is
ns-421.awsdns-52.com. You can ask him for the github.com IP address with this request:
dig @ns-421.awsdns-52.com github.com
Recursive DNS servers by themselves don't know anything about who owns which IP address. They compute the IP address for a domain by querying it from the appropriate authoritative DNS servers and then cache that IP address in case they are asked for it again. So, 8.8.8.8 is a recursive DNS server.
When people visit your website, they are probably making DNS lookups to a recursive DNS server. So how do recursive DNS servers work? Let's get a look!
How a recursive DNS server queries the IP address of github.com
Let's take a look at an example of what a recursive DNS server (e.g. 8.8.8.8) does when you ask it for the IP address (A record) for github.com. First, if it already has a cached result, it will issue it. But what if all caches are expired? Here's what's going on.
Step 1 : The IP addresses for the root DNS servers are hard-coded into its source code. You can see this in the unbound source code . Let's say he selects 198.41.0.4 first. Here is the official source for these hard-coded IP addresses, also known as the "root hints file".
Step 2 : Ask root nameservers about github.com.
We can roughly reproduce what is happening with the command
dig... It gives us a new authoritative nameserver to query: a nameserver for .comwith an IP address of 192.5.6.30.
$ 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 - in this case, there is an authority section with some NS records and an additional section with A records, so you don't need to do an extra lookup to get the IP addresses of those name servers.
In practice, 99.99% of the time there will already be a cached nameserver address
.com, but we pretend we are really starting from scratch.
Step 3 : Ask nameservers
.comabout github.com.
$ 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 send the request! This is one of the nameservers for github.com.
Step 4 : Ask the github.com nameservers for the github.com address.
We're almost done!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
So we have an A record for github.com. The recursive server now has the github.com IP and can return it to you. And he was able to go through the whole process, starting with just a few hard-coded IP addresses: the addresses of the root name servers.
How to see all steps of a recursive DNS server: dig + trace
To see what the recursive DNS server will do to resolve the domain, you can run:
$ dig @8.8.8.8 +trace github.com
This command shows all the DNS records that the recursive server requests, starting with the root DNS servers, which is all four steps we just went through.
Update DNS records
Now that we know the basics of how DNS works, let's update some DNS records and see what happens.
When updating DNS records, there are two main options:
- keep the same name servers;
- change nameservers.
Let's talk about TTL
But we forgot something important. This is TTL. As we said earlier, a recursive DNS server will cache records until they expire. It decides whether a record expires based on its TTL (time to live).
In this example, the GitHub nameserver returns a TTL of 60 for its DNS record, which means 60 seconds:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
This is a fairly short TTL. In theory, if all DNS implementations followed the DNS standard , that would mean that if GitHub decided to change the IP address for github.com, everyone would receive a new IP address within 60 seconds. Let's see how this happens in practice.
Option 1: update the DNS record on the same name servers
First, I updated my nameservers (Cloudflare) to get a new DNS record, the A record, which 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
It worked immediately! There was no need to wait at all, because before that there was no DNS record
test.jvns.cathat could be cached. Excellent. But it looks like the new record is cached for about five minutes (299 seconds).
So what if we try to change this IP address? I changed it to 5.6.7.8 and then ran the same DNS query:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
It looks like on this DNS server the 1.2.3.4 record is still cached for 144 seconds. Interestingly, if you query 8.8.8.8 multiple times, you will get inconsistent results - sometimes it gives you a new IP and sometimes an old one. Probably 8.8.8.8 actually distributes the load across a bunch of different backends, each with their own cache.
After five minutes of waiting, all 8.8.8.8 caches were updated and always returned a new 5.6.7.8 entry. Amazing. It's pretty fast!
You can't always rely on TTL
As with most Internet protocols, not everything follows the DNS specification. Some ISP DNS servers will cache records for longer than the TTL specified. For example, within two days instead of five minutes. And people can always hardcode the old IP address in their file
/etc/hosts.
In practice, when updating a DNS record with a five minute TTL, you can expect a large percentage of clients to quickly move to new IP addresses (for example, within 15 minutes), and then there will be a bunch of laggards that will slowly update over the next few days.
Option 2: updating your nameservers
So, we've seen that when you renew an IP address without changing your name servers, many DNS servers get a new IP address pretty quickly. Excellent. But what happens if you change your nameservers? Let's try!
I didn't want to update the nameservers for my blog, so instead I took a different domain of mine and used that in the examples for the HTTP log, examplecat.com.
Earlier my servers were set to
dns1.p01.nsone.net. I decided to change them to Google servers with addresses ns-cloud-b1.googledomains.comand so on.
When I made the change, my domain registrar displayed a somewhat ominous message: “Changes to examplecat.com saved. They will come into effect within the next 48 hours. " Then I set up a new A record for the domain to point to 1.2.3.4.
Okay, let's see if anything has changed:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
No changes. 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 still doesn't know anything. The reason 1.1.1.1 sees a new IP, even though I just changed it five minutes ago, is probably because no one has ever asked 1.1.1.1 about this examplecat.com before - so it has nothing in its cache It was.
Name servers have a lot more TTLs
The reason my registrar said, “It will take 48 hours,” is because the TTL on the NS records (the information about which nameserver the recursive server should access) is much larger.
The new nameserver definitely returns a new IP address for examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
But remember what happened when we queried the github.com nameservers earlier:
$ 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
...
172,800 seconds is 48 hours! Thus, updating the name server usually takes much longer. It takes time for the caches to expire and to propagate the new address. It takes much longer than just updating your IP address without changing your nameserver.
How your nameservers are updated
When I update nameservers for
examplecat.com, the nameserver .comgets a new NS record with a new domain. Like this:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
But how does this new NS record get there? In fact, I tell my domain registrar what I want the new nameservers to look like by updating them on the website, and then my domain registrar tells the nameservers
.comto do the update.
For
.comthese updates are fairly fast (within a few minutes), but I think that for some other TLD zones, the nameservers may not apply updates as quickly.
Your program's DNS resolver library can also cache DNS records
Another reason why the TTL might not be observed in practice is that many programs must resolve DNS names, and some programs will also cache DNS records in memory indefinitely (until the program is restarted).
For example, there is an article on setting up JVM TTL for DNS lookup . I haven't written much JVM code for DNS lookups myself, but a little internet search about JVM and DNS gives the impression that you can configure the JVM to cache every DNS lookup for an infinite amount of time (see this ElasticSearch ticket for example ) ...
That's all!
Hope this helps you understand what happens when you update your DNS.
I'll make a reservation that the entire history of DNS distribution is determined not only by TTL. Some recursive DNS servers probably don't respect TTLs, even major servers like 8.8.8.8. So even if you just update the A record with a small TTL, it is possible that in practice you will still receive requests for the old IP within a day or two.
After posting this article, I changed the nameservers for examplecat.com back to their old values.
What else to read: