我目前正在尝试使用Google Cloud DNS将具有临时IP的Compute Engine VM映射到主机名，该操作在VM启动时进行。我正在通过如下的shell脚本执行此操作：
gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE \
--name subd.domain.com \
--type A "1.2.3.4" \ #the old external ip for the VM
--ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE \
--name subd.domain.com \
--type A "5.6.7.8" \ #the new external ip for the VM
--ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE
运行脚本后，我可以在Cloud DNS UI中看到记录已成功更改，其中“ A” RR具有新的外部IP。
现在发生的事情是这些更改真正生效需要很长时间。更改后访问主机名“ subd.domain.com”将返回“ NXDOMAIN”状态，该状态会持续很长时间，只有在此之后，它最终会将域映射到新IP。
这种情况对我提出了两个问题：
＃1 为什么DNS会通过NXDOMAIN阶段？这些更改不应该充当Update（由于在事务中运行此操作）而不是Remove，然后充当Create.
＃2 是什么决定此记录更新生效的时间？
答案 0 :(得分：2)
我将基于数十年的DNS经验提供此建议。不要将DNS视为您的按需数据库。 DNS生态系统并非旨在支持您尝试做的事情。链中的每个链接都缓存DNS条目。您无法控制此过程。在您的示例中，TTL为300秒。您上方的下一个服务器至少要等5分钟，您的条目才会过期。许多缓存会忽略您的TTL，并将其设置为几小时甚至几天。您需要将DNS设置设计为“最终一致”而不是“即时一致”。最终意味着几小时或几天。
在计划DNS更改时，我计划至少48小时使更改生效。这意味着我们在旧的DNS条目上维护服务，而新的DNS条目生效。
答案 1 :(得分：1)
DNS更改以几种不同的方式传播（传播）。随着DNS的发展，这些不同的方式也在发展，可以在各种RFC（https://www.isc.org/community/rfcs/dns/）中找到。
在您的示例中，您尝试更改“ domain.com” DNS区域中资源的A记录（将IP地址映射到名称）。您正在显示的方法首先删除旧记录，然后使用“事务”添加新记录。使用“交易”的方式是Google的Cloud DNS产品所独有的，不是已记录的RFC的一部分，并且可能（也可能不会）影响成功解决问题的速度。 （附带说明，在我的测试中，即使一个事务包括多个DNS更改，它也只会使SOA序列增加1）
首先，对我来说是技术方面的简短回顾。
有几台服务器充当该区域（domain.com）记录的“权威”来源。那些权威的服务器是该区域的NS记录中列出的服务器。这些是当浏览器中的某人试图浏览至该名称或尝试对其进行ping操作时将回答请求的服务器。当某人ping或某人尝试在浏览器中对其进行访问时，访问这些服务器的方式是高度可变的以及超出此答案的范围（Google表示“客户端DNS解析”）
通常，Google Cloud DNS将为您提供四台权威服务器，其名称例如为任何新创建的区域：
DNS名称查询实用程序（例如“ dig”或“ nslookup”）可用于分别查询每个权威服务器的状态。
现在，当您运行“ gcloud dns ...”命令来删除和/或添加记录时，它不是在使用记录在案的DNS方法来促进将记录传输到所有权威服务器。从测试中可以看出，最好的办法是先使用您的更改来更新一些中央数据库，然后再启动一个更新服务器本身的过程（也许使用DNS样式通知？）。可以从以下事实看出这一点：Google Cloud DNS UI有时可以在任何权威服务器实际注册您的交易更改之前显示您的更新。
接下来，由于更改是由一组权威服务器发送和/或提取的，因此似乎需要一段时间才能在每个服务器上完全变得一致。 （Zach Bjornson在http://blog.zachbjornson.com/2018/08/14/dns-propagation.html上发布了有关使用GCP和AWS进行DNS记录添加的时间的分析，以及用于自己执行分析的代码。）
其中一张图表显示了达到一致性的时间： Time for GCP DNS Servers to Update
尽管上面列出的四台服务器（ns-cloud-xxx ...）都只有一个IP地址，但是它们是任播IP，这意味着它们可以位于多个数据中心的多个网络中。因此，尽管ns-cloud-a1.googledomains.com解析为216.239.32.106，但该IP可能存在于迈阿密，坦帕，奥兰多，亚特兰大和其他几个地方的服务器上。当您尝试与之通信时，流所经过的网络会将您带到最近的网络（感谢@BGP！）。在我的测试中（针对运行与您发布的交易类似的交易的域，每个发布的googledomains.com域名服务器每秒运行20次挖掘），看来更改缓慢收敛，这意味着在最初的几秒钟内，是旧IP（已删除的IP），然后dig请求开始显示它正在更改，但可能只有40个或50个显示新IP的请求中的一个。在接下来的大约一分钟内，越来越多地返回新IP，直到100％的请求都显示了新IP。
在有限的测试中，我从未收到用于测试记录的NXDOMAIN，所有（数千个）请求都返回了旧IP或新IP，以用于记录。
现在，此时，所有权威服务器都已收敛到“ subd.domain.com”的A记录的新IP地址。 DNS解析器或客户端可能具有某种本地缓存，用于最小化对频繁请求的记录的网络请求。这些客户端中的一些会遵守所请求记录的TTL（生存时间），但有些则不会（我尚未看到与IMHO实现的很多一致性）。 TTL是“建议”，要求记录的人员可以遵循TTL，以确保他们在最小化网络流量和确保记录值的准确性之间达到良好的平衡。因此，现在，客户端可能已经为TTL缓存了旧记录，因此它可能需要在尝试再次请求记录之前过期。在您的示例中，TTL为300，即300秒，即5分钟，因此您最多可能需要等待5分钟。
