У моей группы есть сервер, указывающий на DNS, предоставленный Active Directory, чтобы гарантировать, что он может достичь любых хостов, управляемых доменом. К сожалению, моей команде тоже нужно запустить dig +trace часто, и время от времени мы получаем странные результаты. Я являюсь администратором DNS, но не администратором домена, но команда, отвечающая за эти серверы, тоже не понимает, что здесь происходит.
Проблема, похоже, переместилась между обновлениями ОС, но трудно сказать, является ли это характеристикой версии ОС или другими настройками, изменяемыми в процессе обновления.
dig +trace (запрос . IN NS с первого входа в /etc/resolv.conf) иногда возвращал 0 байтовых ответов.Пример второй проблемы:
$ dig +trace -x 1.2.3.4
; <<>> DiG 9.8.2 <<>> +trace -x 1.2.3.4
;; global options: +cmd
. 3600 IN NS dns2.ad.example.com.
. 3600 IN NS dns1.ad.example.com.
;; Received 102 bytes from 192.0.2.11#53(192.0.2.11) in 22 ms
1.in-addr.arpa. 84981 IN NS ns1.apnic.net.
1.in-addr.arpa. 84981 IN NS tinnie.arin.net.
1.in-addr.arpa. 84981 IN NS sec1.authdns.ripe.net.
1.in-addr.arpa. 84981 IN NS ns2.lacnic.net.
1.in-addr.arpa. 84981 IN NS ns3.apnic.net.
1.in-addr.arpa. 84981 IN NS apnic1.dnsnode.net.
1.in-addr.arpa. 84981 IN NS ns4.apnic.net.
;; Received 507 bytes from 192.0.2.228#53(192.0.2.228) in 45 ms
1.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net.
4827 7200 1800 604800 172800
;; Received 127 bytes from 202.12.28.131#53(202.12.28.131) in 167 ms
В большинстве случаев это не проблема, но может вызвать dig +trace следовать неверному пути, если мы отслеживаем внутри домена, для которого у AD есть внутреннее представление.
Почему dig +trace сходит с ума? И почему кажется, что жалуемся только мы?
Вас троллируют корневые ссылки. Эту проблему сложно устранить, и она зависит от понимания того, что . IN NS запрос, отправленный в начале трассировки не установить RD (требуется рекурсия) флаг на пакете.
Когда DNS-сервер Microsoft получает нерекурсивный запрос для корневых серверов имен, возможно, они вернут настроенные корневые подсказки. Пока вы не добавляете RD флаг на запрос, сервер будет продолжать возвращать тот же ответ с фиксированным TTL в течение всего дня.
$ dig @192.0.2.11 +norecurse . NS
; <<>> DiG 9.8.2 <<>> @192.0.2.11 +norecurse . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12586
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 3600 IN NS dns2.ad.example.com.
. 3600 IN NS dns1.ad.example.com.
;; ADDITIONAL SECTION:
dns2.ad.example.com. 3600 IN A 192.0.2.228
dns1.ad.example.com. 3600 IN A 192.0.2.229
Это то место, где большинство усилий по поиску и устранению неисправностей не увенчаются успехом, потому что легко предположить, что dig @whatever . NS воспроизведет проблему, что фактически полностью ее маскирует. Когда сервер получает запрос на корневые серверы имен с RD установлен флаг, он протянется и возьмет копию настоящий корневые серверы имен, и все последующие запросы для . NS без то RD flag волшебным образом начнет работать, как ожидалось. Это делает dig +trace снова счастлив, и каждый может снова чесать в затылке, пока проблема не появится снова.
Вы можете либо согласовать другую конфигурацию с администраторами домена, либо обойти проблему. Пока отравленные корневые подсказки достаточно хороши в большинстве обстоятельств (и вы знаете об обстоятельствах, в которых они отсутствуют: противоречивые взгляды и т. Д.), Это не является большим неудобством.
Некоторые обходные пути без изменения корневых подсказок:
. NS. Вы также можете подключить этот сервер имен к ${HOME}/.digrc, но это может сбить с толку других пользователей общей учетной записи или в какой-то момент быть забытым вами. dig @somethingelse +trace example.comdig . NSdig +trace example.com