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 + trace, поступающий с IP-адреса в acl для внутреннего представления, никогда не потерпит неудачу при выполнении dig + trace для зоны внутри внутреннего представления. Это только кажется неудачным, когда вы копаете + отслеживаете зоны во внешнем виде с IP-адреса, указывающего на внутреннее представление.