Dig + traceは常に正確ですか？
DNSキャッシュの正確さが問題である場合、Dig +traceは、インターネットに面したDNSレコードの信頼できる回答を決定するための推奨される方法です。これは、グルーレコードも表示する+additionalと組み合わせて使用すると特に便利なようです。
時々、この点でいくつかの意見の相違があるようです-一部の人々は、中間ネームサーバーのIPアドレスを検索するためにローカルリゾルバーに依存していると言いますが、コマンド出力はこれがルートの最初のリストを超えて起こっていることを示していませんネームサーバー。 +traceの目的がルートサーバーから開始し、追跡することである場合、これは当てはまらないと考えるのは当然のようです。 （少なくともルートネームサーバーの正しいリストがある場合）
Dig +traceは本当に、ルートネームサーバーを過ぎて何かに対してローカルリゾルバーを使用しますか？
これは明らかに段階的なQ＆Aですが、 これはしばしば人々を混乱させる傾向があります であり、トピックをカバーする標準的な質問を見つけることができません。
Dig +traceは優れた診断ツールですが、設計の1つの側面は広く誤解されています。照会されるすべてのサーバーのIPはリゾルバーライブラリから取得されます。これは見過ごされがちで、ローカルキャッシュにネームサーバーのwrong回答がキャッシュされている場合にのみ問題になることがよくあります。
詳細分析
これは出力のサンプルで簡単に分解できます。最初のNSの委任以降はすべて省略します。
; <<>> Dig 9.7.3 <<>> +trace +additional serverfault.com
;; global options: +cmd
. 121459 IN NS d.root-servers.net.
. 121459 IN NS e.root-servers.net.
. 121459 IN NS f.root-servers.net.
. 121459 IN NS g.root-servers.net.
. 121459 IN NS h.root-servers.net.
. 121459 IN NS i.root-servers.net.
. 121459 IN NS j.root-servers.net.
. 121459 IN NS k.root-servers.net.
. 121459 IN NS l.root-servers.net.
. 121459 IN NS m.root-servers.net.
. 121459 IN NS a.root-servers.net.
. 121459 IN NS b.root-servers.net.
. 121459 IN NS c.root-servers.net.
e.root-servers.net. 354907 IN A 192.203.230.10
f.root-servers.net. 100300 IN A 192.5.5.241
f.root-servers.net. 123073 IN AAAA 2001:500:2f::f
g.root-servers.net. 354527 IN A 192.112.36.4
h.root-servers.net. 354295 IN A 128.63.2.53
h.root-servers.net. 108245 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 355208 IN A 192.36.148.17
i.root-servers.net. 542090 IN AAAA 2001:7fe::53
j.root-servers.net. 354526 IN A 192.58.128.30
j.root-servers.net. 488036 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 354968 IN A 193.0.14.129
k.root-servers.net. 431621 IN AAAA 2001:7fd::1
l.root-servers.net. 354295 IN A 199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms
. IN NS（ルートネームサーバー）の最初のクエリは、ローカルリゾルバー（この場合はComcast）にヒットします。 （75.75.75.75）これは簡単に見つけられます。- 次のクエリは
serverfault.com. IN Aに対するものであり、取得したルートネームサーバーのリストからランダムに選択されたe.root-servers.net.に対して実行されます。192.203.230.10というIPアドレスがあり、+additionalが有効になっているので、接着剤から来ているように見えますと表示されます。 - Serverfault.comに対する権限がないため、これは
com.TLDネームサーバーに委任されます。 - ここの出力から明らかでないのは、
Digがe.root-servers.net.のIPアドレスをグルーから導き出さなかったことです。
バックグラウンドで、これは実際に起こったことです：
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)
+traceは、接着剤を調べる代わりに、ローカルリゾルバをだまして調べ、次のホップのネームサーバーのIPアドレスを取得しました。卑劣！
これは通常「十分」であり、ほとんどの人にとって問題にはなりません。残念ながら、エッジのケースがあります。何らかの理由でアップストリームDNSキャッシュがネームサーバーに間違った答えを提供している場合、このモデルは完全に機能しなくなります。
実世界の例：
- ドメインが期限切れになる
- 接着剤はレジストラリダイレクトネームサーバーで再ポイントされます
- 偽のIPがns1とns2.yourdomain.comにキャッシュされます
- ドメインは、復元された接着剤で更新されます
- 偽のネームサーバーIPを持つキャッシュは、ドメインが販売されていると言うウェブサイトに人々を送り続けます
上記の場合、+traceは、ドメイン所有者自身のネームサーバーが問題の原因であることを示唆しているため、サーバーが正しく設定されていないことを顧客に誤って伝えることは1度だけです。それがあなたが何かをすることができる（または喜んで）何かであるかどうかは別の話ですが、正しい情報を持っていることが重要です。
Dig +traceは優れたツールですが、他のツールと同様に、ツールの機能と機能、および不十分であることが判明した場合に手動で問題をトラブルシューティングする方法を知る必要があります。
編集：
Dig +traceは、NSaliasesを指すCNAMEレコードについて警告しないことにも注意してください。これはISC BIND（および場合によってはその他）が修正しようとしないRFC違反です。 +traceは、ローカルに構成されたネームサーバーから取得したAレコードを完全に受け入れますが、BINDが完全な再帰を実行する場合は、SERVFAILでゾーン全体を拒否します。
接着剤が存在する場合、トラブルシューティングが難しい場合があります。これは問題なく動作します NSレコードが更新されるまで 、その後突然中断します。グルーレスな委任は常にですNSレコードがエイリアスを指している場合にBINDの再帰を中断します。
ルートネームサーバーを見つける以外の方法でローカルリゾルバーを使用せずにDNS解決をトレースする別の方法は、 dnsgraph を使用することです（完全な開示：私はこれを書きました）。コマンドラインツールとWebバージョンがあり、インスタンスは http://ip.seveas.net/dnsgraph/ で見つけることができます。
現時点で実際にDNSの問題があるserverfault.comの例：
このスレッドには非常に遅れていますが、なぜDig + traceがローカルリゾルバーへの再帰クエリを使用するのかについての質問の一部は直接説明されておらず、この説明はDig + traceの結果の精度に関連しています。
ルートゾーンのNSレコードの最初の再帰クエリの後、Digは次の条件でローカルリゾルバに後続のクエリを発行する場合があります。
次の反復クエリの応答のサイズが512バイトを超えるため、参照応答は切り捨てられます
Digは、対応するAレコード（接着剤）がADDITIONALセクションにない参照応答のAUTHORITYセクションからNSレコードを選択します
DigはNSレコードからのドメイン名のみを持っているので、DigはローカルDNSサーバーにクエリを実行して名前をIPアドレスに解決する必要があります。これが根本的な原因です（ごめんなさい、申し訳ありません）。
AndrewBは、ルートゾーンNSレコードが選択されているという点で、先ほど説明した内容と完全には一致していません。
_. 121459 IN NS e.root-servers.net._
対応するAレコードがあります。
_e.root-servers.net. 354907 IN A 192.203.230.10_
ただし、e-rootには対応するAAAAレコードがなく、他の一部のルートサーバーにはAAAAレコードがないことに注意してください。
また、応答のサイズにも注意してください。
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
切り捨てられた応答の一般的なサイズは496バイトです（つまり、次のグルーレコードは16バイトより大きくなり、512バイトを超える応答になります）。言い換えると、NSレコードのクエリでは、完全なAUTHORITYと完全なADDITIONAL（AとAAAAレコードの両方））が512バイトを超えるので、 EDNS0オプションを介してより大きなクエリサイズを指定すると、上記のトレースが示すように、ADDITIONALセクションのどこかで途切れる応答が得られます（f、h、i、j、およびkのみがAおよびAAAAグルーレコードを持っています）。
E.root-servers.netのAAAAレコードの欠如と「NS」への応答のサイズ。 queryは、私が主張している理由により、次の再帰クエリが実行されたことを強く示唆しています。おそらく、クライアントのO/SはIPv6対応であり、AAAAレコードを好む-またはその他の理由がある。
しかし、いずれにしても、このスレッドを読んだ後、Dig + traceがrootの最初のクエリの後に再帰クエリを実行する現象を調べました。 NSレコードに対応するグルーA/AAAAレコードなしで選択してから、そのレコードの再帰クエリをローカルDNSに送信することの間の対応は、私の経験では100％です。逆はtrue-紹介から選択されたNSレコードに対応するグルーレコードがある場合、私は再帰クエリを見ていません。