Eu tenho um controlador de domínio do Windows 2008 R2, que também é um servidor DNS. Ao resolver certos 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 esteja funcionando conforme o 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, ao consultar meu servidor DNS do Windows dig . any, recebo um SERVFAIL, mas os servidores BIND retornam a zona raiz conforme o esperado.
Isso parece semelhante ao problema descrito em http://support.microsoft.com/kb/968372, exceto que eu estou usando dois encaminhadores (128.59.59.70 de cima e 128.59.62.10) e voltando às dicas de raiz, portanto, as pré-condições para expor o problema não são os mesmos. No entanto, também apliquei a MaxCacheTTLcorreção do registro conforme descrito e reiniciei o DNS e todo o servidor, mas o problema persiste. O problema ocorre em todos os controladores de domínio desse domínio e ocorre desde meio ano atrás, mesmo que os servidores estejam recebendo 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 log de depuração foram marcadas, exceto "filtrar por IP". Por outro lado, quando consulta, digamos, accounts.google.com, posso ver o servidor DNS indo para o encaminhador (128.59.59.70, por exemplo). Nesse caso, não vi pacotes saindo do meu servidor DNS, embora bogus.não estivesse no cache (o log de depuração já estava em execução e é a primeira vez que consultei esse servidor bogus.ou qualquer TLD). Ele acabou de retornar o SERVFAIL sem consultar nenhum outro servidor DNS, como no artigo da Microsoft KB vinculado acima.
fonte
Respostas:
Tivemos um problema semelhante nos servidores DNS da Microsoft sem encaminhadores configurados. Parece que esse hotfix está relacionado: http://support.microsoft.com/kb/2508835 . Eu não diria que o uso de encaminhadores negaria a aplicabilidade.
fonte