BIND / DNS - dig + trace = Плохой переход и неправильный переход по горизонтали

У меня интересная проблема. Я начал замечать, что когда я делаю копание + трассировку одного из доменов, на которые мы отвечаем, мы получаем ошибки от наших серверов имен для «Плохого перехода», и вы можете видеть, куда он перенаправил запрос обратно в дерево пространства имен вместо того, чтобы дать ответ. К сожалению, в настоящий момент я не могу воспроизвести эту проблему. Однако я могу воспроизвести плохое (ГОРИЗОНТАЛЬНОЕ) направление. Обычно после того, как запрос обращается к нашему серверу имен, я вижу следующее:

;; BAD (HORIZONTAL) REFERRAL
;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms

Иногда это зацикливается, пока я не дойду до ошибки «слишком много поисков», и он просто отказывается, или он останавливается и пробует наш другой сервер, который затем получает ответ . Вот что интересно. Если бы мне пришлось выполнить простой поиск по серверу, который постоянно отказывал в трассировке, я получаю ответ. Если я затем повернусь и снова сделаю копать + трассировку для того же запроса, он никогда не завершится неудачей. Это почти как записи где-то кешируются, и после истечения срока его действия тогда вы снова начнете видеть сообщение. Может ли кто-нибудь помочь мне разобраться, что здесь происходит? Вот информация о нашей среде.

1) RHEL 6, работающий под управлением BIND 9.8.2

2) Официальный главный и подчиненный сервер с открытым доступом. "

3) Серверы настроены в конфигурации" просмотра ". (Двойное представление - одно для" внутреннего " "один для внешнего)

4) Похоже, что мы только начали замечать эти странности после реализации представлений.

5) Запросы, попадающие во внутреннее представление, перенаправляются во внешнее представление для зон, не содержащихся во внутреннем представлении. Для этого мы используем петлевой IP-адрес.

6) Эти полномочные серверы также настроены для ответа на неавторизованные запросы с рекурсией с помощью оператора рекурсии и корневой зоны «подсказки».

Вот наша настройка упрощено.

Главный сервер:

acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

acl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"  


options {
    directory "/var/named";
    recursive-clients 30000;
    tcp-clients 2000;
    check-names master ignore;
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named.stats.txt";
    memstatistics-file "/var/named/data/named_mem/stats.txt";
    zone-statistics yes;
    cleaning-interval 30;


// Listen on ipv4: // Adding localhost for view forwarding
listen-on port 53 { x.x.x.x; 127.0.0.1; };

// And, also listen on ipv6:
// loopback is required for view forwarding do not remove
listen-on-v6 { ::1; x.x.x.x; };

// Enforce the Customer DNS Query ACL Defined Above:
allow-query { ext_trusted; int_trusted; };

};


key "internal" {
algorithm HMAC-SHA512;
secret "xxxxxxxxx";
};

key "external" {
algorithm HMAC-SHA512;
secret "xxxxxxxx";
};

view "internal" {
    match-clients { !key external; int_trusted; key internal; };

    //IP of slave server IPv4
    server x.x.x.x {
    keys { internal; };
};
    //IP of slave server IPv6
    server x.x.x.x {
    keys { internal; };
};

    also-notify { //slave servers go here
    x.x.x.x; x.x.x.x; 

};

    allow-transfer { key internal; local_ns; int_ns; };
    empty-zones-enable no;
    server fe80::/16 { bogus yes; };
    server 0.0.0.0/8 {bogus yes; };

    zone "example.org" {
    type master;
    file "db.eamplein.org";
    allow-query { int_trusted; };
};

    forwarders {
    // forward to external view //
    127.0.0.1; ::1; 
};

    forward only;

};

view "external" {
  match-clients { any; };

 //IP of slave server IPv4
  server x.x.x.x {
  keys { external; };
};
  //IP of slave IPv6
  server x.x.x.x {
  keys { external; };
};

also-notify { //IP address of slave server
   x.x.x.x; x.x.x.x;
};

allow-transfer { key external; ext_ns; local_ns; };
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;
recursion yes;
allow-recursion { any; };

zone "." {
     type hint;
     file "/var/named/named.ca";
};


zone "example.org" {
    type master;
    file "db.eampleout.org";
    allow-query { any; };
};

zone "example.com" {
    type master;
    file "db.eample.com";
    allow-query { any; };
};

};

Конфигурация подчиненного сервера:

acl ext_trusted {
x.x.x.x; // trusted net external
}; // end of "ext_trusted" ACL definition.

acl int_trusted {
x.x.x.x; // trusted internal
}; // end of ACL for "int_trusted"  

options {
    directory "/var/named/slaves";
    recursive-clients 30000;
    tcp-clients 2000;
    check-names master ignore;
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt"; 
    cleaning-interval 30;

// Listen on ipv4:
// Change this to the proper IP address if you ever switch back!
// loopback is required for view forwarding do not remove
listen-on port 53 { 127.0.0.1; x.,x.x.x;; };

// And, also listen on ipv6:

// Configure ipv6 before uncommenting this:
// loopback is required for view forwarding do not remove
listen-on-v6 port 53 { ::1; x,x.x.x; ;

// Enforce the "trusted" ACL defined at the begining of this config file: 
allow-query { ext_trusted; int_trusted; };

};


key "internal" {
algorithm HMAC-SHA512;
secret "xxxxxxxxx";
};

key "external" {
algorithm HMAC-SHA512;
secret "xxxxxxxx";
};

view "internal" {
    match-clients { !key external; int_trusted; key internal; };

    //IPv4 of master server
    server x.x.x.x {
    keys { internal; };
};
    // IPv6
    server x.x.x.x. {
    keys { internal; };
};
    allow-transfer { key internal; local_ns; int_ns; };
    transfer-source x.x.x.x.; 
    empty-zones-enable no;
    server fe80::/16 { bogus yes; };
    server 0.0.0.0/8 {bogus yes; };

    zone "example.org" {
    type slave;
    file "db.example.org";
    masters { x.x.x.x; x.x.x.x; };
    allow-query { int_trusted; };
};

    forwarders {
    // forward to external view // 
    127.0.0.1; ::1; 
};

    forward only;
};

view "external" {
  match-clients { any; };

 //IP of master server
 server x.x.x.x {
 keys { external; };
};
 //IPv6
 server x.x.x.x. {
 keys { external; }; 
};

allow-transfer { key external; ext_ns; local_ns; };
transfer-source x.x.x.x; 
server fe80::/16 { bogus yes; };
server 0.0.0.0/8 {bogus yes; };
empty-zones-enable yes;

recursion yes;
allow-recursion { any; };

zone "." {
    type hint;
    file "/var/named/named.ca";
};

zone "example.org" {
    type slave;
    file "db.exampleout.org";
    masters { x.x.x.x; x.x.x.x; };
    allow-query { any; };
};

zone "example.com" {
    type master;
    file "db.example.com";
    allow-query { any; }; 
};

};

ОБНОВЛЕНИЕ: просто небольшое примечание, которое я заметил, что трассировка dig +, поступающая с IP-адреса в acl для внутреннего представления, никогда не завершится ошибкой при выполнении dig + trace для зоны внутри внутренней Посмотреть. Это только кажется неудачным, когда вы копаете + отслеживаете зоны во внешнем виде с IP-адреса, указывающего на внутреннее представление.