web-dev-qa-db-ja.com

Dig + traceがWindowsServer DNSに対して失敗することがあるのはなぜですか？

私のチームには、Active Directoryによって提供されるDNSを指すサーバーがあり、ドメインによって管理されているすべてのホストに確実に到達できるようになっています。残念ながら、私のチームもDig +traceを頻繁に実行する必要があり、散発的に奇妙な結果が得られます。私はDNS管理者ですが、ドメイン管理者ではありませんが、これらのサーバーを担当するチームは、ここでも何が起こっているのかわかりません。

問題はOSのアップグレード間でシフトしているようですが、それがOSのバージョンの特徴なのか、アップグレードプロセス中に変更された他の設定なのかはわかりません。

  • アップストリームサーバーがWindowsServer 2003の場合、Dig +traceの最初のステップ（. IN NSの最初のエントリからの/etc/resolv.confの要求）は、0バイトの応答を返すことがありました。
  • アップストリームサーバーがWindowsServer 2012にアップグレードされると、ゼロバイト応答の問題は解消されましたが、DNSサーバーで構成されたフォワーダーのリストが散発的に取得される問題に置き換えられました。

2番目の問題の例：

$ Dig +trace -x 1.2.3.4      

; <<>> Dig 9.8.2 <<>> +trace -x 1.2.3.4
;; global options: +cmd
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.
;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms

1.in-addr.arpa.         84981   IN      NS      ns1.apnic.net.
1.in-addr.arpa.         84981   IN      NS      tinnie.arin.net.
1.in-addr.arpa.         84981   IN      NS      sec1.authdns.ripe.net.
1.in-addr.arpa.         84981   IN      NS      ns2.lacnic.net.
1.in-addr.arpa.         84981   IN      NS      ns3.apnic.net.
1.in-addr.arpa.         84981   IN      NS      apnic1.dnsnode.net.
1.in-addr.arpa.         84981   IN      NS      ns4.apnic.net.
;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms

1.in-addr.arpa.         172800  IN      SOA     ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net.
4827 7200 1800 604800 172800
;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms

ほとんどの場合、これは問題ではありませんが、ADが内部ビューを持っているドメイン内をトレースしている場合、Dig +traceが間違ったパスをたどる原因になります。

なぜDig +traceは気を失っているのですか？そして、なぜ私たちだけが不平を言っているように見えるのですか？

domain-name-systemwindows-server-2003windows-server-2012dig
5
Andrew B

あなたはルートヒントに支配されています。これはトラブルシューティングが難しいものであり、トレースの開始時に送信される. IN NSクエリを理解することにかかっていますしないパケットにRD（再帰が必要）フラグを設定します。

MicrosoftのDNSサーバーがルートネームサーバーに対する非再帰的な要求を受信すると、構成されたルートヒントを返す可能性があります。リクエストにRDフラグを追加しない限り、サーバーは1日中固定のTTL）で同じ応答を返し続けます。

$ Dig @192.0.2.11 +norecurse . NS

; <<>> Dig 9.8.2 <<>> @192.0.2.11 +norecurse . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12586
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       3600    IN      NS      dns2.ad.example.com.
.                       3600    IN      NS      dns1.ad.example.com.

;; ADDITIONAL SECTION:
dns2.ad.example.com.    3600    IN      A       192.0.2.228
dns1.ad.example.com.    3600    IN      A       192.0.2.229

Dig @whatever . NSが問題を再現し、実際には完全にマスクするという簡単な仮定があるため、これはほとんどのトラブルシューティング作業が失敗する場所です。サーバーは、RDフラグが設定されたルートネームサーバーのリクエストを受け取ると、realルートネームサーバーのコピーと、それに続く. NSのすべてのリクエストを取得しますなしRDフラグは魔法のように期待どおりに機能し始めます。これにより、Dig +traceは再び幸せになり、問題が再発するまで、誰もが頭を悩ませることに戻ることができます。

オプションは、ドメイン管理者と別の構成をネゴシエートするか、問題を回避することです。毒された根のヒントがほとんどの状況で十分である限り（そしてあなたはそれらがそうではない状況を知っている：矛盾する見解など）、これは大きな不便ではありません。

ルートヒントを変更しない場合のいくつかの回避策は次のとおりです。

  • デフォルトのリゾルバーのセットが少ないマシンでトレースを実行します。
  • . NSに応答してインターネットのルートネームサーバーを返すネームサーバーからトレースを開始します。このネームサーバーを${HOME}/.digrcに配線することもできますが、これにより、共有アカウントの他のユーザーが混乱したり、ある時点で忘れられたりする可能性があります。 Dig @somethingelse +trace example.com
  • トレースを実行する前に、ルートのヒントをシードします。
    Dig . NS
    Dig +trace example.com
6
Andrew B