У нас есть проблема с некоторыми кэширующими серверами имен, на которых запущен BIND на CentOS, в том смысле, что они работают неправильно и неправильно обрабатывают «Дополнительные записи», которые содержат связующие записи. При запросе d.gtld-servers.net dig получает записи клея:
$ dig @192.31.80.30 ns1.teamsystem.com
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @192.31.80.30 ns1.teamsystem.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 48270
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;ns1.teamsystem.com. IN A
;; AUTHORITY SECTION:
teamsystem.com. 172800 IN NS ns1.teamsystem.com.
teamsystem.com. 172800 IN NS ns2.teamsystem.com.
;; ADDITIONAL SECTION:
ns1.teamsystem.com. 172800 IN A 2.115.99.97
ns2.teamsystem.com. 172800 IN A 2.115.99.98
;; Query time: 100 msec
;; SERVER: 192.31.80.30#53(192.31.80.30)
;; WHEN: Mon Aug 6 10:22:54 2012
;; MSG SIZE rcvd: 100
Мне интересно, это сам домен или что-то, что мы неправильно настроили. Ниже приводится перефразированный tcpdump.
# dig +trace ns1.teamsystem.com
- Standard query NS <Root>
- Standard query response NS ... (lists all the root nameservers)
- Standard query A d.gtld-servers.net
- Standard query response A 192.31.80.30
- Standard query A ns1.teamsystem.com
- Standard query response
-- Additional Records
--- ns1.teamsystem.com: type A, class IN, addr 2.115.99.97
--- ns2.teamsystem.com: type A, class IN, addr 2.115.99.98
На этом этапе dig начинает использовать серверы имен из /etc/resolv.conf для получения AAAA ns1.teamsystem.com.
- Standard query AAAA ns1.teamsystem.com
- Standard query response, Server failure
У нас есть 3 записи сервера имен, поэтому он пробует их все, получая одинаковый отказ. Затем он повторяет попытку с запросом записи A.
- Standard query A ns1.teamsystem.com
- Standard query response, Server failure
Это доказывает, что BIND на наших преобразователях не может или не желает следить за связующими записями, которые явно доступны в разделе «Дополнительные записи».
Единственная проблема, которую мы можем найти с зоной, заключается в том, что SOA не соответствует серверам имен в связующих записях:
$ dig +short @2.115.99.98 teamsystem.com SOA
ns.teamsystem.com. postmaster.teamsystem.com. 1 3600 600 86400 3600