我试图弄清楚 DNS 中如何处理 TTL（最后我试图找出切换域的最快方法），但不知何故我陷入了解释 TTL 值的困境。
例如，我今天移动了一个域名，在将其移动给我之前，该域名具有以下 DNS 记录：
主机 -a example.com ns.old-provider.net
Trying "example.com"
Using domain server:
Name: ns.old-provider.net
Address: 0.0.0.0#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45674
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;example.com. IN ANY
;; ANSWER SECTION:
example.com. 3600 IN NS ns9.old-provider.net.
example.com. 3600 IN NS ns.old-provider.net.
example.com. 180 IN MX 10 mail.example.com.
example.com. 3600 IN NS ns8.old-provider.net.
example.com. 180 IN A 0.0.0.0
example.com. 3600 IN SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600
;; ADDITIONAL SECTION:
ns8.old-provider.net. 86400 IN A 0.0.0.0
ns9.old-provider.net. 3600 IN A 0.0.0.0
ns.old-provider.net. 86400 IN A 0.0.0.0
mail.example.com. 180 IN A 0.0.0.0
Received 258 bytes from 0.0.0.0#53 in 31 ms
我对上述输出的解释是，该域名应在最多 3600 秒后解析到我的服务器（因为我正在更改 NS 和 A 记录）。
由于我确实移动了上述域名，在收到 TRANSFER ACK 3 小时后它仍然解析到错误的 DNS 服务器：
host -a example.com 8.8.8.8
[...]
;; ANSWER SECTION:
example.com. 179 IN A 0.0.0.0
example.com. 3599 IN NS ns9.old-provider.net.
example.com. 3599 IN NS ns.old-provider.net.
example.com. 179 IN MX 10 mail.example.com
example.com. 3599 IN NS ns8.old-provider.net.
example.com. 3599 IN SOA ns.old-provider.net. info.old-provider.net. 2015012001 14400 3600 604800 3600
正如您所看到的，我正在使用 Google DNS 服务器进行检查，因此我猜测可以确保 TTL 得到尊重。
我肯定漏掉了什么。但我就是想不通——有人能给我点提示吗？
问题是否出在 SOA 记录的 TTL 上，因此在进行切换之前必须将其降低？
编辑
挖掘 +trace +additional example.com @8.8.8.8
; <<>> DiG 9.8.1-P1 <<>> +trace +additional example.com @8.8.8.8
;; global options: +cmd
. 1024 IN NS c.root-servers.net.
. 1024 IN NS i.root-servers.net.
. 1024 IN NS j.root-servers.net.
. 1024 IN NS d.root-servers.net.
. 1024 IN NS f.root-servers.net.
. 1024 IN NS g.root-servers.net.
. 1024 IN NS k.root-servers.net.
. 1024 IN NS a.root-servers.net.
. 1024 IN NS h.root-servers.net.
. 1024 IN NS l.root-servers.net.
. 1024 IN NS b.root-servers.net.
. 1024 IN NS e.root-servers.net.
. 1024 IN NS m.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 30 ms
de. 172800 IN NS z.nic.de.
de. 172800 IN NS f.nic.de.
de. 172800 IN NS a.nic.de.
de. 172800 IN NS l.de.net.
de. 172800 IN NS s.de.net.
de. 172800 IN NS n.de.net.
a.nic.de. 172800 IN A 194.0.0.53
a.nic.de. 172800 IN AAAA 2001:678:2::53
f.nic.de. 172800 IN A 81.91.164.5
f.nic.de. 172800 IN AAAA 2a02:568:0:2::53
l.de.net. 172800 IN A 77.67.63.105
l.de.net. 172800 IN AAAA 2001:668:1f:11::105
n.de.net. 172800 IN A 194.146.107.6
n.de.net. 172800 IN AAAA 2001:67c:1011:1::53
s.de.net. 172800 IN A 195.243.137.26
z.nic.de. 172800 IN A 194.246.96.1
;; Received 343 bytes from 2001:500:2f::f#53(2001:500:2f::f) in 179 ms
example.com. 86400 IN NS ns9.old-provider.net.
example.com. 86400 IN NS ns8.old-provider.net.
example.com. 86400 IN NS ns.old-provider.net.
;; Received 93 bytes from 0.0.0.0#53(0.0.0.0) in 39 ms
example.com. 180 IN A 0.0.0.0
;; Received 45 bytes from 0.0.0.0#53(0.0.0.0) in 29 ms
答案1
我无法肯定地回答，因为您使用的是模糊域名，但是当您更改顶点NS记录时，验证引用NS记录和相应粘合记录的 TTL 也很重要。应该预期旧名称服务器将在整个持续时间内继续看到查询。考虑到您正在运行的测试，这对我来说是最有可能的问题。
作为背景，我将引导您查看我之前做过的一个现有问答。已接受的答案链接到 RFC2181（我经常使用它，因为它是为人类使用而设计的）：
DNS 域顶端的 NS 记录起什么作用？
我认为这里发生的事情是您的胶合记录被被动缓存。从您的验证中看不出这一点的原因是，如果尚未进行权威查询，则对NS和A记录的显式查询通常会触发权威查询。基本上，胶合记录会被动地被尊重，直到 TTL 过期或有人明确请求该记录为止。
最简单的确认方法是运行以下命令：
dig +trace +additional example.com