Configure o bind9 para encaminhar as consultas como estão e para responder as respostas como estão, ou em busca de redirecionamento perferct

Question

Eu uso bind9 server ( A.A.A.A ) somente como encaminhador: as consultas são encaminhadas para outro servidor DNS ( B.B.B.B ). Eu peço manualmente ao B.B.B.B para resolver o domínio e obtive o resultado correto:

$ dig a downloadcenter.intel.com @B.B.B.B
;; ANSWER SECTION:
downloadcenter.intel.com. 182   IN      CNAME   downloadcenter.intel.com.edgekey.net.
downloadcenter.intel.com.edgekey.net. 17879 IN CNAME e11.b.akamaiedge.net.
e11.b.akamaiedge.net.   19      IN      A       172.231.112.37

Espero que bind9 server A.A.A.A faça a mesma consulta única ao servidor B.B.B.B e retorne o endereço 172.231.112.37 . Mas na realidade ele faz duas consultas: primeiro ele pede A downloadcenter.intel.com , depois ele pede A e11.b.akamaiedge.net . Existe alguma maneira de confiar na primeira resposta e fazer apenas uma consulta para B.B.B.B ?

Eu preciso disso porque eu preciso ter o mesmo IP resolvido em ambos A.A.A.A e B.B.B.B. Mas, se duas consultas são feitas, às vezes os servidores podem armazenar em cache IPs diferentes. Isso é muito comum com registros TTL baixos, como este.

Eu escava a documentação e a seção mais próxima é sobre Filtragem de Conteúdo , mas não consigo encontrar resposta direta. Eu também tentei Unbound , mas tem o mesmo problema; aqui está uma parte relacionada do código-fonte .

Log do servidor B.B.B.B que explica o problema:

Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] downloadcenter.intel.com from 192.168.0.175 ← first query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded downloadcenter.intel.com to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com.edgekey.net is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 172.231.112.37
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175 ← extra query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 2.21.192.37

A outra questão é que, se o cliente pedir A.A.A.A para resolver downloadcenter.intel.com novamente, CNAME ainda não expirou, mas A expirou, por isso bind9 pede B.B.B.B apenas para A:

Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 23.53.35.18

Eu preciso de uma maneira de encaminhar a consulta exatamente como foi solicitado. Bind9 é muito intelectual aqui. Existe uma maneira de desativar o bind9 cache?

Isso é necessário na minha configuração porque eu quero que o servidor B.B.B.B veja a solicitação do cliente original downloadcenter.intel.com todas as vezes.

Substitua bind9 por algo mais idiota? dnsmasq é a resposta perfeita, exceto pelo fato de que A.A.A.A é um host do Windows, portanto, as alternativas são limitadas.

Config de Bind9 ( A.A.A.A ):

options {
    dnssec-validation no;
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
    forwarders {
        B.B.B.B;
    };
    forward only;
};

O servidor B.B.B.B é um dnsmasq .

    

Answer 1

Sua suposição inicial está incorreta:

I expect that server A.A.A.A will do the same single query to server B.B.B.B and will return address 172.231.112.37.

Vamos analisar isso.

• O cliente está solicitando um registro do tipo A denominado downloadcenter.intel.com. .
• Não existe esse registro A .
• O servidor recursivo não pode mentir e dizer que o valor de registro A desse registro é um endereço IP. Em vez disso, ele deve informar o alias encontrado.

O resto é apenas recursão. Em termos leigos, se um servidor recursivo receber uma consulta recursiva ( RD flag está definido), ele deve assumir que o cliente é completamente estúpido e que não será capaz de realizar pesquisas recursivas próprias. Não há espaço para dividir o cabelo, porque na maioria dos casos é 100% preciso. Isso força o servidor recursivo a perseguir os aliases até chegar a uma resposta terminal, caso exista. A norma é explícita a esse respeito.