Это, очевидно, поэтапные вопросы и ответы, но это часто сбивает людей с толку, и я не могу найти канонический вопрос по этой теме.
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запись указывает на псевдоним.
+nssearch?+nssearchвыполняетNSпоиск записи по вашему локальному распознавателю для запрошенной записи, после чего следует серияA/ просмотровAAAAпо локальному распознавателю для каждого из возвращенных серверов имен. Это также чувствительно к поддельным записям сервера имен в кеше.Другой способ отслеживания разрешения DNS без использования локального преобразователя для чего-либо, кроме поиска корневых серверов имен, - это использование dnsgraph (полное раскрытие: я написал это). Он имеет инструмент командной строки и веб-версию, экземпляр которой вы можете найти по адресу http://ip.seveas.net/dnsgraph/
Пример для serverfault.com, который на самом деле сейчас имеет проблему с 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 ms496 байтов - это общий размер для ответов, которые были усечены (то есть следующая склеенная запись была бы> 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, выбранная из реферала, имеет соответствующую клейкую запись.
источник