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

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

• Почему dig + trace игнорирует Glue Records?
• Это поведение характерно для dig или dig + trace , или же рекурсивный сервер имен также «вручную проверяет» полученные связующие записи?

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

Это полный захват транзакции 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-запись, поэтому вместо этого предоставляет полные доменные имена серверов доменных имен TLD .com (a.gtld-servers.net, b.gtld-servers.net и т. Д.).Обратите внимание, что F Root NS также предоставляет «Дополнительные записи», которые представляют собой записи A, соответствующие каждому из полных доменных имен сервера имен TLD .com:

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

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

У меня следующие вопросы:

• Почему dig + trace игнорирует Glue Records?
• Является ли это поведение характерным для dig или dig + trace , или же рекурсивный сервер имен также «вручную проверяет» полученные связующие записи?

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

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

---

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

---

Edit 2 : Этот вопрос похож на мой, но не совсем то же самое. В этом вопросе @Andrew B подтверждает то же поведение, которое я наблюдаю:

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

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

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