Является ли dig + trace всегда точным?

Когда речь идет о точности кеша DNS, это, dig +traceкак правило, рекомендуемый способ определения достоверного ответа для записи DNS в Интернете. Это кажется особенно полезным, когда также в паре с +additional, который также показывает склеенные записи.

Иногда кажется, что есть некоторые разногласия по этому вопросу - некоторые люди говорят, что он использует локальный распознаватель для поиска IP-адресов промежуточных серверов имен, но выходные данные команды не дают никаких признаков того, что это происходит за пределами первоначального списка root неймсерверов. Кажется логичным предположить, что это не будет иметь место, если целью +traceявляется запуск на корневых серверах и отслеживание пути вниз. (по крайней мере, если у вас есть правильный список корневых серверов имен)

dig +traceДействительно ли использует локальный преобразователь для чего-либо, кроме корневых серверов имен?

Это, очевидно, поэтапные вопросы и ответы, но это часто сбивает людей с толку, и я не могу найти канонический вопрос по этой теме.

dig +traceявляется отличным диагностическим инструментом, но один аспект его дизайна часто неправильно понимается: IP-адрес каждого сервера, который будет запрашиваться, получен из библиотеки распознавателя . Это очень легко упустить из виду и часто становится проблемой, когда ваш локальный кеш имеет неправильный ответ для кэшированного сервера имен.

Детальный анализ

Это легче разбить на образец выборки; Я опущу все после первой делегации NS.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• Первоначальный запрос для . IN NS(корневых серверов имен) обращается к локальному распознавателю, который в этом случае является Comcast. ( 75.75.75.75) Это легко определить.
• Следующий запрос для serverfault.com. IN Aи выполняется e.root-servers.net., случайно выбранный из списка корневых серверов имен, который мы только что получили. У него есть IP-адрес 192.203.230.10, и, поскольку мы +additionalвключили его, он, похоже, исходит от клея.
• Поскольку он не является полномочным для serverfault.com, он делегируется серверам com.имен TLD.
• Из этого вывода не очевидно, что digIP-адрес не был получен e.root-servers.net.из клея.

На заднем плане это то, что действительно произошло:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

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

Обычно это «достаточно хорошо» и не создает проблем для большинства людей. К сожалению, есть крайние случаи. Если по какой-либо причине ваш вышестоящий DNS-кеш дает неправильный ответ для сервера имен, эта модель полностью разрушается.

Пример из реального мира:

• срок действия домена истекает
• Клей переназначается на серверах перенаправления имен регистратора
• фиктивные IP-адреса кэшируются для ns1 и ns2.yourdomain.com
• домен обновляется с восстановленным клеем
• любые кэши с поддельными IP-адресами серверов имен продолжают отправлять людей на веб-сайт, который сообщает, что домен продается

В приведенном выше случае +traceбудет предположить, что источником проблемы являются собственные серверы имен владельца домена, и вы на расстоянии одного звонка от неверного сообщения клиенту о том, что его серверы неправильно настроены. Является ли это чем-то, что вы можете (или хотите) сделать с чем-то, это другая история, но важно иметь правильную информацию.

dig +trace Это отличный инструмент, но, как и любой инструмент, вам нужно знать, что он делает, а что нет, и как вручную устранять проблему, если она оказывается недостаточной.

Редактировать:

Следует также отметить, что dig +traceне будет предупреждать вас о NSзаписях, которые указывают на CNAMEпсевдонимы. Это нарушение RFC, которое ISC BIND (и, возможно, другие) не будет пытаться исправить. +traceбудет полностью рад принять Aзапись, полученную от вашего локально настроенного сервера имен, тогда как если бы BIND выполнял полную рекурсию, он бы отклонил всю зону с помощью SERVFAIL.

Это может быть сложно решить, если клей присутствует; это будет работать нормально, пока записи NS не обновятся , а затем внезапно прекратятся. Бесклеевые делегации всегда нарушают рекурсию BIND, когда NSзапись указывает на псевдоним.

Другой способ отслеживания разрешения DNS без использования локального преобразователя для чего-либо, кроме поиска корневых серверов имен, - это использование dnsgraph (полное раскрытие: я написал это). Он имеет инструмент командной строки и веб-версию, экземпляр которой вы можете найти по адресу http://ip.seveas.net/dnsgraph/

Пример для serverfault.com, который на самом деле сейчас имеет проблему с DNS:

Очень поздно к этой теме, но я думаю, что часть вопроса о том, почему dig + trace использует рекурсивные запросы к локальным распознавателям, не была объяснена напрямую, и это объяснение относится к точности результатов dig + trace.

После первоначального рекурсивного запроса для записей NS корневой зоны, dig может выдавать последующие запросы локальным распознавателям при следующих условиях:

1. Реферальный ответ усекается из-за размера ответа, превышающего 512 байт для следующего итеративного запроса.

2. dig выбирает запись NS из раздела AUTHORITY реферального ответа, для которого соответствующая запись A (клей) отсутствует в разделе ДОПОЛНИТЕЛЬНО

Поскольку у dig есть только имя домена из записи NS, dig должен преобразовать имя в IP-адрес путем запроса локального DNS-сервера. Это коренная причина (каламбур, извините).

У AndrewB есть пример, который не полностью соответствует тому, что я только что описал, в том, что выбрана запись NS корневой зоны:

. 121459 IN NS e.root-servers.net.

имеет соответствующую запись A:

e.root-servers.net. 354907 IN A 192.203.230.10

Однако обратите внимание, что нет соответствующей записи AAAA для e-root, а также нет записи AAAA для некоторых других корневых серверов.

Также обратите внимание на размер ответа:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 байтов - это общий размер для ответов, которые были усечены (то есть следующая склеенная запись была бы> 16 байтов, помещая ответ более 512 байтов). Другими словами, в запросе для записей NS для root полная AUTHORITY и полная ADDITIONAL (и записи A, и AAAA) будут превышать 512 байт, поэтому любой запрос на основе UDP, который не указывает больший размер запроса с помощью опций EDNS0, будет получите ответ, который обрезан где-то в ДОПОЛНИТЕЛЬНОМ разделе, как показано в приведенной выше трассировке (только f, h, i, j и k имеют записи склеивания A и AAAA).

Отсутствие записи AAAA для e.root-servers.net и размера ответа на «NS». запрос настоятельно предполагает, что следующий рекурсивный запрос был выполнен по той причине, на которую я претендую. Возможно, клиентская операционная система поддерживает IPv6 и предпочитает записи AAAA - или по какой-либо другой причине.

Но в любом случае, прочитав эту ветку, я изучил феномен dig + trace, выполняющий рекурсивные запросы после исходного для root. По моему опыту, соответствие между выбором записи NS без соответствующей клейкой записи A / AAAA и копанием, а затем отправкой рекурсивного запроса для этой записи в локальный DNS составляет 100%. И обратное верно - я не видел рекурсивных запросов, когда запись NS, выбранная из реферала, имеет соответствующую клейкую запись.