Является ли dig +trace всегда точным?
Когда точность DNS-кеша под вопросом, dig +trace как правило, является рекомендуемым способом определения достоверного ответа для записи DNS в Интернете. Это кажется особенно полезным в сочетании с +additional, который также показывает склеенные записи.
Иногда кажется, что есть некоторые разногласия по этому вопросу - некоторые люди говорят, что он использует локальный распознаватель для поиска IP-адресов промежуточных серверов имен, но выходные данные команды не дают никаких признаков того, что это происходит за пределами первоначального списка root неймсерверы. Кажется логичным предположить, что это не будет иметь место, если цель +trace это начать с корневых серверов и проследить свой путь вниз. (по крайней мере, если у вас есть правильный список корневых серверов имен)
Есть ли dig +trace действительно использовать локальный распознаватель для чего-либо, кроме корневых серверов имен?
3 ответа
Это, очевидно, поэтапные вопросы и ответы, но это часто сбивает людей с толку, и я не могу найти канонический вопрос по этой теме.
dig +trace является отличным диагностическим инструментом, но один аспект его дизайна часто неправильно понимается: IP-адрес каждого сервера, который будет запрашиваться, получен из библиотеки распознавателя. Это очень легко упустить из виду и часто становится проблемой, когда ваш локальный кеш имеет неправильный ответ для кэшированного сервера имен.
Детальный анализ
Это легче разбить на образец выборки; Я опущу все после первой делегации NS.
; <<>> DiG 9.7.3 <<>> +trace +additional faultserver.ru
;; 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) Это легко заметить. - Следующий запрос для
faultserver.ru. IN Aи бежит противe.root-servers.net., случайно выбранный из списка корневых серверов имен, которые мы только что получили. Имеет IP-адрес192.203.230.10и так как у нас есть+additionalвключен, кажется, идет от клея. - Поскольку он не является полномочным для faultserver.ru, он делегируется
com.Серверы имен TLD. - Что не очевидно из вывода здесь, это то, что
digне получил IP-адрес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? faultserver.ru. (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/
Пример для faultserver.ru, который на самом деле сейчас имеет проблему с DNS:
Очень поздно к этой теме, но я думаю, что часть вопроса о том, почему dig +trace использует рекурсивные запросы к локальным распознавателям, не была объяснена напрямую, и это объяснение относится к точности результатов dig +trace.
После первоначального рекурсивного запроса для записей NS корневой зоны, dig может выдавать последующие запросы локальным распознавателям при следующих условиях:
Реферальный ответ усекается из-за размера ответа, превышающего 512 байт для следующего итеративного запроса.
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, выбранная из реферала, имеет соответствующую клейкую запись.