Назад | Перейти на главную страницу

делегирование / 24 и / 64 обратных зон

Я уверен, что упускаю из виду что-то настолько простое, но я просто не вижу этого ... Я пытаюсь делегировать обратные зоны / 24 и / 64 для нашей тестовой сети хостам в тестовой сети. Я наблюдаю ту же проблему с делегированием IPv4 / 24 и IPv6 / 64, поэтому сейчас я сосредоточусь на IPv4.

Мы используем 172.31.0.0/16 внутри, с 172.31.99.0/24 Тестовая сеть.

Я хочу делегировать 99.31.172.in-addr.arpa. к 2 новым контроллерам домена в тестовой сети на 172.31.99.11 и .12

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

Очевидно, я заменил наш фактический домен на «example».

После полной перезагрузки named я получаю NXDOMAIN от локального преобразователя:

# dig -x 172.31.99.11 @localhost

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50720
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;11.99.31.172.in-addr.arpa. IN  PTR

;; Query time: 29 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Jul  9 16:38:33 2013
;; MSG SIZE  rcvd: 43

Между тем, прямой поиск IP-адреса, которому я делегировал, работает нормально:

# dig -x 172.31.99.11 @172.31.99.11

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> -x 172.31.99.11 @172.31.99.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44598
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;11.99.31.172.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
11.99.31.172.in-addr.arpa. 1200 IN  PTR svr-addc1.ad.example.com.au.

;; Query time: 2 msec
;; SERVER: 172.31.99.11#53(172.31.99.11)
;; WHEN: Tue Jul  9 15:49:51 2013
;; MSG SIZE  rcvd: 81

Это делегирование для прямого просмотра, которое работает должным образом:

$ORIGIN ad.example.com.au.
@             NS    svr-addc1
@             NS    svr-addc2
; glue records:
svr-addc1 A     172.31.99.11
          AAAA  2001:xxxx:xxxx:c699::addc:21
svr-addc2 A     172.31.99.12
          AAAA  2001:xxxx:xxxx:c699::addc:22

Обратный поиск для других сетей / 24 по-прежнему работает нормально:

# dig -x 172.31.42.101 @localhost +short
sw-sana.example.com.au.

РЕДАКТИРОВАТЬ

Если я добавлю зону в named.conf как type forward зона, то все работает правильно:

### TEST network delegated to the new AD controllers
zone "99.31.172.in-addr.arpa" IN {
    type forward;
    forwarders { 172.31.99.11; 172.31.99.12; };
};
zone "9.9.6.c.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" IN {
    type forward;
    forwarders { 2001:xxxx:xxxx:c699::addc:21; 2001:xxxx:xxxx:c699::addc:22; };
};

И копание с использованием локального преобразователя работает:

# dig -x 172.31.99.11 +short
svr-addc1.ad.example.com.au.

Я правда не понимаю, что делаю не так: - /

Я хочу делегировать 99.31.172.in-addr.arpa. к 2 новым контроллерам домена в тестовой сети на 172.31.99.11 и .12

$ORIGIN 99.31.172.in-addr.arpa.
@       NS      svr-addc1.ad.example.com.au.
@       NS      svr-addc2.ad.example.com.au.

В какой файл вы помещаете строки выше? Делегации должны находиться в содержащей зоне (т. Е. Записи делегирования для 99.31.172.in-addr.arpa. Должны существовать внутри зоны для 31.172.in-addr.arpa.) Кроме того, в качестве стилистического вопроса, что вы получаете изменив $ ORIGIN? Это делает записи менее ясными и может вызвать побочные эффекты, если у вас есть другое содержимое зоны, определенное далее в файле.

Наконец, ваш файл named.conf на основном сервере имен (а не в тестовой сети) все еще содержит объявление зоны для 99.31.172.in-addr.arpa. в ее взглядах?

После того, как домен делегирован на ваш основной DNS-сервер, он не будет отвечать на DNS-запросы для этих доменов, если рекурсия не включена. Причина, по которой пересылка работает, заключается в том, что по умолчанию пересылка выполняет рекурсию. Вы можете сначала попытаться включить рекурсию.