正确计算来自主机-a输出的DNS TTL

我试图找出如何在DNS中处理TTL(最后我试图找出切换域的最快方法),但不知何故,我被困在解释TTL值。

例如,我今天移动了一个具有以下DNSlogging的域名,然后将其移到我的位置:

主机-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秒之后parsing到我的服务器(因为我正在改变NS和Alogging)。

正如我移动上述域名,收到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的尊重。

我肯定错过了什么。 但我想不出来 – 请问有谁能给我一个提示吗?

问题是SOAlogging的TTL,所以在进行切换之前必须降低这个值?


编辑

dig + trace +其他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 

我不能肯定地回答,因为你正在使用混淆域,但是当你改变apex NSlogging时,validation你的NSlogging和相应的粘合logging的TTL也是很重要的。 应该预料,旧名称服务器将继续查看整个持续时间的查询。 考虑到你正在运行的testing,这将是最可能的问题。

作为背景,我会引导你走向现在的问答。 接受的答案链接到RFC2181(我经常使用它,因为它是专为人类消费而devise的):
NS域logging在DNS域的顶点有什么作用?

我相信这里发生的事情是,你的胶水logging被动caching。 之所以这从你的validation不明显的原因是,一个明确的查询NSAlogging往往会触发权威性的查询,如果还没有制定。 基本上,胶水被动地受到尊重,直到TTL到期,或有人明确要求logging。

确认最简单的方法是运行: dig +trace +additional example.com