dig + traceは常に正確ですか？

DNSキャッシュの精度に問題がdig +traceある場合、DNSレコードに直面しているインターネットの信頼できる回答を決定する方法として推奨される傾向があります。これ+additionalは、グルーレコードも表示するともペアになっている場合に特に便利なようです。

時折、この点について意見の相違があるようです-中間ネームサーバーのIPアドレスを検索するのにローカルリゾルバーに依存していると言う人もいますが、コマンド出力では、これがルートの初期リストを超えて発生していることを示していませんネームサーバー。目的が+traceルートサーバーで開始し、追跡することである場合、これは当てはまらないと仮定するのは論理的なようです。（少なくともルートネームサーバーの正しいリストがある場合）

ないdig +trace本当にルートネームサーバの過去何のためのローカルリゾルバを使うのか？

これは明らかに段階的なQ＆Aですが、これは人々をしばしば混乱させる傾向があり、トピックをカバーする標準的な質問を見つけることができません。

dig +traceは優れた診断ツールですが、その設計の1つの側面は広く誤解されています。照会されるすべてのサーバーのIPは、リゾルバーライブラリから取得されます。これは非常に簡単に見落とされ、ローカルキャッシュにキャッシュされたネームサーバーに対する間違った答えがある場合にのみ問題になることがよくあります。

詳細分析

これは、出力のサンプルで簡単に分類できます。最初の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.されます。IPアドレスは192.203.230.10であり、+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は、ドメイン所有者自身のネームサーバーが問題の原因であり、サーバーが誤って設定されていることを顧客に誤って伝えることから離れるだけです。それがあなたが何かできるか（または喜んで）するかどうかは別の話ですが、適切な情報を持つことが重要です。

dig +trace は素晴らしいツールですが、他のツールと同様に、それが何をして何をしないか、そしてそれが不十分であることが判明したときに問題を手動でトラブルシューティングする方法を知る必要があります。

編集：

また、エイリアスを指すレコードdig +traceについて警告しないことに注意してください。これはRFC違反であり、ISC BIND（および場合によってはその他）は修正を試みません。ローカルに設定されたネームサーバーから取得したレコードを受け入れることは完全に幸せですが、BINDが完全な再帰を実行する場合、SERVFAILでゾーン全体を拒否します。NSCNAME+traceA

接着剤が存在する場合、これはトラブルシューティングが難しい場合があります。NSレコードが更新されるまでこれは問題なく機能し、その後突然壊れます。グルーレスデリゲーションは、レコードがエイリアスを指す場合、常に BINDの再帰を中断しNSます。

ルートネームサーバーを見つけること以外にローカルリゾルバを使用せずにDNS解決をトレースする別の方法は、dnsgraphを使用することです（完全開示：これを書きました）。コマンドラインツールとWebバージョンがあり、http：//ip.seveas.net/dnsgraph/でインスタンスを見つけることができます。

現在DNSの問題が実際にあるserverfault.comの例：

このスレッドには非常に遅れていますが、dig + traceがローカルリゾルバに再帰クエリを使用する理由に関する質問の一部は直接説明されていないと思います。この説明はdig + traceの結果の精度に関連しています。

ルートゾーンのNSレコードに対する最初の再帰クエリの後、digは、次の条件下でローカルリゾルバに後続のクエリを発行する場合があります。

1. 次の反復クエリで応答のサイズが512バイトを超えるため、参照応答が切り捨てられます

2. digは、ADDITIONALセクションに対応するAレコード（接着剤）が欠落している紹介応答の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バイトを超えるため、UDNベースのクエリはEDNS0オプションで大きなクエリサイズを指定しません。上記のトレースが示すように、ADDITIONALセクションのどこかで切断される応答を取得します（fおよびh、i、j、およびkのみがAおよびAAAAグルーレコードを持っています）。

e.root-servers.netのAAAAレコードの欠如と「NS」への応答のサイズ queryは、私が主張している理由で次の再帰クエリが実行されたことを強く示唆します。おそらく、クライアントO / SはIPv6対応であり、AAAAレコードまたは他の何らかの理由を好みます。

しかし、いずれにしても、このスレッドを読んだ後、ルートの最初のクエリに続いて再帰クエリを実行するdig + traceの現象を調べました。私の経験では、対応するグルーA / AAAAレコードなしでNSレコードを選択してから、そのレコードの再帰クエリをローカルDNSに送信するまでの対応は100％です。そして、その逆です。リフェラルから選択されたNSレコードに対応するグルーレコードがある場合、再帰クエリは見られません。