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

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

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

если xyz.comиспользование сервер имен ns1.xyz.info,
и xyz.infoиспользует сервер имен ns1.xyz.co,
и xyz.coиспользуют сервер имена ns1.xyz.cc,
и xyz.ccиспользует сервер имена ns1.xyz.co.uk, ... и так далее

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

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

domain-name-system rfc

— tylerl
источник

Раздел « Ограничение объема работы» в tools.ietf.org/html/rfc1035#section-7.1 - это то, что приходит мне в голову. Это не совсем конкретный вопрос о том, каким должен быть предел, но я не знаю, есть ли какое-то определенное правило в этом отношении.

— Хокан Линдквист

Кроме того, не могли бы вы рассказать о каком-то реальном сценарии, когда вы предвидите, что это проблема (на практике это кажется крайне маловероятным), или это вопрос чисто академического характера?

— Хокан Линдквист

@ HåkanLindqvist Я на самом деле создаю инструмент, который ищет проблемы в настройках DNS. Это одна из проблем, которую нужно искать. Вопрос в том, насколько глубокой должна быть система, чтобы искать дальнейшие проблемы, прежде чем просто сдаться.

— Tylerl

@tylerl Возможно, вы захотите взглянуть на github.com/dotse/dnscheck .

— Дженни Д

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

— Tylerl

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 будет кэшировать информацию, которую он собирает о местонахождении серверов имен. Злоумышленник должен настроить множество доменов без клея, а затем сделать много запросов о них. Стоимость настройки доменов, которые могут быть отменены регистратором после использования, вероятно, сделает это непривлекательным для злоумышленника.

— mc0e
источник

.com и .net оба являются verisign. Они исключение. en.m.wikipedia.org/wiki/Verisign

— tylerl

«Исключения», по-видимому, охватывают большинство доменов верхнего уровня, с которыми я работал, но да, безусловно, есть домены, в которых нет склеенных записей.

— mc0e