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

Привязка DNS - Использование представлений Внешние зоны не передаются ведомому устройству

Краткое описание моей проблемы заключается в том, что мы начали обновление DNS-сервера здесь, на моем предприятии.

В настоящее время у нас есть 2 внутренних DNS-сервера и 2 внешних DNS-сервера. Мы обновляем оборудование и объединяем наши серверы, так что у нас есть 1 главный и 1 подчиненный, которые будут заботиться как о внутренних, так и о внешних DNS. Оба сервера имеют два сетевых адаптера, которые были подключены к IP: один адрес находится во внешней сети общего пользования, а другой - во внутренней. На моем мастере я установил внутреннее представление, которое доступно только из диапазонов нашей внутренней сети, и внешнее представление, которое может запрашивать кто угодно. У меня все настроено, и разрешение DNS работает нормально. Проблема, с которой я сталкиваюсь, заключается в том, что когда я настроил подчиненное устройство и установил его, подчиненное устройство будет наследовать обновления только для зон, перечисленных во внутреннем представлении. Все зоны внешнего обзора выдают ошибку 

;<<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>> IN AXFR 43.96.32.in-addr.arpa @129.yy.yy.10 
;; global options: +cmd 
; Transfer failed.

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

Ниже я приведу образцы моих файлов master / slave named.conf. Моя система в настоящее время работает под управлением RHEL 6.6 и Bind DNS 9.8.2.

Мастер - Named.conf

acl internal_hosts { 10.101.0.0/16; 172.21.0.0/16;
10.2.0.0/16; 169.254.0.0/16;
172.23.0.0/16; 32.0.0.0/8;
12.109.164.0/24; 12.109.165.0/24;
63.79.18.0/24; 63.88.0.0/16;
129.42.0.0/16; 4.30.26.0/24;
4.28.188.0/24; 172.21.131.248/29;};
acl internal_slave { 10.xx.xx.2; };
acl external_slave { 129.yy.yy.11; };
acl internal_master { 10.xx.xx.1; };
acl external_master { 129.yy.yy.10; };

options {
    directory "/etc";
    pid-file "/var/run/named/named.pid";
    dnssec-enable no;
    query-source port 53;
    forward only;
    notify yes;
    allow-query { any; };
    listen-on {
        10.xx.xx.1;
        127.0.0.1;
        129.yy.yy.10;
    };
    forwarders {
        129.34.20.80;
        198.4.83.35;
        4.2.2.2;
        8.8.8.8;
    };
    allow-transfer {127.0.0.1; };
};


server 10.xx.xx.2 {
    transfer-format many-answers;
    transfers 10000;
};
server 129.yy.yy.11 {
    transfer-format many-answers;
    transfers 10000;
};

