BIND 9.8.2 не предоставление записи для “роет domain.xxx ЛЮБОЙ”
Я получил проблему со своим BIND 9.8.2 установок. После конфигурирования основной зоны, которая хорошо работает, я заметил, что не могу получить список всех A записи с помощью dig утилита с ANY опция.
Вот некоторые примеры:
google.com
Если я пробую google.com, я могу добраться A записи:
# dig google.com ANY
; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> google.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51302
;; flags: qr rd ra; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN ANY
;; ANSWER SECTION:
google.com. 264 IN A 46.28.246.109
google.com. 54220 IN NS ns3.google.com.
google.com. 264 IN A 46.28.246.108
google.com. 264 IN A 46.28.246.84
google.com. 264 IN A 46.28.246.113
google.com. 264 IN A 46.28.246.104
google.com. 54220 IN NS ns2.google.com.
google.com. 264 IN A 46.28.246.99
google.com. 264 IN A 46.28.246.118
google.com. 264 IN A 46.28.246.119
google.com. 54220 IN NS ns4.google.com.
google.com. 264 IN A 46.28.246.89
google.com. 264 IN A 46.28.246.93
google.com. 264 IN A 46.28.246.88
google.com. 264 IN A 46.28.246.94
google.com. 60 IN SOA ns1.google.com. dns-admin.google.com. 1559778 7200 1800 1209600 300
google.com. 54220 IN NS ns1.google.com.
google.com. 264 IN A 46.28.246.123
google.com. 264 IN A 46.28.246.98
google.com. 264 IN A 46.28.246.103
google.com. 264 IN A 46.28.246.114
;; Query time: 47 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Thu Jun 26 18:43:50 2014
;; MSG SIZE rcvd: 402
Мой домен лаборатории - MX записывает как пример
Я могу добраться MX записи, если я прошу их:
# dig internal.bluenet.lab MX
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> internal.bluenet.lab MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40974
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;internal.bluenet.lab. IN MX
;; ANSWER SECTION:
internal.bluenet.lab. 257965 IN MX 20 mail2.internal.bluenet.lab.
internal.bluenet.lab. 257965 IN MX 10 mail1.internal.bluenet.lab.
;; AUTHORITY SECTION:
internal.bluenet.lab. 257439 IN NS ns.internal.bluenet.lab.
;; Query time: 2 msec
;; SERVER: 10.200.1.99#53(10.200.1.99)
;; WHEN: Thu Jun 26 18:53:35 2014
;; MSG SIZE rcvd: 99
Мой домен лаборатории - нет записи
Неважно, если я использую ANY или A опции я не могу получить все A записи как ответ. Только если я использую A опция я получаю одну запись
# dig internal.bluenet.lab ANY
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> internal.bluenet.lab ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39681
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;internal.bluenet.lab. IN ANY
;; ANSWER SECTION:
internal.bluenet.lab. 257961 IN MX 10 mail1.internal.bluenet.lab.
internal.bluenet.lab. 257961 IN MX 20 mail2.internal.bluenet.lab.
internal.bluenet.lab. 257961 IN SOA ns.internal.bluenet.lab. adminlab.bluenet.lab.internal.bluenet.lab. 3837556585 28800 7200 2419200 86400
internal.bluenet.lab. 257435 IN NS ns.internal.bluenet.lab.
;; AUTHORITY SECTION:
internal.bluenet.lab. 257435 IN NS ns.internal.bluenet.lab.
;; Query time: 0 msec
;; SERVER: 10.200.1.99#53(10.200.1.99)
;; WHEN: Thu Jun 26 18:53:40 2014
;; MSG SIZE rcvd: 168
У меня есть типичная установка BIND - chrooted только с основной зоной. Я заблокировал зональные передачи (для предотвращения AXFR запросы).
Интересно, почему я не могу добраться A записи. Любезно помогите мне на нем. Должен некоторая опция в named.conf использоваться для разрешения этого?
Предполагая, что на самом деле существует запись A, я полагаю, что наблюдаемое поведение сводится к общему поведению ЛЮБОЙ запросов, когда они направлены на кэширующий сервер.
Важно отметить, что любой сервер, независимо от того, является ли он кэширующим или авторитетным, должен возвращать только те записи, которые у него есть для запрашиваемого имени в запросе ЛЮБОЙ .
То есть, если у кэширующего сервера есть что-то в кэше, то это совершенно верно (и наиболее распространенная реализация), чтобы просто вернуть то, что все еще находится в кэше для этого имени. Это означает, что часть результата могла истечь, если есть разные TTL.
На практике это означает, что ЛЮБЫЕ запросы полезны только в очень специфических обстоятельствах (как правило, не для встраивания в программное обеспечение, а для отладки и подобных целей).