Takeda11的Fenix
很多人在更改站点IP地址时对更新DNS记录感到困惑。为什么这些记录会缓慢更新？您是否真的需要等待两天才能更新所有内容？为什么有些访客看到新的IP，而另一些访客看到旧的IP？Mail.ru云解决方案
团队翻译了一篇由开发人员兼文章Julia Evans撰写的文章，她在其中回答了这些问题，并从前端角度广泛地讨论了DNS更新期间发生的情况。
这是对更新DNS记录时幕后发生情况的快速了解。
DNS的工作方式：递归和权威DNS服务器
首先，我们需要解释一下DNS系统。 DNS服务器有两种类型：权威服务器和递归服务器。
权威DNS服务器（也称为名称服务器）为它们负责的每个域维护IP地址数据库。例如，现在github.com的权威DNS服务器是
ns-421.awsdns-52.com。您可以通过以下请求向他询问github.com IP地址：
dig @ns-421.awsdns-52.com github.com
递归DNS服务器本身对谁拥有哪个IP地址一无所知。他们通过从适当的权威DNS服务器查询来计算域的IP地址，然后缓存该IP地址，以防再次请求该IP地址。因此8.8.8.8是一个递归DNS服务器。
当人们访问您的网站时，他们很可能在递归DNS服务器上进行DNS查找。那么递归DNS服务器如何工作？让我们来看看！
递归DNS服务器如何查询github.com的IP地址
让我们看一个示例，当您请求递归DNS服务器（例如8.8.8.8）的github.com IP地址（A记录）时。首先，如果它已经有一个缓存的结果，它将发出它。但是，如果所有缓存都过期了怎么办？这是怎么回事。
步骤1：将根DNS服务器的IP地址硬编码到其源代码中。您可以在未绑定的源代码中看到这一点。假设他首先选择了198.41.0.4。这是这些硬编码IP地址的正式来源，也称为“根目录提示文件”。
步骤2：向root名称服务器询问有关github.com的信息。
我们可以大致重现命令的内容
dig... 它为我们提供了一个新的权威名称服务器：.comIP地址为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
...
DNS响应的细节更加复杂-在这种情况下，有一个带有一些NS记录的授权部分，另一个带有A记录的部分，因此您不必进行额外的查找即可获取那些名称服务器的IP地址。
实际上，99.99％的时间中已经有一个缓存的名称服务器地址
.com，但是我们假装我们真的是从头开始。
步骤3：向名称服务器
.com询问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
...
我们有一个新的IP地址来发送请求！这是github.com的名称服务器之一。
步骤4：向github.com名称服务器查询github.com地址。
我们快完成了！
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
因此，我们在github.com上有一个A记录。递归服务器现在具有github.com IP地址，可以将其返回给您。而且，他能够完成整个过程，从几个硬编码的IP地址开始：根名称服务器的地址。
如何查看递归DNS服务器的所有步骤：dig + trace
要查看递归DNS服务器将如何解析域，可以运行：
$ dig @8.8.8.8 +trace github.com
该命令显示了递归服务器请求的所有DNS记录，从根DNS服务器开始，这是我们刚刚完成的所有四个步骤。
更新DNS记录
既然我们了解了DNS工作原理，那么让我们更新一些DNS记录，看看会发生什么。
更新DNS记录时，有两个主要选项：
- 保留相同名称的服务器；
- 更改名称服务器。
让我们谈谈TTL
但是我们忘记了一些重要的事情。这是TTL。如前所述，递归DNS服务器将缓存记录，直到记录到期。它根据TTL（生存时间）决定记录的到期时间。
在此示例中，GitHub名称服务器为其DNS记录返回TTL为60，这意味着60秒：
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
这是一个相当短的TTL。从理论上讲，如果所有DNS实施均遵循DNS标准，则意味着如果GitHub决定更改github.com的IP地址，则每个人都将在60秒内收到一个新IP地址。让我们看看在实践中这是如何发生的。
选项1：更新相同名称服务器上的DNS记录
首先，我更新了名称服务器（Cloudflare）以获取一个新的DNS记录，即A记录，该记录映射
test.jvns.ca到1.2.3.4：
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
立即生效！根本不需要等待，因为在此之前，没有
test.jvns.ca可以缓存的DNS记录。优秀的。但是看起来新记录被缓存了大约五分钟（299秒）。
那么，如果我们尝试更改此IP地址怎么办？我将其更改为5.6.7.8，然后运行了相同的DNS查询：
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
看起来在此DNS服务器上1.2.3.4记录仍被缓存144秒。有趣的是，如果多次查询8.8.8.8，您将得到矛盾的结果-有时它为您提供了一个新IP，有时又为您提供了旧IP。大概8.8.8.8实际上将负载分布在许多不同的后端上，每个后端都有自己的缓存。
等待五分钟后，所有8.8.8.8缓存均已更新，并始终返回新的5.6.7.8条目。惊人。非常快！
您不能总是依靠TTL
与大多数Internet协议一样，并非所有内容都遵循DNS规范。某些ISP DNS服务器将缓存记录的时间长于指定的TTL。例如，在两天内而不是五分钟内。人们总是可以在文件中对旧IP地址进行硬编码
/etc/hosts。
在实践中，当使用五分钟的TTL更新DNS记录时，您可以期望很大比例的客户端快速转移到新的IP地址（例如，在15分钟之内），然后会有一大堆落后于未来几天的更新。
选项2：更新您的名称服务器
因此，我们已经看到，在不更改名称服务器的情况下更新IP地址时，许多DNS服务器很快就会获得新的IP地址。优秀的。但是，如果您更改名称服务器会怎样？我们试试吧！
我不想为我的博客更新名称服务器，所以我改用了我的其他域，并在HTTP日志的示例examplecat.com中使用了该域。
以前，我的服务器设置为
dns1.p01.nsone.net。我决定将它们更改为带有地址ns-cloud-b1.googledomains.com等的Google服务器。
进行更改后，我的域名注册商显示了一些不祥的消息：“对examplecat.com的更改已保存。它们将在接下来的48小时内生效。”然后，我为域设置新的A记录，使其指向1.2.3.4。
好吧，让我们看看是否有任何变化：
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
没有变化。如果我询问其他DNS服务器，则它知道新IP：
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
但是8.8.8.8仍然什么都不知道。即使我在五分钟前刚刚更改它，1.1.1.1仍会看到一个新IP的原因可能是因为之前从未有人问过example.com这个例子，所以1.1.1.1却没有任何内容。它是。
名称服务器具有更多的TTL
我的注册服务商说“需要48小时”的原因是因为NS记录上的TTL（有关递归服务器应访问哪个名称服务器的信息）要大得多。
新的名称服务器肯定会为examplecat.com返回一个新的IP地址：
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
但是请记住我们之前查询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
...
172,800秒是48小时！因此，更新名称服务器通常需要更长的时间。缓存过期并传播新地址需要时间。这比仅更新IP地址而不更改名称服务器所需的时间要长得多。
域名服务器的更新方式
当我更新的域名服务器时
examplecat.com，域名服务器.com会获得一个具有新域的新NS记录。像这样：
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
但是这个新的NS记录如何到达那里？实际上，我通过在网站上更新域名告诉域名注册商我想要新的域名服务器的外观，然后域名注册商告诉域名服务器
.com进行更新。
对于
.com这些更新来说，速度相当快（几分钟之内），但我认为对于其他一些TLD区域，名称服务器可能无法尽快应用更新。
您程序的DNS解析程序库也可以缓存DNS记录
实际中可能无法观察到TTL的另一个原因是，许多程序必须解析DNS名称，并且某些程序还将无限期地将DNS记录缓存在内存中（直到重新启动程序）。
例如，有一篇关于为DNS查找设置JVM TTL的文章。我自己没有为DNS查找编写太多JVM代码，但有关JVM和DNS的一些互联网搜索给人的印象是，您可以配置JVM以无限期地缓存每个DNS查找（例如，参见此ElasticSearch故障单） ...
就这样！
希望这可以帮助您了解更新DNS时发生的情况。
我将保留DNS分配的整个历史记录，不仅由TTL决定。一些递归DNS服务器可能不遵守TTL，即使是像8.8.8.8之类的主要服务器也是如此。因此，即使您只是使用较小的TTL更新A记录，实际上还是有可能在一两天内收到对旧IP的请求。
发布本文后，我将examplecat.com的名称服务器改回了原来的值。
还有什么要读的：