Servidor 2012R2 do servidor DNS retornando SERVFAIL para algumas consultas AAAA


17

(Reescrevendo a maior parte dessa pergunta, pois muitos dos meus testes originais são irrelevantes à luz de novas informações)

Estou tendo problemas com os servidores DNS do servidor 2012R2. O maior efeito colateral desses problemas é que os emails do Exchange não são enviados. Troque consultas por registros AAAA antes de tentar os registros A. Quando vê SERVFAIL para o registro AAAA, nem tenta os registros A, apenas desiste.

Para alguns domínios, ao consultar nos servidores DNS do diretório ativo, recebo SERVFAIL em vez de NOERROR sem resultados.

Eu tentei isso em vários controladores de domínio Server 2012R2 diferentes que estão executando o DNS. Um deles é um domínio totalmente separado, em uma rede diferente atrás de um firewall e conexão à Internet diferentes.

Dois endereços que conheço causam esse problema são smtpgw1.gov.on.caemxmta.owm.bell.net

Eu tenho usado digem uma máquina Linux para testar isso (192.168.5.5 é o meu controlador de domínio):

grant@linuxbox:~$ dig @192.168.5.5 smtpgw1.gov.on.ca -t AAAA

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.5.5 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56328
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;smtpgw1.gov.on.ca.             IN      AAAA

;; Query time: 90 msec
;; SERVER: 192.168.5.5#53(192.168.5.5)
;; WHEN: Wed Oct 21 14:09:10 EDT 2015
;; MSG SIZE  rcvd: 46

Mas as consultas contra um controlador de domínio público funcionam conforme o esperado:

grant@home-ssh:~$ dig @4.2.2.1 smtpgw1.gov.on.ca -t AAAA

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @4.2.2.1 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;smtpgw1.gov.on.ca.             IN      AAAA

;; Query time: 136 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Wed Oct 21 14:11:19 EDT 2015
;; MSG SIZE  rcvd: 46

Como eu disse, tentei isso em duas redes e domínios diferentes. Um é um domínio totalmente novo, que definitivamente possui todas as configurações padrão do DNS. O outro foi migrado para o Server 2012, portanto, algumas configurações antigas de 2003/2008 podem ter sido transferidas. Eu obtenho os mesmos resultados em ambos.

Desabilitar o EDNS com o dmscnd /config /enableednsprobes 0corrige. Vejo muitos resultados de pesquisa sobre o EDNS ser um problema no Server 2003, mas não muito que corresponda ao que estou vendo no Server 2012. Nenhum dos firewalls tem um problema com o EDNS. A desativação do EDNS deve ser apenas uma solução temporária - evita o uso do DNSSEC e pode causar outros problemas.

Também vi algumas postagens sobre problemas com o Server 2008R2 e o EDNS, mas essas mesmas postagens dizem que as coisas foram corrigidas no Server 2012, portanto, ele deve funcionar corretamente.

Eu também tentei habilitar o log de depuração para DNS. Posso ver os pacotes que eu esperava, mas isso não me dá muita idéia do motivo pelo qual está retornando o SERVFAIL. Aqui estão as partes relevantes do log de depuração do servidor DNS:

Primeiro pacote - consulta do cliente ao meu servidor DNS

16/10/2015 09:42:29 0974 PACKET 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) em (2) ca (0)
Informações da pergunta UDP em 000000EFF1BF01A0
  Soquete = 508
  Endereço remoto 172.16.0.254, porta 50764
  Consulta de tempo = 4556080, Na fila = 0, Expiração = 0
  Comprimento do Buf = 0x0fa0 (4000)
  Comprimento da mensagem = 0x002e (46)
  Mensagem:
    XID 0xa61e
    Sinalizadores 0x0120
      QR 0 (PERGUNTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 1
      RA 0
      Z 0
      CD 0
      AD 1
      RCODE 0 (NOERROR)
    QCOUNT 1
    CONTA 0
    NSCOUNT 0
    ARCOUNT 1
    SEÇÃO PERGUNTA:
    Deslocamento = 0x000c, contagem RR = 0
    Nome "(7) smtpgw1 (3) gov (2) em (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SEÇÃO DE RESPOSTA:
      esvaziar
    SEÇÃO DA AUTORIDADE:
      esvaziar
    SEÇÃO ADICIONAL:
    Deslocamento = 0x0023, contagem de RR = 0
    Nome "(0)"
      OPÇÃO TIPO (41)
      CLASS 4096
      TTL 0
      DLEN 0
      DADOS   
        Tamanho do buffer = 4096
        Rcode Ext = 0
        Rcode completo = 0
        Versão = 0
        Sinalizadores = 0

Segundo pacote - consulta do meu servidor DNS para o servidor DNS

16/10/2015 09:42:29 0974 PACKET 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) em (2) ca (0)
Informações da pergunta UDP em 000000EFF0A22160
  Soquete = 9812
  Endereço remoto 204.41.8.237, porta 53
  Consulta de tempo = 0, Na fila = 0, Expiração = 0
  Comprimento do Buf = 0x0fa0 (4000)
  Comprimento da mensagem = 0x0023 (35)
  Mensagem:
    XID 0x3e6c
    Sinalizadores 0x0000
      QR 0 (PERGUNTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      RCODE 0 (NOERROR)
    QCOUNT 1
    CONTA 0
    NSCOUNT 0
    ARCOUNT 0
    SEÇÃO PERGUNTA:
    Deslocamento = 0x000c, contagem RR = 0
    Nome "(7) smtpgw1 (3) gov (2) em (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SEÇÃO DE RESPOSTA:
      esvaziar
    SEÇÃO DA AUTORIDADE:
      esvaziar
    SEÇÃO ADICIONAL:
      esvaziar

Terceiro pacote - resposta do servidor DNS (NOERROR)

16/10/2015 09:42:29 0974 PACKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) em (2) ca (0)
Informações de resposta UDP em 000000EFF2188100
  Soquete = 9812
  Endereço remoto 204.41.8.237, porta 53
  Consulta de tempo = 4556080, Na fila = 0, Expiração = 0
  Comprimento do Buf = 0x0fa0 (4000)
  Comprimento da mensagem = 0x0023 (35)
  Mensagem:
    XID 0x3e6c
    Sinalizadores 0x8400
      QR 1 (RESPOSTA)
      OPCODE 0 (CONSULTA)
      AA 1
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      RCODE 0 (NOERROR)
    QCOUNT 1
    CONTA 0
    NSCOUNT 0
    ARCOUNT 0
    SEÇÃO PERGUNTA:
    Deslocamento = 0x000c, contagem RR = 0
    Nome "(7) smtpgw1 (3) gov (2) em (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SEÇÃO DE RESPOSTA:
      esvaziar
    SEÇÃO DA AUTORIDADE:
      esvaziar
    SEÇÃO ADICIONAL:
      esvaziar

