我见过很多人对更新他们网站的DNS记录来更改IP地址感到困惑。为什么会慢呢？你真的要等2天才能更新所有东西吗？为什么有些人看到新IP，有些人看到旧IP？发生什么事了呢？
所以我想写一篇关于当您更新DNS记录时幕后发生的事情的快速探索。
首先，我们需要稍微解释一下DNS。DNS服务器有两种：权威性和递归性。
权威DNS服务器(也称为名称服务器)有一个数据库，其中包含它们负责的每个域的IP地址。例如，现在github.com的权威DNS服务器是ns-421.awsdns-52.com。您可以这样向它索要github.com的IP；
递归DNS服务器本身并不知道谁拥有什么IP地址。他们通过询问正确的权威DNS服务器来找出域的IP地址，然后缓存该IP地址，以防再次被询问。8.8.8.8是递归DNS服务器。
当人们访问您的网站时，他们可能正在向递归DNS服务器进行DNS查询。那么，递归DNS服务器是如何工作的呢？让我们看看!。
让我们来看一个例子，当您向递归DNS服务器(如8.8.8.8)请求github.com的IP地址(A记录)时，它会做些什么。首先，如果它已经缓存了一些内容，它会给您提供它已经缓存的内容。但是如果它所有的缓存都过期了呢？以下是发生的情况：
步骤1：它在源代码中硬编码了根DNS服务器的IP地址。您可以在Unbinded的源代码中看到这一点。假设它首先选择198.41.0.4。以下是这些硬编码IP地址的官方来源，也称为“根提示文件”。
我们可以粗略地重现挖掘过程中发生的事情。这给我们提供了一个新的权威域名服务器来询问：.com的域名服务器，IP为192.5.6.30。
DNS响应的细节要稍微复杂一些-在本例中，有一个包含一些NS记录的AUTHORITY部分和一个包含A记录的附加部分，因此您不需要进行额外的查找即可获得这些名称服务器的IP地址。
(实际上，99.99%的情况下它已经缓存了.com域名服务器的地址，但我们假装我们真的是从头开始)。
我们有一个新的IP地址要问！这是github.com的名称服务器。
万岁！！我们为github.com创造了A级的记录！现在，递归名称服务器拥有github.com的IP地址，可以将其返回给您。而且它只需硬编码几个IP地址：根名称服务器的地址，就可以完成所有这些工作。
当我想要查看递归DNS服务器在解析adomain时将执行什么操作时，我运行。
这将显示它请求的所有DNS记录，从根DNSservers开始-我们刚刚经历的所有4个步骤。
现在我们已经了解了DNS工作原理的基础知识，让我们更新一些DNS记录，看看会发生什么。
不过，我们忘了一些重要的事情！TTLS！您知道我们前面是怎么说的吗？递归DNS服务器将缓存记录，直到它们过期。它决定记录是否应该过期的方式是通过查看TTL或“活着的时间”。
在本例中，GitHub的名称服务器为其DNS记录返回的A记录的TTL为60，这意味着60秒：
这是一个相当短的TTL，从理论上讲，如果每个人的DNS实现都遵循DNS标准，这意味着如果Github决定更改github.com的IP地址，每个人都应该在60秒内获得新的IP地址。让我们看看这在实践中是如何发挥作用的。
首先，我更新了名称服务器(Cloudflare)以拥有一个新的DNS记录：将test.jvns.ca映射到1.2.3.4的A记录。
这立即奏效了！根本不需要等待，因为在缓存之前没有test.jvns.ca DNS记录。太棒了。但是看起来新记录被缓存了大约5分钟(299秒)。
那么，如果我们尝试更改该IP呢？我将其更改为5.6.7.8，然后运行相同的DNS查询。
嗯，看起来DNS服务器的1.2.3.4记录还缓存了144秒。有趣的是，如果我多次查询8.8.8.8，实际上得到的结果并不一致--有时会给我新的IP，有时会给我旧的IP，我猜这是因为8.8.8.8实际上会将负载平衡到一组不同的后端，每个后端都有自己的缓存。
我等了5分钟后，所有的8.8.8.8缓存都更新了，并且总是返回新的5.6.7.8记录。太棒了。那真是太快了！
与大多数互联网协议一样，并不是所有的东西都遵循DNS规范。一些ISP DNS服务器缓存记录的时间会比TTL指定的时间更长，比如2天而不是5分钟。而且人们总是可以在他们的/etc/hosts中硬编码旧的IP地址。
在实践中，当使用5分钟的TTL更新DNS记录时，我预计会发生的情况是，很大比例的客户端将转移到新的IPsquickly(比如在15分钟内)，然后会有一大批落后者在接下来的几天里慢慢更新。
我们已经看到，当您在不更改名称服务器的情况下更新IP地址时，很多DNS服务器会非常快地获取新的IP。太棒了。但是，如果您更改了您的命名服务器，会发生什么情况呢？让我们试一试吧！
我不想更新我的博客的名称服务器，所以我使用了我拥有的另一个域名，并在HTTPzine的示例中使用：examplecat.com。
以前，我的名称服务器设置为dns1.p01.nsone.net。我决定将它们切换到Google的名称服务器-ns-cloud-b1.googledomains.com等。
当我进行更改时，我的域名注册商有点不祥地弹出了主题消息-“对examplecat.com的更改已保存。它们将在接下来的48小时内生效“。然后，我为该域设置了一个新的A记录，使其指向1.2.3.4。
但8.8.8.8仍然毫无头绪。尽管我在5分钟前刚刚更换了新IP，1.1.1.1仍然会看到它的原因可能是之前没有人查询过1.1.1.1关于examplecat.com的信息，所以它的缓存中没有任何东西。
我的注册员说“这将需要48小时”的原因是TTLson NS记录(递归名称服务器如何知道要询问哪个名称服务器)要长得多！
172800秒就是48小时！因此，与只更新IP地址而不更改名称服务器相比，名称服务器更新通常需要更长的时间才能从缓存中过期并传播。
当我更新examplecat.com的名称服务器时，发生的情况是.com名称服务器获得新域的新NS记录。就像这样：
但是，新的NS记录是如何做到这一点的呢？发生的事情是，我通过在网站上更新来告诉域名注册商我想要的新域名服务器是什么，然后我的域名注册商告诉.com域名服务器进行更新。
对于.com，这些更新发生得相当快(在几分钟内)，但我认为对于其他一些TLD，TLD名称服务器可能不会那么快地应用更新。
TTLS在实践中可能得不到尊重的另一个原因是：许多程序需要解析DNS名称，一些程序还会在内存中无限期地缓存DNS记录(直到程序重新启动)。
例如，AWS有一篇关于为DNS NameLookup设置JVM TTL的文章，我自己还没有编写那么多执行DNS查找的JVM代码，但是从少量关于JVM和DNS的搜索可以看出，您似乎可以配置JVM，使其无限期地缓存每个DNS查找。(比如这期ElasticSearch)。
我希望这能帮助您了解更新DNS时发生的事情！
作为免责声明，再次声明-TTL绝对不能说明有关DNS传播的全部内容-一些递归DNS服务器肯定不尊重TTL，即使像8.8.8.8这样的主要服务器也是如此。所以，即使你只是用一个短的TTL来更新A记录，很有可能在实践中，你仍然会在一两天内收到对旧IP的请求。
此外，在发布这篇文章后，我将examplecat.com的名称服务器改回了原来的值。