我涉足 DNS 设置已经有一段时间了，所以我的知识可能有点过时了。
我们有一个域，其主服务器由我们的团队管理，从属服务器由托管公司提供。在某个时候，我们决定切换到另一家托管公司。与此同时，我们决定主服务器和从属服务器都由我们管理。作为准备此过程的一部分，我们减少了域的刷新、重试和过期参数，以使任何更改传播得更快一些。然后我们将服务器移至新主机，更改区域文件，启动串行并重新加载 DNS 服务器。传播过程在某种程度上是不平衡的。那里的大多数 DNS 服务器都有新数据。然而有些却没有，即使它远远超过了我们的过期设置和（由一些 DNS 管理员强制）默认的一周过期设置。
在调查可能的原因时，我们发现我们的服务器配置错误，只允许从从服务器发出查询。因此，在相当长的一段时间内，对我们服务器的任何外部查询都会失败，但从从服务器可以正常工作。当然，这个问题立即得到了纠正。我们还发现，之前的托管公司仍然保留着我们的从属区域，并响应手动 (nslookup/host) 查询，提供过时的区域视图。
所以我的问题是：旧的从属 DNS 服务器能否以某种方式对不稳定的 DNS 传播负责？如果某个 DNS 服务器达到某个区域的过期/刷新时间，它是否会从顶部（根服务器）一直遍历 DNS 树来获取数据？还是它只是与最近从其获取区域信息的服务器进行检查？
编辑：抱歉没有说清楚，但我自然而然地在注册商级别更改了域的 DNS 条目。如果我使用 nslookup/host 进行非递归查询，并从 TLD 向下查找到我的域，则一切都与应有的一致。但仍有一些 DNS 服务器提供旧区域数据作为非权威答案。
答案1
您根本无法修复拒绝听从 TTL 设置的管理员。所以忘掉这个问题吧，因为它不是您可以解决的问题。
假设无法解决，那么如果您已经完成了所有其他正确的步骤，那么您就无能为力了。您需要非常努力地在小窗口中尽可能同步服务器，但即使这样，也总会有一个小窗口，其中主服务器领先于从服务器。
重要的是，如果你要删除一个从属服务器，请更改区域中的 NS 记录和也更改父区域对 NS 记录的概念。请务必记住，您的父区域有 NS 记录的副本以及与这些 NS 记录关联的相关“粘合剂”（IP 地址）。如果您尚未更改父区域的观念，那么这可能是导致问题的原因。
答案2
DNS 不会传播。您之前主机上的从属服务器影响您域名的名称解析的唯一方式是，它是否仍列为您的域名的名称服务器。检查您域名的 WHOIS 信息，并检查您的域名注册商，以查看您的域名列出了哪些名称服务器。如果列出了旧的从属服务器，则需要修复它。一旦您的名称服务器被列为唯一名称服务器，您就没问题了。至于其他 DNS 服务器不遵守您的 TTL，您对此无能为力。至于托管您域名区域的从属服务器，只要它们不是您域名的权威服务器，那就无关紧要了。
如果愿意，我可以为 Microsoft 和 Google 托管 DNS 区域，但这只对使用我的 DNS 服务器进行名称解析的 DNS 客户端有影响。如果任何 DNS 客户端使用从属服务器，并且从属服务器仍为您的域提供权威性答案，那么它将影响这些客户端对您的域的名称解析，但所有其他 DNS 客户端将不受影响。
答案3
运行dig +trace NS your.domain.com然后询问您上方的每个名称服务器对 your.domain.com 的名称服务器的看法。以 att.com 为例：
$ dig NS +trace att.com
; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> NS +trace att.com
;; global options: +cmd
. 395258 IN NS d.root-servers.net.
. 395258 IN NS e.root-servers.net.
. 395258 IN NS c.root-servers.net.
. 395258 IN NS f.root-servers.net.
. 395258 IN NS m.root-servers.net.
. 395258 IN NS g.root-servers.net.
. 395258 IN NS l.root-servers.net.
. 395258 IN NS a.root-servers.net.
. 395258 IN NS k.root-servers.net.
. 395258 IN NS j.root-servers.net.
. 395258 IN NS b.root-servers.net.
. 395258 IN NS h.root-servers.net.
. 395258 IN NS i.root-servers.net.
;; Received 508 bytes from 212.2.96.53#53(212.2.96.53) in 213 ms
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 190 ms
att.com. 172800 IN NS ns3.attdns.com.
att.com. 172800 IN NS ns2.attdns.com.
att.com. 172800 IN NS ns1.attdns.com.
;; Received 134 bytes from 192.48.79.30#53(j.gtld-servers.net) in 420 ms
att.com. 3600 IN NS ns1.attdns.com.
att.com. 3600 IN NS ns3.attdns.com.
att.com. 3600 IN NS ns2.attdns.com.
att.com. 3600 IN NS ns4.attdns.com.
;; Received 168 bytes from 144.160.20.47#53(ns3.attdns.com) in 210 ms
这里 j.gtld-servers.net 表示 att.com 的名称服务器是 ns[123].attdns.com，而 ns3.attdns.com 表示实际上还有第四个。如果您向 com. 的所有名称服务器询问 att.com 的 NS 记录。（dig NS att.com @a.gtld-servers.net.然后dig NS att.com @b.gtld-servers.net.等等）您将全面了解正确配置的客户端在请求您的域的名称服务器时可以收到什么。
然后询问您域名的每个实际名称服务器（示例中为 ns[1234].attdns.com.），他们对其域名（示例中为 att.com）的 NS 记录有何看法，这样您就会得到完整的了解。
这可能有点乏味，但如果您得到的所有答案都是合理的，那么您的配置显然是正确的。您尽了自己的一份力量来缩短过渡阶段，最终一切都会好起来，但您无法对 ISP 故意忽略 DNS 条目的 TTL 以降低其服务器的负载采取任何措施。
答案4
如上所述，其他答案实际上并不完全准确。因此，回答你的问题：
旧的从属 DNS 服务器是否会以某种方式导致不稳定的 DNS 传播？
是的，它可以，大约是因为你亲自识别并用“我看到的效果”代替了“不稳定传播”（这不是正在发生的事情）：
如果某个 DNS 服务器达到某个区域的到期/刷新时间，它是否从 DNS 树的顶部（根服务器）开始遍历整个过程来获取数据？还是它只是与最近从其获取区域信息的服务器进行核对？
除了进行 DNS 查询的人不会下载整个区域，以及过期/刷新时间与此无关之外，您的想法是正确的。已经查询过您的域及其子域的 DNS 信息的人将收到该域的委托信息。在达到该信息的 TTL 之前，他们将继续直接与他们知道的内容 DNS 服务器对话；如果他们继续与您的旧 DNS 托管服务对话，他们将继续每次都被告知旧的委托信息和新的 TTL。
这是一个可以无限持续的循环。 这就是为什么需要说明如何将委派从一组内容 DNS 服务器切换到另一组内容 DNS 服务器，例如这些说明和这些说明除其他外，强调重要的是不要忽略更新旧服务器的委托信息 —全部其中 — 发布。
你有与您的旧托管公司联系并让其更新其发布的内容。