Вопросы Теги

Почему 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) для разрешения my.example.net может помочь, поскольку на серверах имен .net есть .net , а у меня нет IP-адреса. Это просто связующая запись на уровне TLD?

Вопрос 2:

Если связующие записи являются такой необходимой частью DNS, почему делегирование происходит по имени хоста, а не по IP-адресу?

0
задан 26 March 2019 в 20:12
2 ответа

  1. Людям, которые запускают рекурсивные преобразователи (например, Google с 8.8.8.8 или ваш интернет-провайдер), необходимо предоставить IP-адрес хотя бы одного корневого сервера - обычно через файл подсказок. IP-адреса корневого сервера задокументированы IANA и редко меняются.

  2. Упрощает некорневым DNS-серверам изменение IP-адресов, создание нескольких IP-адресов, передачу разных IP-адресов разным регионам и т. Д.

3
ответ дан 4 December 2019 в 11:41

Все программы рекурсивных серверов имен поставляются со списком текущих корневых серверов имен и их 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 здесь (обновление приведенного выше списка)

Шаг 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 : наш запрос действителен
  • no 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.

1139443] но он, очевидно, будет поступать с того же сервера 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 .

1
ответ дан 4 December 2019 в 11:41

Теги

Похожие вопросы