Назад | Перейти на главную страницу

Когда TLD, имеющий связующие записи для серверов имен, сохраняет запросы DNS?

Насколько я понимаю, если у меня для серверов имен example1.com и example2.us установлено значение ns1.example2.us и ns2.example2.us, поиск www.example1.com будет:

Если вместо этого у нас для серверов имен example1.com и example2.com установлено значение ns1.example2.com и ns2.example2.com, поиск www.example1.com будет:

Правильно ли я, что в этом случае поиск состоит только из этих двух шагов? В частности, мне кажется, что на сайте example2.com много запросов, которые предполагают, что поиск по example1.com не всегда использует записи связки, что приводит к дополнительному шагу, когда ns1.example2.com и / или ns2.example2.com ищутся, запрашивая ns1.example2.com и / или ns2.example2.com.

(отредактировал чтобы выделить мои второстепенные вопросы, похороненные в первом примере, и попытаться прояснить мой основной вопрос в конце.)

Может быть, какие-нибудь диаграммы помогут, раз уж я плохо это объясняю. Вот мое понимание того, что должно произойти при поиске www.example.com, если сервером имен example.com являются ns1.host.us и ns2.host.us:

Третий шаг поиска, кажется, происходит почти повсеместно, но для меня не совсем понятен. Должен ли действительно быть этот третий шаг?

Вот мое понимание того, что должно произойти при поиске www.example.com, если серверы имен example.com - ns1.host.com и ns2.host.com:

Правильно ли я понимаю этот случай?

Вот что, я думаю, может происходить примерно с 1/3 поисков для www.example.com с серверами имен ns1.host.com и ns2.host.com (в зависимости от количества и времени запросов к серверам имен для различных доменов) :

Возможно ли это на самом деле и / или это означает, что клиент ведет себя плохо?

Чтобы добавить к ответу Мита. Лучшая практика - только используйте Glue Records для разрешения этих циклических зависимостей. См. Раздел 2.3 RFC1912: http://www.faqs.org/rfcs/rfc1912.html

Цитировать:

Некоторые люди имеют плохую привычку ставить клейкую пластинку всякий раз, когда
они добавляют NS-запись «на всякий случай». Имея дубликат клея
записи в файлах зоны только усложняют задачу, когда сервер имен переходит на новый IP-адрес или удаляется. Вы потратите часы, пытаясь понять, почему случайные люди все еще видят старый IP-адрес какого-то хоста, потому что кто-то забыл изменить или удалить связующую запись в каком-то другом файле. Более новые версии BIND будут игнорировать эти дополнительные связующие записи в файлах локальной зоны.

Обратите внимание на последний бит, если вы используете BIND. Кроме того, я думаю, что большинство DNS клиенты игнорирует связующие записи дополнительных доменов, что объясняет то, что вы видите.

редактировать чтобы следить за комментарием.

Связующие записи TLD обычно предоставляют своему регистратору, но в остальном применяются те же правила. Я управляю доменами в .co.uk и .com. У меня также есть серверы имен в обоих этих TLD, которые являются полномочными для всех моих доменов.

Если я убегу dig ns co.uk и dig ns com, Я вижу большую кучу серверов, которые являются полномочными для этих TLD. Если я выберу один из перечисленных .com серверы и dig @<server> ns <mydomain>.com он вернет все четыре сервера имен для моего домена, но только связующие записи серверов имен в том же TLD (поставляются как ДОПОЛНИТЕЛЬНЫЕ НАЗНАЧЕНИЯ), которые вы описываете.

Если я сбегу dig @<co.uk server> <myotherdomain>.co.uk, Я снова получу все четыре сервера имен, но на этот раз вместе со связующими записями для трех из них в .co.uk TLD.

