(Reescrevendo a maior parte desta questão, já que muitos dos meus testes originais são irrelevantes à luz de novas informações)
Estou tendo problemas com os servidores DNS do Server 2012R2. O maior efeito colateral desses problemas é que os e-mails do Exchange não são enviados. Troque consultas por registros AAAA antes de tentar registros A. Quando vê SERVFAIL para o registro AAAA, ele nem tenta os registros A, apenas desiste.
Para alguns domínios, ao consultar meus servidores DNS do Active Directory, recebo SERVFAIL em vez de NOERROR sem resultados.
Eu tentei isso em vários controladores de domínio Server 2012R2 diferentes que executam DNS. Um deles é um domínio totalmente separado, em uma rede diferente, atrás de um firewall e conexão de Internet diferentes.
Dois endereços que eu sei que causam esse problema são smtpgw1.gov.on.caemxmta.owm.bell.net
Estou usando digem uma máquina Linux para testar isso (192.168.5.5 é 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 em 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 deles é um domínio totalmente novo, que definitivamente possui todas as configurações padrão de DNS. O outro foi migrado para o Server 2012, portanto algumas configurações antigas de 2003/2008 podem ter sido transferidas. Obtenho os mesmos resultados em ambos.
Desativar o EDNS dmscnd /config /enableednsprobes 0corrige o problema. 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 problemas com o EDNS. Desativar o EDNS deve ser apenas uma solução temporária - impede o uso de DNSSEC e pode causar outros problemas.
Também vi algumas postagens sobre problemas com o Server 2008R2 e EDNS, mas essas mesmas postagens dizem que as coisas foram corrigidas no Server 2012, portanto, deve funcionar corretamente.
Também tentei ativar o log de depuração para DNS. Posso ver os pacotes que esperava, mas isso não me dá muita ideia do motivo pelo qual está retornando 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 9:42:29 0974 PACOTE 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7)smtpgw1(3)gov(2)on(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 buffer = 0x0fa0 (4000)
Comprimento da mensagem = 0x002e (46)
Mensagem:
XID0xa61e
Bandeiras 0x0120
QR 0 (PERGUNTA)
OPCODE 0 (CONSULTA)
AA 0
TC 0
DR 1
RA 0
Z 0
CD 0
1 DC
RCODE 0 (NOERROR)
QCONTAR 1
CONTA 0
NSCONTAR 0
ARCO 1
SEÇÃO DE PERGUNTAS:
Deslocamento = 0x000c, contagem RR = 0
Nome "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTIPO AAAA (28)
QCLASSE 1
SEÇÃO DE RESPOSTA:
vazio
SEÇÃO DE AUTORIDADE:
vazio
SEÇÃO ADICIONAL:
Deslocamento = 0x0023, contagem RR = 0
Nome "(0)"
TIPO OPÇÃO (41)
CLASSE 4096
TTL 0
DLEN 0
DADOS
Tamanho do buffer = 4096
Extensão do código R = 0
Código R completo = 0
Versão = 0
Bandeiras = 0
Segundo pacote - consulta do meu servidor DNS para o servidor DNS deles
16/10/2015 9:42:29 0974 PACOTE 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7)smtpgw1(3)gov(2)on(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 buffer = 0x0fa0 (4000)
Comprimento da mensagem = 0x0023 (35)
Mensagem:
XID0x3e6c
Sinalizadores 0x0000
QR 0 (PERGUNTA)
OPCODE 0 (CONSULTA)
AA 0
TC 0
DR 0
RA 0
Z 0
CD 0
d.C. 0
RCODE 0 (NOERROR)
QCONTAR 1
CONTA 0
NSCONTAR 0
ARCO 0
SEÇÃO DE PERGUNTAS:
Deslocamento = 0x000c, contagem RR = 0
Nome "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTIPO AAAA (28)
QCLASSE 1
SEÇÃO DE RESPOSTA:
vazio
SEÇÃO DE AUTORIDADE:
vazio
SEÇÃO ADICIONAL:
vazio
Terceiro pacote – resposta do servidor DNS (NOERROR)
16/10/2015 9:42:29 0974 PACOTE 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7)smtpgw1(3)gov(2)on(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 buffer = 0x0fa0 (4000)
Comprimento da mensagem = 0x0023 (35)
Mensagem:
XID0x3e6c
Sinalizadores 0x8400
QR 1 (RESPOSTA)
OPCODE 0 (CONSULTA)
AA 1
TC 0
DR 0
RA 0
Z 0
CD 0
d.C. 0
RCODE 0 (NOERROR)
QCONTAR 1
CONTA 0
NSCONTAR 0
ARCO 0
SEÇÃO DE PERGUNTAS:
Deslocamento = 0x000c, contagem RR = 0
Nome "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTIPO AAAA (28)
QCLASSE 1
SEÇÃO DE RESPOSTA:
vazio
SEÇÃO DE AUTORIDADE:
vazio
SEÇÃO ADICIONAL:
vazio
Quarto pacote – resposta do meu servidor DNS para o cliente (SERVFAIL)
16/10/2015 9:42:29 0974 PACOTE 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7)smtpgw1(3)gov(2)on(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 buffer = 0x0fa0 (4000)
Comprimento da mensagem = 0x002e (46)
Mensagem:
XID0xa61e
Sinalizadores 0x8182
QR 1 (RESPOSTA)
OPCODE 0 (CONSULTA)
AA 0
TC 0
DR 1
AR 1
Z 0
CD 0
d.C. 0
RCODE 2 (SERVFAIL)
QCONTAR 1
CONTA 0
NSCONTAR 0
ARCO 1
SEÇÃO DE PERGUNTAS:
Deslocamento = 0x000c, contagem RR = 0
Nome "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTIPO AAAA (28)
QCLASSE 1
SEÇÃO DE RESPOSTA:
vazio
SEÇÃO DE AUTORIDADE:
vazio
SEÇÃO ADICIONAL:
Deslocamento = 0x0023, contagem RR = 0
Nome "(0)"
TIPO OPÇÃO (41)
CLASSE 4000
TTL 0
DLEN 0
DADOS
Tamanho do buffer = 4000
Extensão do código R = 0
Código R completo = 2
Versão = 0
Bandeiras = 0
Outras coisas dignas de nota:
- Uma das redes possui acesso nativo à Internet IPv6, a outra não (mas a pilha IPv6 está habilitada nos servidores com configurações padrão). Não parece ser um problema de rede IPv6
- Isso não afeta todos os domínios. Por exemplo,
dig @192.168.5.5 -t AAAA serverfault.comretorna NOERROR e nenhum resultado. A mesma coisa paragoogle.comretornar os endereços IPv6 do Google corretamente. - Tentei instalar o hotfix deKB3014171, não fez diferença.
- A atualização deKB3004539já está instalado.
Editar 7 de novembro de 2015
Eu configurei outra máquina Server 2012R2 não associada ao domínio, instalei a função de servidor DNS e testei com o comando nslookup -type=aaaa smtpgw1.gov.on.ca localhost. NÃO tem os mesmos problemas.
Ambas as VMs estão no mesmo host e na mesma rede, o que elimina quaisquer problemas de rede/firewall. Agora está no nível de patch ou em ser um membro de domínio/controlador de domínio que faz a diferença.
Editar 8 de novembro de 2015
Apliquei todas as atualizações, não fez diferença. Verifiquei novamente se havia alguma diferença de configuração entre meu novo servidor de teste e as configurações de DNS do meu controlador de domínio, e há - o controlador de domínio tinha encaminhadores configurados.
Agora, tenho certeza que tentei com e sem encaminhadores em meus testes iniciais, mas só tentei usando diguma máquina Linux. Obtenho resultados ligeiramente diferentes com e sem configuração de encaminhadores (tentei com Google, OpenDNS, 4.2.2.1 e meus servidores DNS do ISP) quando uso o nslookup em uma máquina Windows.
Com um conjunto de encaminhador, eu consigo Server failed.
Sem um encaminhador (portanto, ele usa servidores DNS raiz), recebo No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.
Mas isso ainda não é o mesmo que obtenho para 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 SERVFAILesse nome ao consultar meu servidor DNS do Windows.
Existe uma pequena diferença entre o domínio do problema e outros que parecem relevantes, mesmo quando não envolvo meu servidor DNS do Windows:
dig -t aaaa @8.8.8.8 smtpgw1.gov.on.canã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 uso.
Então, por que essa seção de autoridade está faltando e por que o servidor DNS do Windows a trata como uma falha quando outros servidores DNS não o fazem?
Responder1
Eu olhei mais para a rede e fiz algumas leituras. A solicitação do registro AAAA, quando inexistente, retorna um SOA. Acontece que o SOA é para um domínio diferente daquele que está sendo solicitado. Suspeito que seja por isso que o Windows está rejeitando a resposta. Solicite AAAA para mx.atomwide.com. Resposta SOA para lgfl.org.uk. Verei se podemos fazer algum progresso com essas informações. 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 está em um registro DNS duvidoso. RFC4074 também é uma boa referência - Introdução e Seção.
Responder2
De acordo comKB832223
Causa
Esse problema ocorre devido à funcionalidade Mecanismos de Extensão para DNS (EDNS0) com suporte no DNS do Windows Server.
EDNS0 permite tamanhos maiores de pacotes do User Datagram Protocol (UDP). Entretanto, 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, entre em contato com 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 em 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 0Nota Digite 0 (zero) e não a letra "O" após "enableednsprobes" neste comando.