Отказ в переносе зоны привязки

10

ОБНОВИТЬ:

BIND версия:

[root@10.224.45.130] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5

Операционная система:

CentOS release 5.6 (Final)

После запуска [root@10.224.45.131] $ dig @10.224.45.130 example.com. axfr:

Ведомый:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options:  printcmd
; Transfer failed.

Мастер:

28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied

То же сообщение об ошибке, что и раньше.

ОБНОВЛЕНИЕ 2:

[root@10.224.45.130 ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 171K   23M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0           
57196 6930K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
  688 57376 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
37869 6120K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  392 21216 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
   74  5275 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    3   192 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:389 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:465 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
   13   832 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:636 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:694 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:843 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:873 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:953 
  119  7584 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:993 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    1    48 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5901 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.224.45.130       tcp dpt:10000 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11211 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11212 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11213 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11511 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11512 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11513 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2987  372K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 

Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
 pkts bytes target     prot opt in     out     source               destination

Я, наверное, посмотрел каждую страницу, касающуюся настройки BIND master / slave, и не могу всю жизнь заставить работать передачу зоны.

Вот мои настройки: (прокрутите вниз для описания проблемы)

Мастер: 10.224.45.130

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify explicit;
    allow-transfer {
        10.224.45.131;
    };
    also-notify {
        10.224.45.131;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type master;
    file "data/example.com.hosts";
};

Раб: 10.224.45.131

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify yes;
    allow-transfer { "none"; };
    allow-notify {
        10.224.45.130;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type slave;
    file "slaves/example.com.hosts";
    masters {
        10.224.45.130;
    };
};

Здесь проблема. Когда я перезапускаю named на подчиненном сервере, он видит, что файлы зоны еще не существуют, и запрашивает передачу с главного сервера:

named.log (Раб)

[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53

... после чего главный сервер получает запрос на передачу:

named.log (Мастер)

[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -

... и отвечает запросом на перевод, который отклоняется:

named.log (Мастер)

[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied

... на подчиненном сервере он отображается как ОТКАЗАНО:

named.log (Раб)

[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED

Просматривая все конфиги снова и снова, я не могу найти ничего плохого в настройках. У меня есть IP-адрес главного сервера, указанный в mastersнастройке конфигурации подчиненной зоны, у меня есть IP-адрес подчиненного сервера, указанный в allow-transferнастройке параметров основных настроек.

Все IP-адреса являются такими, какими они должны быть, не то, чтобы они пытались использовать публичный IP-адрес и были отклонены, потому что IP-адрес не совпадает. У меня есть настройки iptables, чтобы разрешить соединения TCP / UDP через порт 53 (и 953) на обоих серверах. Я правильно настроил права доступа к файлам, так что каталог / slaves, в котором хранятся файлы подчиненной зоны, доступен для записи namedпользователю.

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

— Сара Райан
источник

2

Вы пробовали (временно) настройки allow-transferдля , anyчтобы увидеть , если это исправляет проблему? Ваше allow-transferпредложение выглядит правильно, но это исключит любую вероятность проблем ...

— voretaq7

Нет, все еще получаю ту же ошибку. Я также просто попытался добавить WAN IP-адрес главного сервера в настройку «master», на всякий случай, и это тоже не помогло.

— Сара Райан

1

Вы запускали rndc reconfigпосле изменения конфига на мастере?

— Cakemox

3

Для начала попробуйте убедиться, что передача зоны работает.

На слейве выдай dig @master your-domain. AXFR

Какие версии BIND и какая ОС?

— dmourati
источник

Я обновил свой вопрос выводом и журналами этой команды. Это показывает, что оно было отклонено так же, как и в обычном запросе передачи зоны. Я также добавил информацию относительно версий и ОС. Извините, что оставил эту важную информацию.

— Сара Райан

1

Итак, тот факт, что команда dig завершилась неудачно, указывает на то, что проблема с мастером все еще существует. @ voretaq7, предложенный выше, разрешает передачу на любой, который, я согласен, является разумным шагом для устранения неполадок. Добавьте localhost для allow-transsfer, попробуйте команду dig от мастера на localhost. Также установите «tcpdump -i любой порт 53» на ведущем устройстве, чтобы проверить IP-адреса источника / назначения. Вы говорите: «У меня есть настройка iptables, чтобы разрешить TCP / UDP-соединения через порт 53 (и 953) на обоих серверах», но, пожалуйста, добавьте вывод «iptables -L -n -v» на ведущем устройстве. Вот или выключите iptables на мастере и повторите тестирование.

— dmourati

Я добавил localhost (а также все другие имена хостов и IP-адреса, которые могут быть) в настройку разрешения передачи, и я все еще получаю ту же ошибку. Я добавил вывод из запрошенной вами команды iptables, а также отключил iptables при повторной попытке. Все еще не повезло.

— Сара Райан

3

Нашел проблему. Я использую chroot BIND, но я редактировал файлы conf в / etc, а не в / var / named / chroot / etc. Таким образом, изменения, которые я делал, не были замечены. Я скопировал файлы conf в каталог chroot, и теперь все работает нормально.

— Сара Райан
источник

1

Хороший старик. Рад, что вы нашли это.

— Дмурати

1

Может показаться, что это уже охватывается allow-transferоператором in options, но попробуйте добавить явный allow-transferоператор в зону.

Я не вижу ничего плохого в вашей конфигурации. Похоже, это должно работать. Bind прослушивает этот порт вообще? (То есть все запросы выполняются успешно? Или все они терпят неудачу?)

Ну, у меня есть еще две идеи, которые стоит попробовать.

Убедитесь, что ваши часы обновлены (по крайней мере, в разумных пределах) на обоих серверах.
Возможно, вам мешает SELinux. Попробуйте временно отключить его, чтобы проверить.

— bahamat
источник

Я попытался поместить опцию allow-Transfer в конфигурацию зоны, и она по-прежнему выдает ту же ошибку. Это только запросы на передачу, которые терпят неудачу. Я могу успешно запросить у сервера любой тип записи, и он вернет его, как и ожидалось. Но когда я пытаюсь выполнить зонную передачу, я получаю сообщения об отказе / отказе.

— Сара Райан

Проверьте мой ответ для обновления.

— Багамат