У меня есть 2 домена в моей среде. Один из них - это домен активного каталога для myproductionlab.local по адресу 10.60.0.0/16.
Затем у меня есть debian box с bind9 для домена mytestlab.local
Я добавил запись в свой named.conf.local:
zone "60.10.in-addr.arpa" {
type forward;
forwarders {
10.60.10.5;
10.60.10.7;
10.60.10.9;
};
};
zone "myproductionlab.local" {
type forward;
forwarders {
10.60.10.5;
10.60.10.7;
10.60.10.9;
};
};
ящик debian настроен на 127.0.0.1 для разрешения DNS, и нет глобально настроенных серверов пересылки.
разрешение имен разрешается просто отлично:
nslookup mymachine.myproductionlab.local
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: mymachine.myproductionlab.local
Address: 10.60.10.200
и из журнала запросов:
client 127.0.0.1#36076 (mymachine.myproductinlab.local): query: mymachine.myproductionlab.local IN A + (127.0.0.1)
но обратный DNS не пересылается:
nslookup 10.60.10.200
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find 200.10.60.10.in-addr.arpa: NXDOMAIN
и из журнала запросов:
client 127.0.0.1#40295 (200.10.60.10.in-addr.arpa): query: 200.10.60.10.in-addr.arpa IN PTR + (127.0.0.1)
Я пробовал несколько вариантов зон:
zone "60.10.in-addr.arpa" {
zone "10.60.10.in-addr.arpa" {
zone "200.10.60.10.in-addr.arpa" {
Я также пробовал tcpdump, и 0 пакетов захватываются для nslookup 10.60.10.200, но пакеты захватываются для имени.
когда я вручную указываю DNS-сервер в nslookup, он также отлично работает:
nslookup 10.60.10.200 10.60.10.5
Server: 10.60.10.5
Address: 10.60.10.5#53
200.10.60.10.in-addr.arpa name = mymachine.myproductionlab.local.
На всякий случай, если кто-нибудь попадет в это… Для последних версий Bind9 (по крайней мере, в Debian) недостаточно отключить
include "/etc/bind/zones.rfc1918";
оператор, потому что Bind9 затем автоматически создает их. Вместо,
empty-zones-enable no;
требуется в вашем разделе опций (named.conf.options).
Видеть https://deepoughtt.isc.org/article/AA-00800/0/Automatic-empty-zones-including-RFC-1918-prefixes.html.
Результат DIG привел меня к обнаружению проблемы
dig -x 10.60.10.200
; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -x 10.60.10.200
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26824
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;200.10.60.10.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
10.in-addr.arpa. 86400 IN SOA localhost. root.localhost. 1 604800 86400 2419200 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 21 13:46:50 CST 2017
;; MSG SIZE rcvd: 104
10.in-addr.arpa. был определен в zone.rfc1918, который указывает на db.empty
В предыдущих версиях bind zone.rfc1918 не был включен по умолчанию, и даже я проверил все конфигурации, и ничто не сообщает bind читать этот файл, поэтому он должен быть прочитан по умолчанию сейчас в этой версии или настроен где-то еще.
dpkg -l | grep bind
ii bind9 1:9.9.5.dfsg-9+deb8u6 amd64 Internet Domain Name Server
ii bind9-host 1:9.9.5.dfsg-9+deb8u6 amd64 Version of 'host' bundled with BIND 9.X
ii bind9utils 1:9.9.5.dfsg-9+deb8u6 amd64 Utilities for BIND
ii libbind9-90 1:9.9.5.dfsg-9+deb8u6 amd64 BIND9 Shared Library used by BIND
nslookup не очень помогает, каков результат dig -x 10.60 10.200
который показал, что ваши частные диапазоны по умолчанию были включены и воспринимали ваши запросы как авторитетные.
удалите или отредактируйте их, чтобы быть более конкретными.