NSレコードにIPアドレスが含まれないのはなぜですか？

NSレコードのポイントは、どのネームサーバーがドメイン名の実際のIPアドレスを確実に知っているかをクライアントに伝えることです。したがって、たとえば、次のクエリは、信頼できる回答を取得するfacebook.com場合は質問する必要があることを示していますa.ns.facebook.com。

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

これはクールで便利に思えますが、なぜこのANSWERセクションに信頼できるソースのIPではなくホスト名が含まれているのでしょうか？クライアントがホスト名ではなく、信頼できるソースの実際のIPアドレスを取得する方が簡単ではないでしょうか？

ホスト名を取得した場合、このホスト名をIPに解決するために別のクエリを作成し、この新しいIP facebook.comに探していた最初のドメインについて尋ねる必要があります。これは非効率ではありませんか？

この問題を説明するRFCのいくつかの段落を指す回答に興味があります。

この問題の解決策はDNSグルーレコードです。これについては、グルーレコードとはで説明しています。。

RFC 1035セクション3.3.11の状態

「...クラスはホストとの通信に使用するプロトコルファミリを示していない場合がありますが、通常は強力なヒントです。」

IPアドレスを返すことは、RFCに反するホストに接続する方法を述べることに相当します。

Jasonは、あなたが説明した問題を回避するDNSメカニズムを提供しましたが、なぜこのように処理されるのかについてはまだ検討していません。

私が所有していてexample.com、自分のWebサイトコンテンツの一部をContosoという名前のコンテンツ配信会社と契約しているとします。それらのプラットフォームでsub.example.comは、返される応答を制御できるように、ネームサーバーに委任する必要があります。

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

お気付きのとおり、ContosoのネームサーバーのIPアドレスは指定していません。私たちのサーバーが知っているのは、「管理していませんsub.example.com。代わりにContosoに尋ねてください」とインターネットに伝えることです。次の理由により、これは非常に重要です。

• Contoso.comは所有していません。
• ContosoがネームサーバーIPの変更をすべての顧客と調整することは期待できません。サーバーがそれらのIPを提供していた場合、それがまさに発生しなければならないことです。

ここまでは順調ですね。1年が経過しましたが、Contosoが知らないうちに、CDNネームサーバーのIPアドレスを変更しています。DNSはそれがないというように動作しますので、彼らがしなければならないすべては更新しているA彼らが返すレコードをns1.cdnとns2.cdn.contoso.com.。

これは重要なポイントに私たちをもたらします：Jasonによって記述されたグルーレコードはgoogle.com、ネームサーバーがであるns1.google.comと世界に伝えるなど、DNSの「鶏と卵」のシナリオを処理するために存在しns2.google.comます。あなたは、必要があります決して、彼らはこのような問題を解決するために存在していない限り、あなたが所有していないというインフラを指しグルーレコードを作成しません。

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

これにより、鶏と卵のシナリオが回避されますが、ContosoはこれらのネームサーバーのすべてのIP変更を調整する必要があります。これは非常に危険であり、望ましくありません。