Tengo un controlador de dominio de Windows 2008 R2 que también es un servidor DNS. Al resolver ciertos TLD, devuelve un 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
Obtengo el mismo resultado para un TLD real como com.cuando consulto el DC como se muestra arriba. Compare con un servidor BIND que funciona como se esperaba:
$ 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
De manera similar, cuando dig . anyconsulto mi servidor DNS de Windows con , recibo un SERVFAIL pero los servidores BIND devuelven la zona raíz como se esperaba.
Esto suena similar al problema descrito en http://support.microsoft.com/kb/968372, excepto que estoy usando dos reenviadores (128.59.59.70 desde arriba, así como 128.59.62.10) y volviendo a las indicaciones de raíz, por lo que las condiciones previas para Exponer el problema no son lo mismo. Sin embargo, también apliqué la MaxCacheTTLcorrección del registro como se describe y reinicié DNS y todo el servidor, pero el problema persiste. El problema se produce en todos los controladores de dominio en este dominio y se ha producido desde hace medio año, a pesar de que los servidores reciben actualizaciones automáticas de Windows.
EDITAR
Aquí hay un registro de depuración. El cliente es 160.39.114.110, que es mi estación de trabajo.
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 las opciones en el cuadro de registro de depuración fueron marcadas excepto "filtrar por IP". Por el contrario, cuando consulto, por ejemplo, accounts.google.com, puedo ver que el servidor DNS sale a su reenviador (128.59.59.70, por ejemplo). En este caso, no vi salir ningún paquete de mi servidor DNS a pesar de que bogus.no estaba en el caché (el registro de depuración ya se estaba ejecutando y esta es la primera vez que consulté este servidor bogus.o cualquier TLD). Acaba de devolver SERVFAIL sin consultar a ningún otro servidor DNS, como en el artículo de Microsoft KB vinculado anteriormente.
fuente
Respuestas:
Hemos tenido un problema similar en los servidores DNS de Microsoft sin reenviadores configurados. Parece que esta revisión está relacionada: http://support.microsoft.com/kb/2508835 . No diría que el uso de reenviadores negaría la aplicabilidad.
fuente