Quarto pacote - resposta do meu servidor DNS para o cliente (SERVFAIL)

16/10/2015 09:42:29 0974 PACKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) em (2) ca (0)
Informações de resposta UDP em 000000EFF1BF01A0
  Soquete = 508
  Endereço remoto 172.16.0.254, porta 50764
  Consulta de tempo = 4556080, Na fila = 4556080, Expiração = 4556083
  Comprimento do Buf = 0x0fa0 (4000)
  Comprimento da mensagem = 0x002e (46)
  Mensagem:
    XID 0xa61e
    Sinalizadores 0x8182
      QR 1 (RESPOSTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 1
      RA 1
      Z 0
      CD 0
      AD 0
      RCODE 2 (SERVFAIL)
    QCOUNT 1
    CONTA 0
    NSCOUNT 0
    ARCOUNT 1
    SEÇÃO PERGUNTA:
    Deslocamento = 0x000c, contagem RR = 0
    Nome "(7) smtpgw1 (3) gov (2) em (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SEÇÃO DE RESPOSTA:
      esvaziar
    SEÇÃO DA AUTORIDADE:
      esvaziar
    SEÇÃO ADICIONAL:
    Deslocamento = 0x0023, contagem de RR = 0
    Nome "(0)"
      OPÇÃO TIPO (41)
      CLASS 4000
      TTL 0
      DLEN 0
      DADOS   
        Tamanho do buffer = 4000
        Rcode Ext = 0
        Rcode completo = 2
        Versão = 0
        Sinalizadores = 0

Outras coisas a serem observadas:

  • Uma das redes possui acesso à Internet IPv6 nativo, a outra não (mas a pilha IPv6 está ativada nos servidores com configurações padrão). Não parece ser um problema de rede IPv6
  • Não afeta todos os domínios. Por exemplo, dig @192.168.5.5 -t AAAA serverfault.comretorna NOERROR e nenhum resultado. O mesmo vale para google.comos endereços IPv6 do Google corretamente.
  • Tentei instalar o hotfix do KB3014171 , não fez diferença.
  • A atualização do KB3004539 já está instalada.

Editar 7 de novembro de 2015

I tenha configurado outro sem domínio juntou máquina servidor 2012R2, e função de servidor DNS instalado e testado com o comando nslookup -type=aaaa smtpgw1.gov.on.ca localhost. NÃO tem os mesmos problemas.

As duas VMs estão no mesmo host e na mesma rede, o que elimina quaisquer problemas de rede / firewall. Agora, cabe ao nível do patch ou ser um membro / controlador de domínio que faz a diferença.

Editar 8 de novembro de 2015

Aplicou todas as atualizações, não fez diferença. Fiz uma verificação dupla se havia alguma diferença de configuração entre o meu novo servidor de teste e as configurações DNS do meu controlador de domínio, e existem - o controlador de domínio tinha os encaminhadores configurados.

Agora, tenho certeza de que tentei com encaminhadores e sem os meus testes iniciais, mas só tentei usando diguma máquina Linux. Recebo resultados ligeiramente diferentes com e sem a instalação de encaminhadores (tentei com o Google, OpenDNS, 4.2.2.1 e meus servidores DNS do ISP) quando uso o nslookup em uma máquina Windows.

Com um encaminhador definido, eu entendo Server failed.

Sem um encaminhador (então ele usa servidores DNS raiz), eu recebo No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Mas ainda não é o mesmo que recebo em outros domínios que não possuem registros IPv6 - o nslookup no Windows simplesmente não retorna resultados para outros domínios.

Com ou sem encaminhadores, digainda aparece SERVFAILpara esse nome ao consultar o servidor DNS do Windows.

Há uma pequena diferença entre o domínio do problema e outros que parece relevante, mesmo quando não envolvo o servidor DNS do Windows:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca não tem respostas e não possui uma seção de autoridade.

dig -t aaaa @8.8.8.8 serverfault.comnão retorna respostas, mas possui uma seção de autoridade. O mesmo acontece com a maioria dos outros domínios que tento, independentemente do resolvedor que eu uso.

Então, por que essa seção de autoridade está ausente e por que o servidor DNS do Windows a trata como uma falha quando outros servidores DNS não o fazem?


Você está executando esses testes no servidor Exchange? Caso contrário, sugiro fazer isso para que você possa vê-lo da perspectiva do Exchange. Você pode tentar executar o SMTPDiag também no servidor Exchange. Sugiro executá-lo enquanto estiver executando uma captura de rede no servidor Exchange, para que você possa exibir os detalhes da atividade de rede / DNS. O SMTPDiag é uma ferramenta antiga, mas é uma ferramenta de linha de comando que não requer instalação, por isso acho que deve funcionar em todas as versões do Exchange. - microsoft.com/en-us/download/details.aspx?id=11393 #
joeqwerty

Alguns dispositivos de rede não reconhecem e rejeitam pacotes EDNS. Sua equipe de rede introduziu novo dispositivo / configuração recentemente? Para eliminar essa possibilidade, tente resolver o registro AAAA do google.com, ele deve retornar um endereço IPv6.
strongline

Os pacotes @strongline EDNS são excelentes. O registro AAAA para o google funciona, assim como outros sites que eu conheço com o IPv6 em execução. A única chance feita recentemente foi se livrar do nosso último servidor Server 2008R2 DC / DNS e substituí-lo pelo 2012R2.
Grant

O IPv6 está desativado de alguma forma no seu ambiente?
Jim B

@ JimB realmente não está ativado ou desativado ... A pilha IPv6 está sendo executada nos servidores, porque está ativada por padrão, com qualquer configuração padrão que ela tenha. O gateway e a conexão à Internet não têm IPv6.
Grant

Respostas:


3

Examinei a rede mais um pouco e fiz algumas leituras. A solicitação para o registro AAAA, quando inexistente, retorna um SOA. Acontece que a SOA é para um domínio diferente daquele solicitado. Eu suspeito que é por isso que o Windows está rejeitando a resposta. Solicite AAAA para mx.atomwide.com. SOA de resposta para lgfl.org.uk. Vou ver se podemos fazer algum progresso com essa informação. EDIT: Apenas para referência futura, desativar temporariamente "Cache seguro contra poluição" permitirá que a consulta seja bem-sucedida. Não é o ideal, mas prova que o problema é com um registro DNS desonesto. RFC4074 também é uma boa referência - Introdução e Seção.


Vou tentar testar isso hoje no meu ambiente, mas acho que você pode estar interessado em alguma coisa!
Grant

Também editei o seu link - assinaturas e links fora do tópico não são permitidos aqui, e não quero que sua resposta excelente seja excluída por isso.
Grant

0

De acordo com KB832223

Causa

Esse problema ocorre devido à funcionalidade de mecanismos de extensão para DNS (EDNS0) suportada no DNS do Windows Server.

O EDNS0 permite tamanhos maiores de pacotes UDP (User Datagram Protocol). No entanto, alguns programas de firewall podem não permitir pacotes UDP maiores que 512 bytes. Portanto, esses pacotes DNS podem ser bloqueados pelo firewall.

A Microsoft tem a seguinte resolução:

Resolução

Para resolver esse problema, atualize o programa de firewall para reconhecer e permitir pacotes UDP maiores que 512 bytes. Para obter mais informações sobre como fazer isso, contate o fabricante do seu programa de firewall.

A Microsoft tem a seguinte sugestão para solucionar o problema:

Gambiarra

Para contornar esse problema, desative o recurso EDNS0 nos servidores DNS baseados no Windows. Para fazer isso, execute a seguinte ação:

Em um prompt de comando, digite o seguinte comando e pressione Enter:

dnscmd /config /enableednsprobes 0

Nota Digite um 0 (zero) e não a letra "O" depois de "enabledednsprobes" neste comando.


Eu vi esse artigo - os firewalls que testei com ambos passam por grandes pacotes DNS sem problemas, como evidenciado por ele funcionando perfeitamente no Linux. Desativar edns impede o uso do DNSSEC, portanto, embora ele resolva o problema, não é uma boa solução.
Grant

desculpe, eu não sabia que as orientações da Microsoft também se aplicavam ao Linux. Por curiosidade, você tem algum sistema operacional da Microsoft que esteja funcionando através do firewall?
Tim Penner
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.