(Reescribiendo la mayor parte de esta pregunta ya que muchas de mis pruebas originales son irrelevantes a la luz de la nueva información)
Tengo problemas con los servidores DNS Server 2012R2. El mayor efecto secundario de estos problemas es que los correos electrónicos de Exchange no se envían. Intercambie consultas para registros AAAA antes de probar registros A. Cuando ve SERVFAIL para el registro AAAA, ni siquiera intenta los registros A, simplemente se da por vencido.
Para algunos dominios, cuando consulto los servidores DNS de mi directorio activo, obtengo SERVFAIL en lugar de NOERROR sin resultados.
Probé esto desde varios controladores de dominio de Server 2012R2 diferentes que ejecutan DNS. Uno de ellos es un dominio completamente separado, en una red diferente detrás de un firewall y una conexión a Internet diferentes.
Dos direcciones que sé que causan este problema son smtpgw1.gov.on.caymxmta.owm.bell.net
Lo he estado usando digen una máquina Linux para probar esto (192.168.5.5 es mi controlador de dominio):
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
Pero las consultas contra un controlador de dominio público funcionan como se esperaba:
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 dije, probé esto en dos redes y dominios diferentes. Uno es un dominio nuevo, que definitivamente tiene todas las configuraciones predeterminadas para DNS. El otro se ha migrado a Server 2012, por lo que es posible que se hayan transferido algunas configuraciones antiguas de 2003/2008. Obtengo los mismos resultados en ambos.
Deshabilitar EDNS dmscnd /config /enableednsprobes 0lo soluciona. Veo muchos resultados de búsqueda acerca de que EDNS es un problema en Server 2003, pero no hay muchos que coincidan con lo que veo en Server 2012. Ninguno de los firewalls tiene problemas con EDNS. Sin embargo, deshabilitar EDNS debería ser solo una solución temporal: impide el uso de DNSSEC y podría causar otros problemas.
También he visto algunas publicaciones sobre problemas con Server 2008R2 y EDNS, pero esas mismas publicaciones dicen que las cosas están solucionadas en Server 2012, por lo que debería funcionar correctamente.
También intenté habilitar el registro de depuración para DNS. Puedo ver los paquetes que esperaba, pero no me da mucha idea de por qué devuelve SERVFAIL. Aquí están las partes relevantes del registro de depuración del servidor DNS:
Primer paquete: consulta del cliente a mi servidor DNS
16/10/2015 9:42:29 a.m. 0974 PAQUETE 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
Información de preguntas UDP en 000000EFF1BF01A0
Zócalo = 508
Dirección remota 172.16.0.254, puerto 50764
Consulta de tiempo=4556080, en cola=0, caducidad=0
Longitud del buf = 0x0fa0 (4000)
Longitud del mensaje = 0x002e (46)
Mensaje:
XID 0xa61e
Banderas 0x0120
QR 0 (PREGUNTA)
CÓDIGO OP 0 (CONSULTA)
AA 0
CT 0
RD 1
AR 0
Z 0
CD 0
1 d.C.
RCODIGO 0 (NOERROR)
QCUENTA 1
CUENTA 0
NSCUENTA 0
CUENTA 1
SECCIÓN DE PREGUNTAS:
Desplazamiento = 0x000c, recuento RR = 0
Nombre "(7)smtpgw1(3)gov(2)on(2)ca(0)"
TIPO AAAA (28)
Q CLASE 1
SECCIÓN DE RESPUESTAS:
vacío
SECCIÓN DE AUTORIDAD:
vacío
SECCIÓN ADICIONAL:
Compensación = 0x0023, recuento RR = 0
Nombre "(0)"
TIPO OPCIÓN (41)
CLASE 4096
TTL 0
DLEN 0
DATOS
Tamaño del búfer = 4096
Ext. código R = 0
Código R completo = 0
Versión = 0
Banderas = 0
Segundo paquete: consulta desde mi servidor DNS a su servidor DNS
16/10/2015 9:42:29 a.m. 0974 PAQUETE 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
Información de preguntas UDP en 000000EFF0A22160
Zócalo = 9812
Dirección remota 204.41.8.237, puerto 53
Consulta de tiempo=0, en cola=0, caducidad=0
Longitud del buf = 0x0fa0 (4000)
Longitud del mensaje = 0x0023 (35)
Mensaje:
XID 0x3e6c
Banderas 0x0000
QR 0 (PREGUNTA)
CÓDIGO OP 0 (CONSULTA)
AA 0
CT 0
RD 0
AR 0
Z 0
CD 0
anuncio 0
RCODIGO 0 (NOERROR)
QCUENTA 1
CUENTA 0
NSCUENTA 0
CUENTA 0
SECCIÓN DE PREGUNTAS:
Desplazamiento = 0x000c, recuento RR = 0
Nombre "(7)smtpgw1(3)gov(2)on(2)ca(0)"
TIPO AAAA (28)
Q CLASE 1
SECCIÓN DE RESPUESTAS:
vacío
SECCIÓN DE AUTORIDAD:
vacío
SECCIÓN ADICIONAL:
vacío
Tercer paquete: respuesta de su servidor DNS (NOERROR)
16/10/2015 9:42:29 a.m. 0974 PAQUETE 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
Información de respuesta UDP en 000000EFF2188100
Zócalo = 9812
Dirección remota 204.41.8.237, puerto 53
Consulta de tiempo=4556080, en cola=0, caducidad=0
Longitud del buf = 0x0fa0 (4000)
Longitud del mensaje = 0x0023 (35)
Mensaje:
XID 0x3e6c
Banderas 0x8400
QR 1 (RESPUESTA)
CÓDIGO OP 0 (CONSULTA)
AA 1
CT 0
RD 0
AR 0
Z 0
CD 0
anuncio 0
RCODIGO 0 (NOERROR)
QCUENTA 1
CUENTA 0
NSCUENTA 0
CUENTA 0
SECCIÓN DE PREGUNTAS:
Desplazamiento = 0x000c, recuento RR = 0
Nombre "(7)smtpgw1(3)gov(2)on(2)ca(0)"
TIPO AAAA (28)
Q CLASE 1
SECCIÓN DE RESPUESTAS:
vacío
SECCIÓN DE AUTORIDAD:
vacío
SECCIÓN ADICIONAL:
vacío
Cuarto paquete: respuesta de mi servidor DNS al cliente (SERVFAIL)
16/10/2015 9:42:29 a.m. 0974 PAQUETE 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
Información de respuesta UDP en 000000EFF1BF01A0
Zócalo = 508
Dirección remota 172.16.0.254, puerto 50764
Consulta de tiempo=4556080, en cola=4556080, caducidad=4556083
Longitud del buf = 0x0fa0 (4000)
Longitud del mensaje = 0x002e (46)
Mensaje:
XID 0xa61e
Banderas 0x8182
QR 1 (RESPUESTA)
CÓDIGO OP 0 (CONSULTA)
AA 0
CT 0
RD 1
RA 1
Z 0
CD 0
anuncio 0
RCODIGO 2 (SERVFAIL)
QCUENTA 1
CUENTA 0
NSCUENTA 0
CUENTA 1
SECCIÓN DE PREGUNTAS:
Desplazamiento = 0x000c, recuento RR = 0
Nombre "(7)smtpgw1(3)gov(2)on(2)ca(0)"
TIPO AAAA (28)
Q CLASE 1
SECCIÓN DE RESPUESTAS:
vacío
SECCIÓN DE AUTORIDAD:
vacío
SECCIÓN ADICIONAL:
Compensación = 0x0023, recuento RR = 0
Nombre "(0)"
TIPO OPCIÓN (41)
CLASE 4000
TTL 0
DLEN 0
DATOS
Tamaño del búfer = 4000
Ext. código R = 0
Código R completo = 2
Versión = 0
Banderas = 0
Otras cosas a tener en cuenta:
- Una de las redes tiene acceso a Internet IPv6 nativo, la otra no (pero la pila IPv6 está habilitada en los servidores con la configuración predeterminada). No parece ser un problema de red IPv6
- No afecta a todos los dominios. Por ejemplo,
dig @192.168.5.5 -t AAAA serverfault.comdevuelve NOERROR y no hay resultados. Lo mismo ocurre congoogle.comlas devoluciones correctas de las direcciones IPv6 de Google. - Intenté instalar la revisión desdeKB3014171, no hizo ninguna diferencia.
- La actualización deKB3004539ya está instalado.
Editar 7 de noviembre de 2015
Configuré otra máquina Server 2012R2 que no está unida a un dominio, instalé la función de servidor DNS y la probé con el comando nslookup -type=aaaa smtpgw1.gov.on.ca localhost. NO tiene los mismos problemas.
Ambas máquinas virtuales están en el mismo host y en la misma red, lo que elimina cualquier problema de red/firewall. Ahora depende del nivel de parche o de ser miembro o controlador de dominio lo que marca la diferencia.
Editar 8 de noviembre de 2015
Apliqué todas las actualizaciones, no hizo ninguna diferencia. Fui a verificar si había alguna diferencia de configuración entre mi nuevo servidor de prueba y la configuración DNS de mi controlador de dominio, y las hay: el controlador de dominio tenía configurados los reenviadores.
Ahora, estoy seguro de que lo intenté con y sin reenviadores en mis pruebas iniciales, pero solo lo intenté usando digdesde una máquina Linux. Obtengo resultados ligeramente diferentes con y sin configuración de reenviadores (probé con Google, OpenDNS, 4.2.2.1 y los servidores DNS de mi ISP) cuando uso nslookup en una máquina con Windows.
Con un reenviador configurado, obtengo Server failed.
Sin un reenviador (por lo que utiliza servidores DNS raíz), obtengo No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.
Pero eso todavía no es lo mismo que obtengo para otros dominios que no tienen registros IPv6: nslookup en Windows simplemente no arroja resultados para otros dominios.
Con o sin reenviadores, digtodavía se muestra SERVFAILese nombre al consultar mi servidor DNS de Windows.
Hay una pequeña diferencia entre el dominio problemático y otros que parece relevante, incluso cuando no involucro mi servidor DNS de Windows:
dig -t aaaa @8.8.8.8 smtpgw1.gov.on.cano tiene respuestas y no tiene una sección de autoridad.
dig -t aaaa @8.8.8.8 serverfault.comno devuelve respuestas, pero tiene una sección de autoridad. Lo mismo ocurre con la mayoría de los otros dominios que pruebo, sin importar qué solucionador utilice.
Entonces, ¿por qué falta esa sección de autoridad y por qué el servidor DNS de Windows la trata como una falla cuando otros servidores DNS no lo hacen?
Respuesta1
Investigué un poco más la red tace y leí un poco. La solicitud del registro AAAA, cuando no existe, devuelve un SOA. Resulta que la SOA es para un dominio diferente al que se solicita. Sospecho que es por eso que Windows rechaza la respuesta. Solicite AAAA para mx.atomwide.com. Respuesta SOA para lgfl.org.uk. Veré si podemos avanzar algo con esta información. EDITAR: Solo para referencia futura, desactivar temporalmente "Caché seguro contra la contaminación" permitirá que la consulta se realice correctamente. No es ideal, pero demuestra que el problema está en un registro DNS poco fiable. RFC4074 también es una buena referencia: Introducción y Sección.
Respuesta2
De acuerdo aKB832223
Causa
Este problema se produce debido a la funcionalidad Mecanismos de extensión para DNS (EDNS0) compatible con Windows Server DNS.
EDNS0 permite tamaños de paquetes de Protocolo de datagramas de usuario (UDP) más grandes. Sin embargo, es posible que algunos programas de firewall no permitan paquetes UDP de más de 512 bytes. Por lo tanto, estos paquetes DNS pueden estar bloqueados por el firewall.
Microsoft tiene la siguiente resolución:
Resolución
Para resolver este problema, actualice el programa de firewall para reconocer y permitir paquetes UDP de más de 512 bytes. Para obtener más información sobre cómo hacer esto, comuníquese con el fabricante de su programa de firewall.
Microsoft tiene la siguiente sugerencia para solucionar el problema:
Solución alterna
Para solucionar este problema, desactive la función EDNS0 en servidores DNS basados en Windows. Para hacer esto, realice la siguiente acción:
En el símbolo del sistema, escriba el siguiente comando y luego presione Entrar:
dnscmd /config /enableednsprobes 0Nota Escriba un 0 (cero) y no la letra "O" después de "enableednsprobes" en este comando.