ホスト-a出力からDNS TTLを正しく計算する
DNSでTTLがどのように処理されるかを理解しようとしていますが（最終的にはドメインを切り替える最速の方法を理解しようとしています）、どういうわけかTTL値の解釈に行き詰まっています。
たとえば、今日、次のDNSレコードを持つドメインを移動してから移動しました。
ホスト-aexample.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が尊重されることを節約できると思います。
私は何かが足りないに違いない。しかし、私はそれを理解することはできません-誰かが私にここでヒントを与えることができますか？
問題はTTLレコードのSOAなので、切り替えを行う前にこれを下げる必要がありますか？
[〜＃〜]編集[〜＃〜]
Dig + 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
難読化されたドメインを使用しているため、はっきりとは答えられませんが、頂点のNSレコードを変更するときは、のTTL）を確認することも重要です。 NSレコードと対応するglueレコードを参照します。古いネームサーバーは、クエリを全期間表示し続けることが予想されます。これは、実行しているテストを考えると、私にとって最も可能性の高い問題です。
背景として、私がしばらく前に行った既存のQ＆Aに向けてあなたを導きます。受け入れられた回答はRFC2181にリンクしています（人間が消費するように設計されているため、私は頻繁に使用します）：
NS DNSドメインの頂点にあるレコードの役割は何ですか？
ここで起こっていることは、あなたの接着剤レコードが受動的にキャッシュされていたということだと思います。これが検証から明らかでない理由は、NSおよびAレコードの明示的なクエリが、まだ作成されていない場合、信頼できるルックアップをトリガーすることが多いためです。基本的に、接着剤は、TTLが期限切れになるか、誰かが明示的にレコードを要求するまで、受動的に尊重されます。
確認する最も簡単な方法は、これを実行することです：Dig +trace +additional example.com