Все так, как должно быть. Если все ваши серверы имен находятся в .us TLD, а затем клиенты, которые ищут ваш .com доменам будут сообщены доменные имена ваших серверов имен .com серверы; тогда клиенты выполнят еще один запрос на .us серверов, чтобы найти их IP-адреса. Этот дополнительный круговой обход может показаться неэффективным, но он должен происходить только один раз за период TTL для каждого клиента. (обычно 48 часов для записей TLD.)

(Прошу прощения, если вы уже знаете все вышеперечисленное). Чтобы ответить на исходный вопрос. Склеивающие записи не предназначены для сохранения запросов DNS. Они необходимы для предотвращения бесконечных циклов.

Редактировать 2

Извините за болтовню по этому поводу. Теперь я понимаю, о чем вы (между прочим, хорошие диаграммы).

Мое понимание того, как должны вести себя клиенты, состоит в том, что если у кого-то есть возможность получить авторитетные RR, то он должен; но в этом случае клиент запрашивает у сервера имен его своя А записи, что бессмысленно, так как клей является те записи А.

Я достигаю предела своих знаний здесь, но я не могу придумать ни одной ситуации, в которой клиенту может понадобиться это сделать. Я предполагаю здесь, но, возможно, реализация клиента должна проверить, что сервер определенно является авторитетным для ns_.host.us, даже если это означает то, что выглядит как бессмысленный дополнительный обход.

Попробуйте dig +trace www.example.com чтобы увидеть, делает ли он то же самое. Мне было бы любопытно узнать, выполняет ли он такой же поиск, если оригинал запрос был также для имени _.host.us.

Серверы имен в делегировании идентифицируются по имени, а не по IP-адресу. Это означает, что разрешающий сервер имен должен выдать другой DNS-запрос, чтобы узнать IP-адрес сервера, к которому он был отнесен. Если имя, указанное в делегировании, является поддоменом домена, для которого предоставляется делегирование, существует циклическая зависимость. В этом случае сервер имен, обеспечивающий делегирование, также должен предоставить один или несколько IP-адресов для полномочного сервера имен, упомянутого в делегировании. Эта информация называется клеем. Делегирующий сервер имен предоставляет это связующее звено в форме записей в дополнительном разделе ответа DNS и предоставляет делегирование в разделе ответа ответа.

Например, если авторитетный сервер имен для example.org - ns1.example.org, компьютер, пытающийся разрешить www.example.org, сначала разрешает ns1.example.org. Поскольку ns1 содержится в example.org, для этого необходимо сначала разрешить example.org, который представляет собой циклическую зависимость. Чтобы разорвать зависимость, сервер имен для домена верхнего уровня организации включает клей вместе с делегированием, например, example.org. Связующие записи - это записи адресов, которые предоставляют IP-адреса для ns1.example.org. Сопоставитель использует один или несколько из этих IP-адресов для запроса одного из авторитетных серверов домена, что позволяет ему выполнить DNS-запрос. Это может решить проблему.

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

  1. запросить корень для www.example1.com, получить ссылку на com namesevers.
  2. query com nameserver для www.example1.com, получите ссылку на ns1.example.com, сервер имен для example1.com.
  3. К сожалению, у нас нет IP-адреса ns1.example1.com. query com nameserver для ns1.example.com.
  4. goto 3.

Сервер имен com должен вернуть запись A для ns1.example.com, иначе вы никогда не доберетесь до нее.

Вы все еще можете столкнуться с проблемами с делегированием вне бейливика, поскольку авторитетные серверы имен не часто возвращают для них связующие записи. Например:

  1. запросить com nameserver для ns1.example1.com, получить ответ ns1.example1.us
  2. запросите у нас сервер имен для ns1.example1.us, получите ответ ns1.example.com
  3. перейти 1

Упс - ни сервер имён com, ни сервер имён в США не вернут клей для рефералов из bailiwick. DJB имеет некоторые примеры поподробнее.

В любом случае клей предназначен не как ярлык, а как механизм, позволяющий избежать петель. Кэширование предоставляет ваш механизм для сохранения результатов поиска.