Почему DNS возвращает полное доменное имя с клейкой записью вместо IP
Когда я отправляю запрос DNS для my.example.netмой рекурсивный сервер DNS переходит в корневую зону DNS (или получает вместо этого какое-то кэшированное значение). Этот сервер имен говорит "иди посмотри на .net серверов имен ", а те, в свою очередь, говорят" посмотрите на example.net серверов имен "и те, в свою очередь, говорят"my.example.net я сидела xxx.xxx.xxx.xxx".
Википедия говорит, что "серверы имен в делегациях идентифицируются по имени, а не по IP-адресу", и необходимость склеивания записей подтверждает это.
Вопрос 1:
Я не понимаю, как корневая зона DNS говорит мне перейти a.gtld-servers.net (или каким-либо другим образом.net nameserver) для разрешения my.example.net может помочь, так как .net серверы имен .net в них и у меня нет IP адреса. Это просто клейкая запись на уровне TLD?
Вопрос 2:
Если склеенные записи являются такой обязательной частью DNS, почему делегирование происходит по имени хоста, а не по IP-адресу?
2 ответа
Людям, которые запускают рекурсивные средства распознавания (например, Google с 8.8.8.8 или ваш провайдер), требуется IP-адрес хотя бы одного корневого сервера - обычно через файл подсказок. IP-адреса корневых серверов задокументированы IANA и редко меняются.
Облегчает DNS-серверам без полномочий root изменять IP-адреса, или иметь несколько, или назначать разные IP-адреса различным регионам и т. Д.
Все рекурсивное программное обеспечение серверов имен поставляется со списком текущих корневых серверов имен и их IP-адресов.
Это дает основу, поскольку это может измениться, но медленно.
После запуска сервер подключит любой из указанных выше IP-адресов для получения через . NS DNS запрашивает текущий список корневых серверов имен, а затем обновляет свой внутренний список и использует его для всех дальнейших нужд. Этот процесс называется "заправка".
Если вам нужны подробности, все это объяснено в RFC 8109 "Инициализация резолвера DNS с запросами инициализации"
Что касается вашего вопроса о клеях, помните, что клеи - это особый крайний случай. Если у вас есть домен adomain.example с помощью ns1.anotherdomain.test тогда нигде нет никаких клеевых записей. См. Определение "склеенных записей" в этом новом документе по терминологии DNS: https://tools.ietf.org/html/rfc7719:
Склейте записи: "[Ресурсные записи], которые не являются частью достоверных данных [зоны] и являются адресными ресурсными записями для [серверов имен в подзонах]. Эти 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 (обновляя приведенный выше список).
Шаг 1
Выберите один из указанных выше 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-адресам.
Шаг 2
Подбирая любой из вышеперечисленных 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-адреса не предоставляются.
Шаг 3
Итак, чтобы упростить использование одного из вышеперечисленных 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,