Когда я отправляю DNS-запрос для my.example.netмой рекурсивный DNS-сервер переходит в корневую зону DNS (или вместо этого получает кешированное значение). Этот сервер имен говорит: «иди посмотри на .net серверы имен ", а те, в свою очередь, говорят" посмотрите на example.net серверы имен "а те, в свою очередь, говорят"my.example.net Я сидел xxx.xxx.xxx.xxx".
Википедия говорит, что «серверы имен в делегировании идентифицируются по имени, а не по IP-адресу», и необходимость приклеивать пластинки поддерживает это.
Вопрос 1:
Я не понимаю, как корневая зона DNS говорит мне перейти на a.gtld-servers.net (или любой другой сервер имен .net) для разрешения my.example.net может помочь, так как .net серверы имен имеют .net в них и у меня нет IP-адреса. Это просто связующая запись на уровне TLD?
Вопрос 2:
Если связующие записи являются такой необходимой частью DNS, почему делегирование происходит по имени хоста, а не по IP-адресу?
Людям, которые запускают рекурсивные преобразователи (например, Google с 8.8.8.8 или ваш интернет-провайдер), необходимо предоставить IP-адрес хотя бы одного корневого сервера - обычно через файл подсказок. IP-адреса корневого сервера задокументировано IANA и меняются редко.
Облегчает некорневым DNS-серверам изменение IP-адреса, создание нескольких IP-адресов или присвоение разных IP-адресов разным регионам и т. Д.
Все программы рекурсивных серверов имен поставляются со списком текущих корневых серверов имен и их IP-адресов.
Это дает основу, поскольку это может меняться, но медленно.
При запуске сервер подключит любой из вышеуказанных IP-адресов для получения через . NS DNS запрашивает текущий список корневых серверов имен, а затем обновляет его внутренний список и использует его для всех дальнейших нужд. Этот процесс называется «заливкой».
Если вам нужны подробности, все это объяснено в RFC 8109 «Инициализация DNS-резолвера с первичными запросами»
Что касается вашего вопроса о клеях, помните, что клеи - это особый край. Если у вас есть домен adomain.example с помощью ns1.anotherdomain.test то нигде нет клеевых записей. См. Определение «связующих записей» в этом новом документе по терминологии DNS: https://tools.ietf.org/html/rfc7719#section-6 :
Связанные записи: «[Записи ресурсов], которые не являются частью авторитетных данных [зоны], а являются записями ресурсов адресов для [серверов имен в подзонах]. Эти записи RR необходимы только в том случае, если имя сервера имен находится« ниже » сокращение, и используются только как часть реферального ответа ". Без клея «мы могли бы столкнуться с ситуацией, когда NS RR сообщают нам, что для того, чтобы узнать адрес сервера имен, мы должны связаться с сервером, используя адрес, который мы хотим узнать». (Определение из [RFC1034], раздел 4.2.1)
Что касается «Когда я отправляю DNS-запрос для my.example.net, он попадает в корневую зону DNS», то это неверно. Ваша система использует один (или несколько) рекурсивных DNS-серверов, локальных или общедоступных. Вы отправляете им все свои DNS-запросы. Они отвечают, как следует из их названия, за выполнение итеративных запросов к нескольким серверам имен рекурсивным способом, начиная с корня, если в их текущем кеше нет данных для ответа на ваш запрос.
Итак, давайте опишем пример, используя настоящее имя, например www.stackexchange.com.
Ты можешь сделать dig +trace www.stackexchange.com A чтобы увидеть, что именно происходит, +trace запускает полный рекурсивный режим и показывает, что делает любой рекурсивный сервер имен, когда его кеш пуст.
Но мы можем переделать это вручную. А если вы хотите, чтобы следовал конкретный алгоритм, прочтите «4.3.2. Алгоритм» в RFC 1034 ИМЕНА ДОМЕНОВ - КОНЦЕПЦИИ И УСТРОЙСТВА (но обратите внимание, что есть более поздние дополнения, особенно для DNSSEC и других записей, таких как DNAME)
Например см. https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/dns/rootns.c Это часть исходного кода BIND. Но в основном это содержание ответа на . NS с IP-адресами, то есть текущий список корневых серверов имен и их IPv4- и IPv6-адресов.
Здесь мы игнорируем этап подготовки DNS (обновление приведенного выше списка)
Выберите один из указанных выше IP-адресов и выполните свой запрос:
$ dig @192.112.36.4 www.stackexchange.com A +nodnssec
; <<>> DiG 9.12.0 <<>> @192.112.36.4 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59725
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59725
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; AUTHORITY SECTION:
com. 2d IN NS k.gtld-servers.net.
com. 2d IN NS e.gtld-servers.net.
com. 2d IN NS g.gtld-servers.net.
com. 2d IN NS c.gtld-servers.net.
com. 2d IN NS l.gtld-servers.net.
com. 2d IN NS j.gtld-servers.net.
com. 2d IN NS h.gtld-servers.net.
com. 2d IN NS a.gtld-servers.net.
com. 2d IN NS b.gtld-servers.net.
com. 2d IN NS m.gtld-servers.net.
com. 2d IN NS d.gtld-servers.net.
com. 2d IN NS f.gtld-servers.net.
com. 2d IN NS i.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 2d IN A 192.5.6.30
b.gtld-servers.net. 2d IN A 192.33.14.30
c.gtld-servers.net. 2d IN A 192.26.92.30
d.gtld-servers.net. 2d IN A 192.31.80.30
e.gtld-servers.net. 2d IN A 192.12.94.30
f.gtld-servers.net. 2d IN A 192.35.51.30
g.gtld-servers.net. 2d IN A 192.42.93.30
h.gtld-servers.net. 2d IN A 192.54.112.30
i.gtld-servers.net. 2d IN A 192.43.172.30
j.gtld-servers.net. 2d IN A 192.48.79.30
k.gtld-servers.net. 2d IN A 192.52.178.30
l.gtld-servers.net. 2d IN A 192.41.162.30
m.gtld-servers.net. 2d IN A 192.55.83.30
a.gtld-servers.net. 2d IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 2d IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 2d IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 2d IN AAAA 2001:500:856e::30
e.gtld-servers.net. 2d IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 2d IN AAAA 2001:503:d414::30
g.gtld-servers.net. 2d IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 2d IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 2d IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 2d IN AAAA 2001:502:7094::30
k.gtld-servers.net. 2d IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 2d IN AAAA 2001:500:d937::30
m.gtld-servers.net. 2d IN AAAA 2001:501:b1f9::30
;; Query time: 121 msec
;; SERVER: 192.112.36.4#53(192.112.36.4)
;; WHEN: Tue Mar 26 12:22:23 EST 2019
;; MSG SIZE rcvd: 874
Итак, сервер на 192.112.36.4 отвечает нам:
NOERROR: наш запрос был действителенaa запись во флагах, мы не получили авторитетного ответа на наш ответ, только указатели, куда идти дальше. мы запрашиваем, не делает ли рекурсия для нас.COM; он предоставляет их имена и IP-адреса.Теперь рекурсивный сервер имен не обязан доверять содержимому «ДОПОЛНИТЕЛЬНОГО РАЗДЕЛА». Это может повториться с m.gtld-servers.net. например, и спросите об этом тот же авторитетный сервер имен. Таким же образом он вернет данные, что он не является авторитетным для этого имени, но знает серверы имен .NET и возвращая свое имя и IP-адреса. Здесь, поскольку их имена снова в .NET, они находятся под залогом, и сервер должен доверять предоставленным IP-адресам.
Выбрав любой из вышеуказанных IP-адресов, мы снова выполняем наш запрос:
$ dig @ 192.26.92.30 www.stackexchange.com A + nodnssec
; <<>> DiG 9.12.0 <<>> @192.26.92.30 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45273
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45273
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; AUTHORITY SECTION:
stackexchange.com. 2d IN NS ns-925.awsdns-51.net.
stackexchange.com. 2d IN NS ns-1029.awsdns-00.org.
stackexchange.com. 2d IN NS ns-cloud-d1.googledomains.com.
stackexchange.com. 2d IN NS ns-cloud-d2.googledomains.com.
;; ADDITIONAL SECTION:
ns-cloud-d1.googledomains.com. 2d IN AAAA 2001:4860:4802:32::6d
ns-cloud-d1.googledomains.com. 2d IN A 216.239.32.109
ns-cloud-d2.googledomains.com. 2d IN AAAA 2001:4860:4802:34::6d
ns-cloud-d2.googledomains.com. 2d IN A 216.239.34.109
;; Query time: 108 msec
;; SERVER: 192.26.92.30#53(192.26.92.30)
;; WHEN: Tue Mar 26 12:35:56 EST 2019
;; MSG SIZE rcvd: 273
Здесь сервер в 192.26.92.30 ранее давал нам примерно такой же ответ: он не является авторитетным для имени, которое мы ищем, но возвращает свой сервер имен и IP-адреса.
Опять же, namserver не смог спросить имя ns-cloud-d1.googledomains.com. но он, очевидно, будет поступать с того же сервера namserver, что и тот же TLD, поэтому он может использовать указанные выше IP-адреса. Или он может снова сделать разрешение с нуля для имен ns-925.awsdns-51.net. или ns-1029.awsdns-00.org. которые являются внешними по отношению к .COM зона, следовательно, IP-адреса не указаны.
Итак, чтобы упростить использование одного из вышеуказанных IP-адресов и повторение запроса:
$ dig @216.239.34.109 www.stackexchange.com A +nodnssec
; <<>> DiG 9.12.0 <<>> @216.239.34.109 www.stackexchange.com A +nodnssec
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16720
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16720
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.stackexchange.com. IN A
;; ANSWER SECTION:
www.stackexchange.com. 5m IN CNAME stackexchange.com.
stackexchange.com. 5m IN A 151.101.1.69
stackexchange.com. 5m IN A 151.101.65.69
stackexchange.com. 5m IN A 151.101.129.69
stackexchange.com. 5m IN A 151.101.193.69
;; Query time: 149 msec
;; SERVER: 216.239.34.109#53(216.239.34.109)
;; WHEN: Tue Mar 26 12:38:34 EST 2019
;; MSG SIZE rcvd: 128
Обратите внимание на важное различие: флаг AA, означающий, что сервер имен, который мы только что запросили, действительно является авторитетным для запрашиваемого имени, поэтому его результаты являются «окончательными». Фактически это показывает, что наше имя CNAME тип записи, но он предоставляет IP-адреса цели, поэтому наш запрос завершен, мы смогли решить эту проблему www.stackexchange.com прямо сейчас и откуда это было сделано, это IP-адреса 151.101.1.69 и 151.101.65.69 и 151.101.129.69 и 151.101.193.69.