Передача зони зв’язування відхилена

ОНОВЛЕННЯ:

Версія 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;
    };
};

Ось проблема. Коли я перезапускаю ім'я підлеглого сервера, він бачить, що файли зон ще не існують, і вимагає передачі з головного сервера:

названий.log (раб)

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

... після чого головний сервер отримує запит на передачу:

найменування.log (майстер)

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

... і відповіді на запит на передачу, який отримує відмову:

найменування.log (майстер)

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

... на підлеглому сервері це виявляється як ВІДМОВА:

названий.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користувачем.

Неважливо, що я роблю, я завжди отримую цю саму помилку. Якщо хтось може дати мені зрозуміти, чого мені не вистачає, я б дуже цінував це!

Для початку спробуйте перевірити, чи працює передача зони.

На підлеглому, видайте dig @master свій домен. axfr

Які версії BIND та яка ОС?

Знайшов проблему. Я використовую хроноване BIND, але я редагував конф-файли у / etc, а не / var / name / chroot / тощо. Тож зміни, які я робив, не були помічені. Я скопіював файли conf у каталог chroot, і це все працює нормально.

Може здатися, що це вже охоплене allow-transferтвердженням у options, але спробуйте додати явний allow-transferвислів під зоною.

Я дійсно не бачу нічого поганого у вашій конфігурації. Схоже, це має спрацювати. Це взагалі слухати на цьому порту? (Тобто чи вдаються будь-які запити? Або всі вони провалюються?)

Що ж, у мене є ще дві ідеї, які варто спробувати.

1. Переконайтесь, що ваші годинники оновлені (принаймні в межах розумного запасу) на обох серверах.

2. Можливо, вам заважає SELinux. Спробуйте тимчасово відключити його для тестування.