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

Почему dig + trace игнорирует связующие записи DNS?

Вот мои вопросы:

Вот более подробное объяснение:

Это полный захват транзакции DNS, вызвавшей эти вопросы.

Я использую dig + trace, чтобы следить за процессом DNS для простого разрешения записи A для www.pizza.com. Как и ожидалось, первый запрос был адресован моему DNS-серверу в поисках корневых серверов имен (пакет №1). Затем мой DNS-сервер отправляет список всех 13 серверов имен (пакет № 2):

Обратите внимание, что в пакете № 2 нет дополнительных записей. Что побуждает моего клиента искать запись A для каждого из предоставленных корневых серверов имен. Что происходит в пакетах с 3 по 28:

Пока это ожидается. Но дальше становится интересно.

Пакет 29 - это мой клиент, который делает запрос к 192.5.5.241 (f.root-servers.net) в поисках записи A для www.pizza.com. Очевидно, корневой NS не знает A-запись, поэтому вместо этого предоставляет .com Полные доменные имена серверов имен TLD (a.gtld-servers.net, b.gtld-servers.net и т. Д.). Обратите внимание, что F Root NS также предоставляет «Дополнительные записи», которые представляют собой записи A, соответствующие каждому из полных доменных имен сервера имен TLD .com:

Далее следует то, вокруг чего вращается мой вопрос. Хотя мой клиент получил записи A, относящиеся к серверам имен TLD .com. Тем не менее, было решено сделать запросы записи A для каждого из серверов имен TLD .com (пакеты 31-56):

То же самое происходит чуть ниже (пакеты 57-66), когда мой клиент запрашивает у серверов имен TLD .com запись A для www.pizza.com и получает авторитетные записи NS для домена Pizza.com. Серверы имен TLD .com предоставляют связующие записи, но мой клиент по-прежнему выходит и вручную разрешает A-запись каждого NS-сервера.

Итак, мои вопросы:

Я использую эту версию Dig:
DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1

И выполнил эту команду:
$ dig www.pizza.com +trace -4

Изменить 1: также добавлены вопросы вверху, чтобы было легче понять, о чем я спрашиваю

Редактировать 2: Этот вопрос is similar to mine, but not exactly the same. In this question, @Andrew B confirms the same behavior I am seeing:

+trace обманул и проконсультировался с локальным преобразователем, чтобы получить IP-адрес сервера имен следующего прыжка вместо консультации с клеем.

Но мой вопрос конкретно Зачем делает dig +trace сделай это? Какая польза? Что он пытается предоставить? Кажется, что это просто дополнительная работа, которая иногда может даже вызвать неточность в том, как dig разрешает адрес и как фактический DNS разрешает адрес (как указано в другом вопросе).

Однако другой вопрос, похоже, отвечает на мой второй вопрос. Похоже, что такое поведение игнорирования клейких записей характерно для копания, а не того, как будет действовать «нормальный» рекурсивный сервер имен.

В официальной документации сказано, что dig может использовать склеивающие записи для последующих запросов, но может вернуться к рекурсивным запросам, если скрепляющие записи не предоставлены [1]:

dig может по-прежнему отправлять запросы на серверы, перечисленные в /etc/resolv.conf, при использовании + trace. При итеративном выполнении делегирования, как указано в параметре + trace, dig начнет с запроса NS-записей для серверов, уполномоченных для root ("." ). Они могут или не могут быть снабжены клеем - это записи A и AAAA, которые могут использоваться для следующих запросов, которые должен отправить dig. Если клей не предоставлен, либо при первоначальном запросе для корневых серверов имен, либо позже, после делегирования, dig вернется к рекурсивному запросу серверов, перечисленных в /etc/resolv.conf, для получения необходимых RRset A / AAAA.

Указание @server не меняет этого поведения - сервер, указанный таким образом, будет запрашиваться только для записей NS для серверов, уполномоченных для root (".").

Это может быть неправильная документация или ошибка в раскопках.

[1] https://kb.isc.org/docs/aa-00208