BIND9 Problema do SERVFAIL com o servidor DNS do Windows 2008 R2

Question

Eu estava procurando por um problema estranho com o BIND 9 quando uma das instâncias do Windows 2008 R2 foi apontada como um encaminhador. Especificamente, quando o DNSSEC é ativado no BIND, alguns nomes de domínio não são resolvidos em circunstâncias específicas. Esses problemas são resolvidos espontaneamente quando são alternados para um servidor DNS público, como o 8.8.8.8 do Google.

Observando isso mais, aparece quando o EDNS está ativado no servidor DNS do Windows 2008 R2 (padrão, aceitando respostas DNSSEC), a resolução falha ocasionalmente com um SERVFAIL quando NODATA é retornado para BIND (ou seja, 0 respostas com um código de status de NOERROR.)

Por exemplo, o tipo SRV mx2.comcast.com falhará quando pesquisado no servidor DNS do Windows 2008 R2 apontado como BIND como um encaminhador, mas o tipo SRV bat.comcast.com funciona muito bem.

Fazendo a consulta localmente com escavação, recebo estes resultados:

mx2.comcast.com SRV - consulta BIND local

; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42484
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
mx2.comcast.com.        3600    IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=
mx2.comcast.com.        3600    IN      NSEC    mx3.comcast.com. A RRSIG NSEC
comcast.com.            3600    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            3600    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=

Mesma consulta, mas feita com o servidor DNS do Google:

; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 mx2.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3537
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1800    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1800    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
mx2.comcast.com.        3600    IN      NSEC    mx3.comcast.com. A RRSIG NSEC
mx2.comcast.com.        3600    IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. pmOHJX7dSNuFSRiFvxNIIuhQk/Sh6/9xSiZ2wj2I6RDKkrQlDScdFjDB nSpeWt9068Wq+aQE36dbTsvyyCKgtrPcJIUxKVCtsXzTavXdx9XVGwG9 cKF6TrQx+MGPRwRwjPorDmPJxImveGMeE7X4Nl1mkGk/lRJwbvk1yFWV w1w=

Ao usar o Windows com o servidor BIND como encaminhador:

; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57054
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

e com o DNS do Google como encaminhador:

; <<>> DiG 9.9.3-P1 <<>> mx2.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56582
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mx2.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

Agora, tentando isso com bat.comcast.com:

; <<>> DiG 9.9.2-P1 <<>> @127.0.0.1 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2383
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1603    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1603    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 1603 IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=
awrelaypool02.comcast.com. 1603 IN      NSEC    www.bat.comcast.com. A RRSIG NSEC

e resolvedor do Google:

; <<>> DiG 9.9.2-P1 <<>> @8.8.8.8 bat.comcast.com SRV +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28253
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            1800    IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600
comcast.com.            1800    IN      RRSIG   SOA 5 2 3600 20130711200520 20130704170020 2643 comcast.com. Te6jKcUXakWpPGQYpZICPShPZYEHHEcCnfFoof6VfOLPhhQP5MlWMbni QSQTY1UZLLCqU0j2U5n48wAMrSLSXoye+9W+pFnHtSl00fCQoQJ2ts+x DDQkdcJo2jWhNHGr6zsP6y9clhLUkFRW7ZVdqCV62KtTumU8Qe4UOjNK R3s=
awrelaypool02.comcast.com. 3600 IN      NSEC    www.bat.comcast.com. A RRSIG NSEC
awrelaypool02.comcast.com. 3600 IN      RRSIG   NSEC 5 3 3600 20130711200520 20130704170020 2643 comcast.com. U87nbvAj7j7pAk4kigqMyVy8XDeHqRP9756PTQsucrRTEchtScfBKWLl Eo7cWJc4Vcsfept+ixg0IiAxpwHATqwNTmq/giAeglFfeFmMHlXrhdOl Bl5myReo1gSXlpm0+bvinOFRek/MUlYGLvDAq17noJag2k1oXrvhaNBo qWo=

Mais uma vez com o Windows (BIND Resolver) :

; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11140
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

Mais uma vez com o Windows (Google Resolver) :

