BIND / DNS - dig + trace = Referência incorreta e referência horizontal incorreta

2

Eu tenho um problema interessante. Eu comecei a perceber que quando eu faço um dig + trace em um dos domínios para os quais temos autoridade, obtemos erros de nossos servidores de nomes para "Bad Referral" e você pode ver para onde ele enviou o pedido para fazer backup da árvore de namespace responda. Infelizmente, não consigo reproduzir esse problema no momento. No entanto, posso reproduzir a referência ruim (HORIZONTAL). Basicamente, uma vez que a consulta é referida ao nosso servidor de nomes, vejo isto:

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

Às vezes, isso faz um loop até que eu atinja o erro "muitas pesquisas" e ele simplesmente desiste, ou ele pára e tenta nosso outro servidor, que recebe uma resposta. Aqui está a parte interessante. Se eu fosse realizar uma escavação simples Uma pesquisa no servidor que falhava continuamente no rastreamento, obtive uma resposta. Se eu, em seguida, virar e fazer o dig + trace contra a mesma consulta novamente, ela nunca falhará novamente. É quase como se os registros estivessem em cache em algum lugar e, depois que expirasse, você voltasse a ver a mensagem novamente. Alguém pode me ajudar a descobrir o que está acontecendo aqui? Aqui está a informação sobre o nosso ambiente.

1) RHEL 6 executando o BIND 9.8.2

2) Servidor Mestre e Escravo autoritário voltado para o público. "

3) Os servidores são configurados em uma configuração de "visualização". (visão dupla - uma para "interna" para externa)

4) Parece que acabamos de ver essas esquisitices após a implementação de visualizações.

5) Consultas que atingem a visão interna são encaminhadas para a visão externa para zonas não contidas na visão interna. Usamos o IP de loopback para conseguir isso.

6) Esses servidores autoritativos também são configurados para responder a consultas não autoritativas com recursão por meio do uso da instrução de recursão e de uma zona de "dica" de raiz.

Aqui está nossa configuração simplificada.

Servidor principal:

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; };
};

};

Configuração do servidor escravo:

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; }; 
};

};

UPDATE: apenas uma nota rápida que eu notei que um dig + trace vindo de um IP no acl para a visão interna nunca falharia em fazer um dig + trace em uma zona dentro da visão interna. Isso só parece falhar quando você digita + zonas de rastreamento na visão externa de um IP apontado para a visão interna.

    
por user53029 16.09.2016 / 20:59

1 resposta

1

Por comentário de @ andrew-b, isso geralmente ocorre devido a uma incompatibilidade na delegação.

Eu me deparei com o mesmo erro em que um desenvolvedor estava tentando fazer uma pesquisa de rastreamento + de um registro ao longo das linhas de host.subdominio.exemplo.org. A causa exata provavelmente será diferente - mas provavelmente terá um tema semelhante.

A causa em nosso caso é que temos uma regra de firewall que captura e redireciona * pesquisas de DNS enviadas para servidores "não autorizados". Em vez disso, a solicitação chegaria ao nosso próprio servidor DNS, que então realizava uma pesquisa recursiva. O cliente pensaria que estava enviando cada pesquisa sucessiva para a Internet, mas essas solicitações seriam respondidas pelo nosso servidor interno.

A correção era lembrar ao desenvolvedor o fato de que as solicitações de DNS seriam interceptadas - e que elas poderiam fazer testes de um servidor que estava na lista de permissões para ignorar a regra de redirecionamento de DNS.

Veja o erro redigido como o desenvolvedor recebeu abaixo:

tricky-desktop:~ tricky$ dig +trace host.subdomain.example.org

; <<>> DiG 9.8.3-P1 <<>> +trace host.subdomain.example.org
;; global options: +cmd
.           3600    IN  NS  g.root-servers.net.
.           3600    IN  NS  l.root-servers.net.
.           3600    IN  NS  j.root-servers.net.
.           3600    IN  NS  k.root-servers.net.
.           3600    IN  NS  b.root-servers.net.
.           3600    IN  NS  m.root-servers.net.
.           3600    IN  NS  d.root-servers.net.
.           3600    IN  NS  i.root-servers.net.
.           3600    IN  NS  e.root-servers.net.
.           3600    IN  NS  c.root-servers.net.
.           3600    IN  NS  h.root-servers.net.
.           3600    IN  NS  a.root-servers.net.
.           3600    IN  NS  f.root-servers.net.
;; Received 477 bytes from 192.168.1.2#53(192.168.1.2) in 87 ms

subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
;; Received 295 bytes from 199.43.133.53#53(199.43.133.53) in 14 ms

subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 295 bytes from 199.43.135.53#53(199.43.135.53) in 5 ms

... 29 REPEATS REDACTED ...

subdomain.example.org.  0   IN  NS  ns-outside-4.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-1.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-2.example.org.
subdomain.example.org.  0   IN  NS  ns-outside-3.example.org.
;; BAD (HORIZONTAL) REFERRAL
dig: too many lookups
tricky-desktop:~ tricky$

A regra de firewall era originalmente necessária para que a equipe do BYOD não conseguisse procurar serviços internos privados devido aos serviços de "Smart DNS" que alteravam sua configuração de DNS.

    
por 02.03.2017 / 13:16