Связующие записи обычно недоступны, если домен и его сервер имен не имеют общего TLD, и технически не являются обязательный если они не используют один и тот же домен второго уровня, что может привести к дополнительным действиям по разрешению домена. Преобразователь должен сначала найти адрес сервера имен, прежде чем он сможет найти адрес вашего домена. Но теоретически вы можете добавить туда больше шагов, чем только эти два.
Вопрос здесь в том, как долго эта цепочка может быть?
если 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 обычно предоставляет связующие записи для IP-адресов серверов имен для домена xyz.com.
например:
$ 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. Некоторые оставляют это на усмотрение владельца домена. Думаю, я помню одного в Австралии, который их не поддерживает. Если количество регистраторов, работающих с доменом вашей страны, невелико, то, возможно, это может быть верно в пределах этой части доменного пространства, но для сети в целом это нетипично.
Для владельцев доменов, безусловно, является хорошей практикой предоставлять Glue-записи, но иногда возможность указать DNS-сервер по имени без привязки IP-адреса рассматривается как обеспечение гибкости, и многие владельцы доменов не понимают проблемы с производительностью, которые это создает.
Если вы предоставляете инструмент отчетности DNS, действительно ли это абсолютный предел такой неправильной конфигурации, который вас интересует? Конечно, для вас более уместно сообщить об отсутствующих записях клея в качестве предупреждения, если возникает хотя бы одна такая проблема с отсутствующими записями клея. Вы, вероятно, захотите отслеживать хотя бы несколько косвенных указаний, которые вы предоставляете (и сообщать об отсутствующих связующих записях), но должны быть некоторые ограничения на то, как далеко вы должны следовать этому. Я был бы очень рад, если бы инструмент отчетов DNS предупредил о первых трех или около того, так как меня действительно интересовало бы только либо добавление связанных записей в мой домен, либо переключение поставщика DNS для домена на более компетентного.
Я сомневаюсь в предлагаемом вами подходе DOS к BIND, поскольку BIND будет кэшировать собираемую информацию о расположении серверов имен. Злоумышленнику придется создать множество доменов без клея, а затем сделать много запросов о них. Стоимость создания доменов, которые, вероятно, будут отменены регистратором после использования, скорее всего, сделает это непривлекательным для злоумышленника.