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

Как разрешаются записи NS?

Примечание. Мне известно о связующих записях и о том, что DNS-серверы используют их только в том случае, если домен ns-сервера совпадает с доменом, для которого вы отправили запрос.

Теперь мой вопрос был: скажем, у вас есть example.com, на котором ns1.example.org (другой домен, чем example.com) в качестве записи NS. В какой-то момент преобразователю также потребуется разрешить и найти IP-адрес для ns1.example.org. У меня вопрос, КАК это делает (без клейкой записи)?

Я предполагаю, что он запускает процесс снова, сначала перейдя к корневому DNS, а затем к .org DNS, затем он достигает серверов имен для example.org... но подождите, а есть ли у серверов имён серверы имён? Если да, то это закончится большим бесконечным циклом, потому что теперь вам нужно найти записи NS для example.org и иди туда и т. д.

Я хочу сказать, что эти IP-адреса серверов имен ДОЛЖНЫ где-то храниться. Я слышал, что люди говорят, что клейкие пластинки используются, только если говорят, что у вас есть example.com и его NS-серверы ns1.example.com, тот же домен. Если это другой домен, то я читал, что есть разрешение этого домена, чтобы найти IP ... но это означает, что такие серверы имен, как ns1.example.org имеют свои собственные серверы имен, что действительно не имеет смысла.

Делегирование серверу имен в другом домене на самом деле мало что меняет - оно просто заставляет преобразователь выполнять больше работы.

В приведенном вами примере example.org домен должен быть работоспособным для example.com имя для успешного разрешения - почему бы ему не иметь свои собственные действующие серверы имен или склеивающие записи?

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

  • Решателю нужен IP-адрес www.example.com (запрос «A www.example.com.»)
  • он не кэшируется, поэтому ему необходимо запросить DNS-сервер, который является авторитетным для example.com
  • не имея лучшего представления, он запрашивает один из предварительно настроенных корневых серверов
  • Вместо окончательного ответа нам сообщают об авторитетных серверах для com., Таких как a.gtld-servers.net; несмотря на то, что они не находятся в com, корневые серверы добавляют клеящие записи; следовательно, мы знаем ip a.gtld-servers.net
  • Поэтому мы задаем вопрос "A www.example.com" a.gtld-servers.net
  • Опять же, a.gtld-серверы знают ответ, но говорят нам, что за это отвечает ns.example.org; обычно там бы на этом этапе можно связать записи, но давайте предположим, что это не так
  • Запускаем подзапрос "A ns.example.org"
  • Как и выше, корневые серверы ведут нас к серверам DNS для организации, например a0.org.afilieas-nst.info; в плохом мире нам пришлось бы начинать игру заново, чтобы найти этого парня, но на этом уровне мы делать получить записи клея
  • Итак, мы можем попросить a0.org.afilieas-nst.info для ns.example.org
  • Мы узнаем, что мы должны спросить a.iana-servers.net о example.org, но, к сожалению, без клея
  • Поэтому мы спрашиваем корневые серверы (потому что мы тем временем узнали о com. И org., Но еще не узнали о сети).
  • В ответе говорится, что, например, a.gtld-servers-net отвечает за net. и мы тоже получаем клей, но мы уже знали ip a.gtld-servers.net
  • Мы запрашиваем у a.gtld-servers.net «A a.inana-servers.net» и изучаем записи NS для iana-servers.net; три из них находятся на iana-servers.net (и поставляются с клеем), а четвертый сервер - ns.icann.org
  • По какой-то глупой причине мы игнорируем связующие записи (или, возможно, эти серверы имен недоступны), и поэтому нам нужно разрешить ns.icann.org; ну, мы уже знаем, что мы должны запросить a0.org.afilieas-nst.info для "A ns.icann.org"
  • По сути, возвращенные серверы имен такие же, как указано выше: три из icann-servers.net и сам ns.icann.org; на этот раз ns.icann.org идет с клеем
  • Итак, теперь мы знаем ip ns.icann.org и можем задать ему «A a.iana-servers.net» и получить его адрес.
  • Итак, теперь мы можем наконец запросить у a.iana-servers.net "A ns.example.org" и получить IP-адрес (ну, не на самом деле, или конечно)
  • Мы можем запросить ns.example.org под этим ip для «A www.example.com» и, наконец, решили нашу исходную проблему.

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

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

К корневым DNS-серверам обращаются по их IP-адресам, настроенным на каждом DNS-сервере. Итак, когда DNS-сервер получает запрос на неизвестное ему доменное имя, он

  1. запрашивает настроенный DNS
  2. запрашивает корневой DNS, который не отвечает на соответствующий IP-адрес, но какой сервер (-ы) имен обрабатывает имя корневого домена (например, .com), а затем этот сервер имен может ответить, какой сервер имен обрабатывает конкретный домен (скажем, nasa.com )

Вы можете провести некоторое исследование, выполнив запрос на трассировку с помощью:

dig +trace www.google.com