Когда TLD, имеющий склеенные записи для серверов имен, сохраняет DNS-запросы?
Насколько я понимаю, если у меня есть серверы имен для example1.com и example2.us, настроенные на ns1.example2.us и ns2.example2.us, поиск www.example1.com будет:
- ищите example1.com, чтобы найти его серверы имен, не приводящие к склеиванию записей (реестр.com не предоставит клей для доменов.us)
- ищите ns1.example2.us и ns2.example2.us (обязательно оба?), каждый из которых будет:
- query example2.us, выдающий склеенные записи для ns1.example2.us и ns2.example2.us
- по-видимому, запрос ns1.example2.us и / или ns2.example2.us, чтобы получить адрес (а) для ns1.example2.us и / или ns2.example2.us (это правильно? похоже, это мой опыт)
- запрос ns1.example2.us и / или ns2.example2.us, чтобы получить адрес www.example1.com
Если вместо этого у нас есть серверы имен для example1.com и example2.com, настроенные на ns1.example2.com и ns2.example2.com, поиск www.example1.com будет:
- ищите example1.com, чтобы найти его серверы имен, получая склеенные записи для ns1.example2.com и ns2.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 (в зависимости от количества и времени запросов к серверам имен для различных доменов).:
Возможно ли это на самом деле и / или представляет ли он клиента с плохим поведением?
3 ответа
Добавить к ответу Мита. Рекомендуется использовать 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
Извините, что бродил вокруг вопроса. Теперь я понимаю, что вы имеете в виду (кстати, хорошие диаграммы).
Мое понимание того, как должны вести себя клиенты, заключается в том, что если у кого-то есть возможность получить авторитетные ОР, то это должно быть; но в этом случае клиент запрашивает у сервера имен свои собственные записи A, что бессмысленно, поскольку Glue - это те записи A.
Я достигаю пределов своих знаний здесь, но я не могу думать ни о какой ситуации, почему клиент должен был бы сделать это. Я предполагаю здесь, но, возможно, клиентская реализация должна проверить, что сервер определенно является полномочным для 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, который представляет циклическую зависимость. Чтобы разорвать зависимость, сервер имен для домена верхнего уровня org включает в себя клей вместе с делегированием для example.org. Клеевые записи - это записи адресов, которые предоставляют IP-адреса для ns1.example.org. Средство распознавания использует один или несколько из этих IP-адресов для запроса одного из доверенных серверов домена, что позволяет ему выполнять DNS-запрос. Это может решить проблему.
Клей предназначен для начальной загрузки запросов, которые в противном случае были бы неразрешимыми. Представь, что нет клея
- запросить корень для www.example1.com, получить ссылку на com namesevers.
- запросите com nameserver для www.example1.com, получите ссылку на ns1.example.com, сервер имен для example1.com.
- К сожалению, у нас нет IP-адреса для ns1.example1.com. запросите com nameserver для ns1.example.com.
- перейти к 3.
Сервер имен com должен возвращать запись A для ns1.example.com, иначе вы никогда не получите этого.
Вы по-прежнему можете столкнуться с проблемами при делегировании из-под контроля, поскольку авторитетные серверы имен не часто возвращают для них склеенные записи. Например:
- запросите com nameserver для ns1.example1.com, получите ответ ns1.example1.us
- запросите у нас сервер имен для ns1.example1.us, получите ответ от ns1.example.com
- перейти к 1
К сожалению, ни сервер имен com, ни сервер имен us не вернут клей для рефералов. У DJB есть несколько примеров более подробно.
Во всяком случае, клей предназначен не как ярлык, а как механизм, позволяющий избежать петель. Кэширование обеспечивает ваш механизм для сохранения поисков.