view "Internal" {

    match-clients { internal_hosts; !external_slave; internal_slave; };
    also-notify { 10.xx.xx.2; };
    allow-transfer { internal_slave; };
    recursion yes;
    allow-recursion { internal_hosts; };
    transfer-source 10.xx.xx.1;


    zone "64.2.10.in-addr.arpa" {
        type master;
        also-notify { 10.xx.xx.2; };
        notify yes;
        allow-transfer { internal_slave; };
        file "/var/named/10.2.64.rev";
    };


view "External" {

    match-clients { !internal_slave; external_slave; any; };
    recursion no;
    allow-transfer { external_slave; };
    also-notify { 129.yy.yy.11; };
    transfer-source 129.yy.yy.10;

    zone "50.146.204.in-addr.arpa" {
        type master;
        notify yes;
        also-notify {129.yy.yy.11;};
        allow-transfer {external_slave;};
        file "/var/named/204.146.50.rev";
    };

Подчиненный - Named.conf

acl internal_hosts { 10.101.0.0/16; 172.21.0.0/16;
    10.2.0.0/16; 169.254.0.0/16;
    172.23.0.0/16; 32.0.0.0/8;
    12.109.164.0/24; 12.109.165.0/24;
    63.79.18.0/24; 63.88.0.0/16;
    129.42.0.0/16; 4.30.26.0/24;
    4.28.188.0/24; 172.21.131.248/29;
};
acl internal_slave { 10.xx.xx.2; };
acl external_slave { 129.yy.yy.11; };
acl internal_master { 10.xx.xx.1; };
acl external_master { 129.yy.yy.10; };

options {
    directory "/etc";
    pid-file "/var/run/named/named.pid";
    dnssec-enable no;
    query-source port 53;
    forward only;
    allow-query { any; };
    listen-on port 53 {
        127.0.0.1;
        10.xx.xx.2;
        129.yy.yy.11;
    };
    forwarders {
        129.34.20.80;
        198.4.83.35;
        4.2.2.2;
        8.8.8.8;
    };
    allow-transfer {127.0.0.1; };
};


server 10.xx.xx.1 {
    transfer-format many-answers;
    transfers 10000;
};

server 129.yy.yy.10 {
    transfer-format many-answers;
    transfers 10000;
};

view "Internal" {
    match-clients { internal_hosts; !external_master; internal_master; };
    recursion yes;
    allow-recursion {internal_hosts;};
    allow-transfer { internal_master; };
    transfer-source 10.xx.xx.2;
    allow-notify {10.xx.xx.1;};

    zone "64.2.10.in-addr.arpa" {
        type slave;
        masters {10.xx.xx.1;};
        allow-transfer {internal_master;};
        allow-update {internal_master;};
        file "/var/named/slaves/10.2.64.Internal.rev";
    };


view "External" {
    allow-transfer {external_master;};
    allow-notify {129.yy.yy.10;};
    transfer-source 129.yy.yy.11;
    match-clients {!internal_master; external_master; internal_hosts; any;};
    recursion no;

    zone "50.146.204.in-addr.arpa" {
        type slave;
        masters {129.yy.yy.10;};
        allow-transfer {external_master;};
        allow-update {external_master;};
        file "/var/named/slaves/204.146.50.External.rev";
    };

Вот вывод из моего / var / log / messages, запрошенных о DIG моему Мастеру. DIG для brsbld.ihost.com - это ошибка во внешнем представлении, тогда как DIG для bldbcrs.net находится во внутреннем представлении и проходит нормально.

Apr 17 09:32:31 bbridns01 named[1717]: client 10.101.8.2#55756: view Internal: transfer of 'bldbcrs.net/IN': AXFR started
Apr 17 09:32:31 bbridns01 named[1717]: client 10.101.8.2#55756: view Internal: transfer of 'bldbcrs.net/IN': AXFR started
Apr 17 09:32:31 bbridns01 named[1717]: client 10.101.8.2#55756: view Internal: transfer of 'bldbcrs.net/IN': AXFR ended
Apr 17 09:32:31 bbridns01 named[1717]: client 10.101.8.2#55756: view Internal: transfer of 'bldbcrs.net/IN': AXFR ended
Apr 17 09:32:56 bbridns01 named[1717]: client 129.42.206.11#41783: view Internal: bad zone transfer request: 'brsbld.ihost.com/IN': non-authoritative zone (NOTAUTH)
Apr 17 09:32:56 bbridns01 named[1717]: client 129.42.206.11#41783: view Internal: bad zone transfer request: 'brsbld.ihost.com/IN': non-authoritative zone (NOTAUTH)

Он, ребята, просто хотел обновить это, чтобы вы знали, что я нашел для решения. С моей внутренней точки зрения аргумент о совпадении клиентов приводил меня в замешательство.

match-clients { internal_hosts; !external_slave; internal_slave; };

ACL internal_hosts включает диапазон 129.42.0.0/16. Он был указан перед! External_slave; аргумент, поэтому он сначала взял это, потому что подчиненный сервер - 129.42.206.11, и поместил его во внутреннее представление. Я изменил его так, чтобы он сначала исключал external_slave, а затем его правильно подбирал внешний вид. 

match-clients { !external_slave; internal_hosts; internal_slave; };

Я предполагаю, что эта строка в ваших основных параметрах конфигурации не позволяет другим получить зоны: 

allow-transfer {127.0.0.1; };

Я бы попробовал удалить эту строку или обновить ее, чтобы включить ваш external_master.

Возможно, это связано с тем, что у вас есть несколько представлений в вашей конфигурации, представление по умолчанию получает эту ограниченную директиву разрешения-передачи из параметров.
http://docs.freebsd.org/doc/8.3-RELEASE/usr/share/doc/bind9/arm/Bv9ARM.ch06.html