Есть ли официальное ограничение на косвенное обращение к серверу имен?

Склеенные записи обычно недоступны, если домен и его сервер имен не разделяют TLD, и технически не требуются, если они не совместно используют один и тот же домен второго уровня, что может привести к дополнительным шагам для разрешения домена. Решатель должен сначала найти адрес сервера имен, прежде чем он сможет найти адрес для вашего домена. Но теоретически вы можете добавить туда больше шагов, чем просто эти два.

Вопрос здесь в том, как долго будет длиться эта цепь?

если xyz.com использует nameserver ns1.xyz.info,
а также xyz.info использует nameserver ns1.xyz.co,
а также xyz.co использует nameserver ns1.xyz.cc,
а также xyz.cc использует nameserver ns1.xyz.co.uk,... и так далее

... у вас может получиться очень длинная цепочка, чтобы распознаватель мог распутаться, прежде чем он сможет разрешить имя, которое вы изначально хотели.

Предположительно, есть практический предел - BIND должен быть готов пройти только через очень много ссылок, в противном случае существует вероятность отказа в обслуживании. Но есть ли официальный лимит? Некоторое количество шагов, после которых распознаватель официально не требуется выполнять?

1 ответ

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

По моему опыту, ваше утверждение о том, что "склеенные записи обычно недоступны, если домен и его сервер имен не разделяют ДВУ", просто не соответствует действительности. Однако это зависит от данных, предоставленных регистратором домена, и их политики различаются. Некоторые требуют, чтобы IP был указан. Некоторые оставляют это на усмотрение владельца домена. Я думаю, что помню один в Австралии, который не поддерживает их. Если число регистраторов, имеющих дело с доменом вашей страны, невелико, то, возможно, это может быть правдой в этой части доменного пространства, но для сети в целом это нетипично.

Владельцы доменов, безусловно, рекомендуют предоставлять записи Glue, но иногда возможность указывать DNS-сервер по имени без указания IP-адреса считается гибким, и многие владельцы доменов не понимают, что это создает проблему производительности.

Если вы предоставляете инструмент отчетности DNS, действительно ли это абсолютный предел для такой неверной конфигурации, которая вас интересует? Конечно, вам важнее сообщить о недостающих записях клея в качестве предупреждения, если возникнет хотя бы одна такая проблема с отсутствующими клеевыми записями. Возможно, вы захотите отследить хотя бы несколько косвенных указаний, которые вы предоставили (и сообщить о пропущенных склеенных записях), но должны быть некоторые ограничения на то, как далеко вы должны следовать этому. Я был бы очень рад, если бы средство отчетности DNS предупреждало о первых трех или около того, поскольку мне было бы действительно интересно либо добавить склеенные записи в мой домен, либо переключить поставщика DNS для домена на более компетентный.

Я сомневаюсь в вашем предложенном подходе DOS для BIND, так как BIND будет кэшировать информацию, которую он собирает о местонахождении серверов имен. Злоумышленник должен установить множество доменов без клея, а затем сделать много запросов о них. Стоимость настройки доменов, которые могут быть отменены регистратором после использования, вероятно, сделает это непривлекательным для злоумышленника.

Другие вопросы по тегам