; <<>> DiG 9.9.3-P1 <<>> bat.comcast.com SRV @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;bat.comcast.com.               IN      SRV

;; AUTHORITY SECTION:
comcast.com.            900     IN      SOA     dns101.comcast.net. domregtech.comcastonline.com. 2009085823 7200 3600 1209600 3600

Analisando esses resultados, a resolução do Windows falha no mx2.comcast.com, ainda que tenha sucesso no bat.comcast.com e, a partir do código de erro reportado pelo Windows (SERVFAIL), pode parecer inicialmente que a validação do DNSSEC está falhando, embora esse não era o caso, pois todas as respostas da consulta tinham o bit 'anúncio' (autenticado) definido nelas. Dito isso, o BIND parece ter uma tendência intrigante para adulterar a ordem em que os RRs da seção de autoridade aparecem. Olhando para a consulta do Google para mx2.comcast.com, podemos ver que a seção de autoridade aparece nesta ordem (é assim que o servidor autoritativo responde também):

• SOA
• RRSIG - SOA
• NSEC
• RRSIG - NSEC

enquanto o BIND retorna respostas nesta ordem:

• RRSIG - NSEC
• NSEC
• SOA
• RRSIG - SOA

Para o bat.comcast.com, o Google responde nesta ordem:

• SOA
• RRSIG - SOA
• NSEC
• RRSIG - NSEC

e o BIND responde nesta ordem:

• SOA
• RRSIG - SOA
• RRSIG - NSEC
• NSEC

Dado que a primeira consulta falhou no Windows, mas a segunda funciona bem, parece evidente que o Windows 2008 R2 requer que o registro SOA apareça primeiro quando não houver respostas e o código de retorno = NOERROR. (Observe que, se o servidor remoto retornou um NXDOMAIN, a ordenação desses RRs não parece importar, e o Windows retornará NXDOMAIN de acordo com o cliente).

Olhando a documentação do BIND e veja se há alguma opção de configuração que controle a ordenação desses RRs, mas sem sucesso. Veja o que tentei:

    rfc2308-type1 yes;
    minimal-responses yes;
    rrset-order {order fixed;};

Eu também tentei atualizar a versão local do BIND para 9.9.3-P1 de 9.9.2-P1, mas o comportamento não parece ter mudado.

Finalmente, eu poderia teoricamente desabilitar o suporte EDNS no Windows 2008 R2 como uma solução alternativa e ter essas consultas funcionando (já que a desativação do EDNS também suprimiria o sinalizador DO para DNSSEC, omitindo assim o RRSIG e o NSEC RRs na resposta), embora Eu preferiria deixar o EDNS ativado por sua eficiência em relação ao UDP.

Alguém sabe alguma coisa que estou sentindo falta aqui ou correu em situações semelhantes?

Qualquer comentário seria muito apreciado!

    

Answer 1

Você conseguiu validar sua suposição de que é a ordem dos registros que faz com que o MSDNS retorne SERVFAIL ? (É plausível do que você mostra na pergunta, mas não está claro para mim que outras possibilidades foram descartadas.)

Além disso, há alguma coisa registrada no lado do MSDNS relacionada à falha?

Não tenho conhecimento de nenhuma opção de vinculação que seria aplicável a como os registros RRSIG / NSEC / SOA são ordenados nesta situação.

Fora das configurações mencionadas, rrset-order é o único que deve afetar o pedido, mas, de acordo com o meu conhecimento, ele é destinado a um cenário como uma resposta com vários registros A e como eles devem ser solicitados, e não isso. / p>

De qualquer forma, o valor fixed não é suportado por padrão:

In this release of BIND 9, the rrset-order statement does not support "fixed" ordering by default. Fixed ordering can be enabled at compile time by specifying "--enable-fixed-rrset" on the "configure" command line.

Parece-me que, se a ordenação é o que causa o seu problema, o MSDNS ou o BIND tem um erro.

É óbvio que o BIND alterou a ordem dos registros em sua resposta, mas não é óbvio (para mim de qualquer maneira) por que isso seria um problema.