6

いくつかのサービス プロバイダーがクライアントのドメインの DNS サービスを運用しており、NS 名がゾーンに設定され、権限のあるネーム サーバー (権限セクション / NS および SOA レコード) によって返され、返された NS 名と一致しないことがわかりました。アップストリームサーバー（TLDサーバーなど）によって、ルックアップに使用されました。

例：

$ dig the-domain-name-here.com NS

; <<>> DiG 9.4.2-P1 <<>> the-domain-name-here.com NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7844
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;the-domain-name-here.com.          IN      NS

;; ANSWER SECTION:
the-domain-name-here.com.   172370  IN      NS      ns1.service-provider-here.net.
the-domain-name-here.com.   172370  IN      NS      ns2.service-provider-here.net.

;; ADDITIONAL SECTION:
ns1.service-provider-here.net.      7200    IN      A       192.168.100.1
ns2.service-provider-here.net.      7200    IN      A       192.168.100.2

;; Query time: 65 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Mar 11 19:44:00 2009
;; MSG SIZE  rcvd: 118

$ dig @ns1.service-provider-here.net. the-domain-name-here.com

; <<>> DiG 9.4.2-P1 <<>> @ns1.service-provider-here.net  the-domain-name-here.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48010
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;the-domain-name-here.com.          IN      A

;; ANSWER SECTION:
the-domain-name-here.com.   86400   IN      A       192.168.100.3

;; AUTHORITY SECTION:
the-domain-name-here.com.   86400   IN      NS      ns1.different-trade-name.net.
the-domain-name-here.com.   86400   IN      NS      ns2.different-trade-name.net.

;; Query time: 68 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Wed Mar 11 19:46:00 2009
;; MSG SIZE  rcvd: 100

gTLD サーバーは、ネーム サーバーが ns1.service-provider-here.net であると言い、そのサーバーで名前を検索すると、正式な回答が得られますが、機関セクションで別の NS 名がリークされます (ns1.different-trade-name 。ネット）。

このように構成された数千のドメインがあります。何の問題もないように見えますが、とても間違っているようです。

これは実際に重要ですか？これが原因で、リゾルバー/クライアントが追加のルックアップを実行したり、名前の解決に失敗したりする状況が発生することはありますか?

4

2 に答える 2

5

まあ、答えは視点によって異なります。

技術的には、親とゾーンの間の不一致が間違っていることは間違いありません。それは決して起こらないはずです (一部のレジストリは、自動ツールを使用してそれをチェックします。たとえば、Zonecheck in .fr)。

実際には、それはかなり頻繁に起こります。最も一般的な原因は、人々が自分のゾーンの NS レコードを変更し、その変更についてレジストリ (または、レジストリが仲介者を経由することを強制している場合はレジストラ) に伝えるのを忘れていることです。

それは本当に問題ですか？あなたが言ったように、2 つのセットの間に空でない交差がある限り、それは機能するはずです。ただ、これに頼るのは危険です。したがって、矛盾を受け入れるのは得策ではありません。

法的に言えば、子ゾーンは常に正しく、親の NS レコードは信頼できません。リゾルバーは、子ゾーンで見つけたリストで委任を置き換える必要があります。

于 2009-03-12T10:56:24.040 に答える
2

親がゾーンに対して権限のある DNS サーバーを参照する有効なレコードを持っている場合、解決はほとんどの場合うまくいくはずです。

異なるレコードがあり、その他の構成ミスがいくつかある場合に、それらが問題になる可能性があるケースを少なくとも 1 つ考えられます。

この問題は、ゾーンが更新されたときにネーム サーバーが通知を送信する方法に関連しています。たとえば、プライマリ DNS サーバーで bind を使用している場合、ゾーンを更新してからリロードすると、bind はゾーンにリストされているすべてのサーバーに更新通知を送信します。別の権限のあるサーバーがプライマリ ゾーンに NS レコードを持っていない場合は、通知を取得せず、古いデータを保持します。親が更新を取得していないこのサーバーを指している場合、そのサーバーがデータの結果を提供するため、問題が発生する可能性があります。

また、「スプリット ホライズン」DNS のようなものがあることにも注意してください。場合によっては、ネットワーク内にある内部ホストに対して、一般に表示するものとは異なるゾーンのビューを提供する必要があります。ネーム サーバー レコードを比較するときは、ゾーンを同じ視点から見ていることを確認してください。

于 2009-03-11T21:10:50.717 に答える