ネームサーバーの間接参照に公式の制限はありますか？

ドメインとそのネームサーバーがTLDを共有していない場合、通常、グルーレコードは使用できません。また、同じセカンドレベルドメインを共有していない場合、技術的には必要ありません。これにより、ドメインを解決するための追加の手順が必要になる場合があります。リゾルバーは、ドメインのアドレスを見つける前に、まずネームサーバーのアドレスを調べる必要があります。ただし、理論的には、これらの2つのステップよりも多くのステップを追加できます。

ここでの問題は、そのチェーンがどれだけ長く許されるかということです。

もしxyz.com用途はネームサーバns1.xyz.info、
およびxyz.info用途ネームサーバns1.xyz.co、
およびxyz.co用途ネームサーバns1.xyz.cc、
およびxyz.ccネームサーバ用途ns1.xyz.co.ukなど、...と

...本来必要な名前を解決する前に、リゾルバがもつれを解くための非常に長いチェーンになる可能性があります。

おそらく実用的な制限があると思います-BINDは非常に多くのリンクをトラバースするだけであるはずです。そうでなければ、サービス拒否の可能性があります。しかし、公式の制限はありますか？それを超えるとリゾルバーが公式に続行する必要がないいくつかのステップ？

if xyz.com uses nameserver ns1.xyz.info,

この場合、ローカルリゾルバーは最初にサーバーに.com（たとえば、a.gtld-servers.net）、xyz.comドメインのネームサーバーの場所を要求します。.comドメインサーバーは通常、xyz.comドメインのネームサーバーのIPアドレスのグルーレコードを提供します。

例えば：

$ dig  gmail.com @a.gtld-servers.net 

; <<>> DiG 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1 <<>> gmail.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gmail.com.         IN  A

;; AUTHORITY SECTION:
gmail.com.      172800  IN  NS  ns2.google.com.
gmail.com.      172800  IN  NS  ns1.google.com.
gmail.com.      172800  IN  NS  ns3.google.com.
gmail.com.      172800  IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     172800  IN  A   216.239.34.10
ns1.google.com.     172800  IN  A   216.239.32.10
ns3.google.com.     172800  IN  A   216.239.36.10
ns4.google.com.     172800  IN  A   216.239.38.10

;; Query time: 375 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jul 10 01:10:57 EST 2014
;; MSG SIZE  rcvd: 181

私の経験では、「ドメインとそのネームサーバーがTLDを共有していない場合、通常、グルーレコードは使用できません」というあなたの声明は真実ではありません。ただし、ドメインのレジストラによって提供されるデータに依存し、それらのポリシーは異なります。IPを指定する必要があるものもあります。ドメイン所有者に任せる人もいます。私はオーストラリアでそれらをサポートしていないものを覚えていると思います。あなたの国のドメインを扱うレジストラの数が少ない場合、おそらくこれはドメイン空間のその部分内では当てはまるかもしれませんが、ネット全体としてはこれは典型的ではありません。

ドメイン所有者がグルーレコードを提供することは確かに良い習慣ですが、IPを特定せずに名前でDNSサーバーを指定する機能は柔軟性を提供すると見なされ、多くのドメイン所有者はこれがもたらすパフォーマンスの問題を理解していません。

DNSレポートツールを提供している場合、それは本当にあなたが興味を持っているそのような誤設定に対する絶対的な制限ですか？確かに、このような接着剤レコードの欠落の問題が1つでも存在する場合は、接着剤レコードの欠落を警告として報告するほうが重要です。あなたはおそらくあなたが提供するような少なくともいくつかの間接参照を追跡したいです（そしてその不足している接着剤レコードを報告します）が、これに従う必要がある範囲にはいくつかの制限があるはずです。ドメインにグルーレコードを追加するか、ドメインのDNSプロバイダーをより有能なDNSプロバイダーに切り替えることにのみ興味があるので、DNSレポートツールが最初の3つ程度を警告してくれればとても嬉しいです。

BINDはネームサーバーの場所について収集した情報をキャッシュするため、BINDで提案されているDOSのアプローチに疑問があります。攻撃者は、接着剤を使わずに多数のドメインを設定し、それらについて多くのクエリを実行する必要があります。使用後にレジストラによってキャンセルされる可能性が高いドメインを設定するコストは、攻撃者にとってこれを魅力のないものにする可能性があります。