Tivemos problemas semelhantes em servidores DNS da Microsoft sem encaminhadores configurados. Parece que esse hotfix está relacionado: link . Eu não diria que usar forwarders negaria a aplicabilidade.
Eu tenho um controlador de domínio do Windows 2008 R2, que também é um servidor DNS. Ao resolver determinados TLDs, ele retorna um SERVFAIL:
$ dig bogus.
; <<>> DiG 9.8.1 <<>> bogus.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;bogus. IN A
Eu obtenho o mesmo resultado para um TLD real como com. ao consultar o DC como mostrado acima. Compare com um servidor BIND que está funcionando como esperado:
$ dig bogus. @128.59.59.70
; <<>> DiG 9.8.1 <<>> bogus. @128.59.59.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;bogus. IN A
;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012012501 1800 900 604800 86400
;; Query time: 18 msec
;; SERVER: 128.59.59.70#53(128.59.59.70)
;; WHEN: Wed Jan 25 14:09:14 2012
;; MSG SIZE rcvd: 98
Da mesma forma, quando eu consultar meu servidor DNS do Windows com dig . any , recebo um SERVFAIL, mas os servidores BIND retornam a zona raiz conforme o esperado.
Isso soa semelhante ao problema descrito no link , mas estou usando dois encaminhadores (128.59.59.70 acima também como 128.59.62.10) e voltando às dicas de raiz para que as condições prévias para expor a questão não sejam as mesmas. No entanto, também apliquei a correção de registro MaxCacheTTL conforme descrito e reiniciei o DNS e também o servidor inteiro, mas o problema persiste. O problema ocorre em todos os controladores de domínio neste domínio e ocorre desde há meio ano, apesar de os servidores estarem a receber atualizações automáticas do Windows.
EDITAR
Aqui está um log de depuração. O cliente é 160.39.114.110, que é minha estação de trabalho.
1/25/2012 2:16:01 PM 0E08 PACKET 000000001EA6BFD0 UDP Rcv 160.39.114.110 2e94 Q [0001 D NOERROR] A (5)bogus(0)
UDP question info at 000000001EA6BFD0
Socket = 508
Remote addr 160.39.114.110, port 49710
Time Query=1077016, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0017 (23)
Message:
XID 0x2e94
Flags 0x0100
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)bogus(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
1/25/2012 2:16:01 PM 0E08 PACKET 000000001EA6BFD0 UDP Snd 160.39.114.110 2e94 R Q [8281 DR SERVFAIL] A (5)bogus(0)
UDP response info at 000000001EA6BFD0
Socket = 508
Remote addr 160.39.114.110, port 49710
Time Query=1077016, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0017 (23)
Message:
XID 0x2e94
Flags 0x8182
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 1
Z 0
CD 0
AD 0
RCODE 2 (SERVFAIL)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)bogus(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
Todas as opções na caixa de registro de depuração foram marcadas, exceto "filtrar por IP". Por outro lado, quando eu consultar, digamos, accounts.google.com, posso ver o servidor DNS saindo para seu encaminhador (128.59.59.70, por exemplo). Nesse caso, não vi nenhum pacote saindo do meu servidor DNS, mesmo que bogus. não estivesse no cache (o log de depuração já estava em execução e esta é a primeira vez que eu consultei esse servidor por bogus. ou qualquer TLD). Acabou de retornar o SERVFAIL sem consultar nenhum outro servidor DNS, como no artigo da Microsoft KB vinculado acima.
Tivemos problemas semelhantes em servidores DNS da Microsoft sem encaminhadores configurados. Parece que esse hotfix está relacionado: link . Eu não diria que usar forwarders negaria a aplicabilidade.