Когда точность кеша DNS находится под вопросом, dig +trace
обычно является рекомендуемым способом определения достоверного ответа для записи DNS, доступной в Интернете. Это кажется особенно полезным в сочетании с +additional
, который также показывает записи клея.
Иногда кажется, что по этому поводу возникают разногласия - некоторые люди говорят, что он полагается на локальный преобразователь для поиска IP-адресов промежуточных серверов имен, но выходные данные команды не указывают на то, что это происходит за пределами исходного списка корневых серверы имен. Логично предположить, что этого не было бы, если бы цель +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
включил это появляется исходить от клея.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? 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 предоставляет неверный ответ для сервера имен, эта модель полностью разрушается.
Пример из реального мира:
В приведенном выше случае +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 может выдавать последующие запросы к локальным преобразователям при следующих условиях:
реферальный ответ усекается из-за того, что размер ответа превышает 512 байт для следующего итеративного запроса
dig выбирает NS-запись из раздела AUTHORITY реферального ответа, для которого соответствующая запись A (клей) отсутствует в разделе ADDITIONAL
Поскольку 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 для электронного корневого сервера, а также нет записи 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». query настоятельно предполагает, что следующий рекурсивный запрос был выполнен по той причине, которую я утверждаю. Возможно, операционная система клиента поддерживает IPv6 и предпочитает записи AAAA - или по какой-то другой причине.
Но в любом случае, прочитав этот поток, я изучил феномен dig + trace, выполняющий рекурсивные запросы, следующие за начальным запросом для root. По моему опыту, соответствие между выбором NS-записи без соответствующей связующей A / AAAA-записи и копанием с последующей отправкой рекурсивного запроса для этой записи в локальный DNS составляет 100%. Верно и обратное: я не видел рекурсивных запросов, когда NS-запись, выбранная из реферала, имеет соответствующую связующую запись.