El servidor DNS 2012R2 del servidor devuelve SERVFAIL para algunas consultas AAAA

17

(Reescribiendo la mayor parte de esta pregunta ya que muchas de mis pruebas originales son irrelevantes a la luz de 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 por registros AAAA antes de intentar registros A. Cuando ve SERVFAIL para el registro AAAA, ni siquiera prueba los registros A, simplemente se da por vencido.

Para algunos dominios, cuando realizo consultas en mis servidores DNS del directorio activo, obtengo SERVFAIL en lugar de NOERROR sin resultados.

He intentado esto desde varios controladores de dominio Server 2012R2 diferentes que ejecutan DNS. Uno de ellos es un dominio completamente separado, en una red diferente detrás de un firewall y conexión a Internet diferentes.

Dos direcciones que sé que causan este problema son smtpgw1.gov.on.caymxmta.owm.bell.net

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, he intentado 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 algunas configuraciones antiguas de 2003/2008 pueden haberse transferido. Obtengo los mismos resultados en ambos.

Deshabilitar EDNS con lo dmscnd /config /enableednsprobes 0arregla. Veo muchos resultados de búsqueda acerca de que EDNS es un problema en el Servidor 2003, pero no mucho que coincida con lo que estoy viendo en el Servidor 2012. Ninguno de los cortafuegos tiene un problema con el EDNS. Sin embargo, deshabilitar EDNS debería ser solo una solución temporal: evita el uso de DNSSEC y puede 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 arregladas en Server 2012, por lo que debería funcionar correctamente.

También he intentado habilitar el registro de depuración para DNS. Puedo ver los paquetes que esperaba, pero no me da mucha idea de por qué está devolviendo 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 AM 0974 PAQUETE 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) en (2) ca (0)
Información de la pregunta UDP en 000000EFF1BF01A0
  Zócalo = 508
  Dirección remota 172.16.0.254, puerto 50764
  Consulta de tiempo = 4556080, En cola = 0, Caducar = 0
  Longitud de buf = 0x0fa0 (4000)
  Longitud de mensaje = 0x002e (46)
  Mensaje:
    XID 0xa61e
    Banderas 0x0120
      QR 0 (PREGUNTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 1
      RA 0
      Z 0
      CD 0
      AD 1
      CÓDIGO 0 (NOERROR)
    QCOUNT 1
    CUENTA 0
    NSCOUNT 0
    CUENTA 1
    PREGUNTA SECCIÓN:
    Desplazamiento = 0x000c, recuento RR = 0
    Nombre "(7) smtpgw1 (3) gov (2) en (2) ca (0)"
      CANT. AAAA (28)
      QCLASS 1
    SECCION DE RESPUESTA:
      vacío
    SECCIÓN DE AUTORIDAD
      vacío
    SECCION ADICIONAL
    Desplazamiento = 0x0023, recuento RR = 0
    Nombre "(0)"
      TIPO OPT (41)
      CLASE 4096
      TTL 0
      DLEN 0
      DATOS   
        Tamaño del buffer = 4096
        Rcode Ext = 0
        Rcode Full = 0
        Versión = 0
        Banderas = 0

Segundo paquete: consulta desde mi servidor DNS a su servidor DNS

10/16/2015 9:42:29 AM 0974 PACKET 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) en (2) ca (0)
Información de la pregunta UDP en 000000EFF0A22160
  Zócalo = 9812
  Dirección remota 204.41.8.237, puerto 53
  Consulta de tiempo = 0, en cola = 0, caducar = 0
  Longitud de buf = 0x0fa0 (4000)
  Longitud de mensaje = 0x0023 (35)
  Mensaje:
    XID 0x3e6c
    Banderas 0x0000
      QR 0 (PREGUNTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      CÓDIGO 0 (NOERROR)
    QCOUNT 1
    CUENTA 0
    NSCOUNT 0
    CUENTA 0
    PREGUNTA SECCIÓN:
    Desplazamiento = 0x000c, recuento RR = 0
    Nombre "(7) smtpgw1 (3) gov (2) en (2) ca (0)"
      CANT. AAAA (28)
      QCLASS 1
    SECCION DE RESPUESTA:
      vacío
    SECCIÓN DE AUTORIDAD
      vacío
    SECCION ADICIONAL
      vacío

Tercer paquete: respuesta de su servidor DNS (NOERROR)

16/10/2015 9:42:29 AM 0974 PAQUETE 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) en (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, Caducar = 0
  Longitud de buf = 0x0fa0 (4000)
  Longitud de mensaje = 0x0023 (35)
  Mensaje:
    XID 0x3e6c
    Banderas 0x8400
      QR 1 (RESPUESTA)
      OPCODE 0 (CONSULTA)
      AA 1
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      CÓDIGO 0 (NOERROR)
    QCOUNT 1
    CUENTA 0
    NSCOUNT 0
    CUENTA 0
    PREGUNTA SECCIÓN:
    Desplazamiento = 0x000c, recuento RR = 0
    Nombre "(7) smtpgw1 (3) gov (2) en (2) ca (0)"
      CANT. AAAA (28)
      QCLASS 1
    SECCION DE RESPUESTA:
      vacío
    SECCIÓN DE AUTORIDAD
      vacío
    SECCION ADICIONAL
      vacío

Cuarto paquete: respuesta de mi servidor DNS al cliente (SERVFAIL)

10/16/2015 9:42:29 AM 0974 PACKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) en (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, Caducar = 4556083
  Longitud de buf = 0x0fa0 (4000)
  Longitud de mensaje = 0x002e (46)
  Mensaje:
    XID 0xa61e
    Banderas 0x8182
      QR 1 (RESPUESTA)
      OPCODE 0 (CONSULTA)
      AA 0
      TC 0
      RD 1
      RA 1
      Z 0
      CD 0
      AD 0
      RCODE 2 (SERVFAIL)
    QCOUNT 1
    CUENTA 0
    NSCOUNT 0
    CUENTA 1
    PREGUNTA SECCIÓN:
    Desplazamiento = 0x000c, recuento RR = 0
    Nombre "(7) smtpgw1 (3) gov (2) en (2) ca (0)"
      CANT. AAAA (28)
      QCLASS 1
    SECCION DE RESPUESTA:
      vacío
    SECCIÓN DE AUTORIDAD
      vacío
    SECCION ADICIONAL
    Desplazamiento = 0x0023, recuento RR = 0
    Nombre "(0)"
      TIPO OPT (41)
      CLASE 4000
      TTL 0
      DLEN 0
      DATOS   
        Tamaño del buffer = 4000
        Rcode Ext = 0
        Rcode Full = 2
        Versión = 0
        Banderas = 0

Otras cosas de nota:

  • Una de las redes tiene acceso nativo a Internet IPv6, 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 para google.comdevuelve las direcciones IPv6 de Google correctamente.
  • Intenté instalar el hotfix de KB3014171 , no hizo ninguna diferencia.
  • La actualización de KB3004539 ya está instalada.

Editar Nov 7, 2015

Configuré otra máquina Server 2012R2 que no se unió al dominio, instalé la función del servidor DNS y 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, por lo que elimina cualquier problema de red / firewall. Ahora está en el nivel de parche o en ser un miembro de dominio / controlador de dominio que marca la diferencia.

Editar nov 8, 2015

Aplica todas las actualizaciones, no hizo ninguna diferencia. Fui a verificar dos veces si había alguna diferencia de configuración entre mi nuevo servidor de prueba y la configuración de DNS de mi controlador de dominio, y existen: el controlador de dominio tenía configurados los reenviadores.

Ahora, estoy seguro de que lo intenté con reenviadores y sin ellos 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 (probado con Google, OpenDNS, 4.2.2.1 y mis servidores DNS ISP) cuando uso nslookup en una máquina Windows.

Con un conjunto de promotores, lo entiendo Server failed.

Sin un reenviador (por lo que usa servidores DNS raíz), obtengo No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Pero eso no es lo mismo que obtengo para otros dominios que no tienen registros IPv6: nslookup en Windows simplemente no devuelve resultados para otros dominios.

Con o sin reenviadores, digaún se muestra SERVFAILese nombre cuando se consulta mi servidor DNS de Windows.

Hay una pequeña diferencia entre el dominio del problema y otros que parecen relevantes, incluso cuando no involucro a mi servidor DNS de Windows:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca no 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 hago con la mayoría de los otros dominios que pruebo, sin importar qué resolución uso.

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?

domain-name-system active-directory mx-record Conceder
fuente
¿Estás realizando estas pruebas desde el servidor de Exchange? Si no, sugeriría hacerlo para que pueda verlo desde la perspectiva de Exchange. Es posible que también desee intentar ejecutar SMTPDiag desde el servidor de Exchange. Sugeriría ejecutarlo mientras realiza una captura de red en el servidor de Exchange para que pueda ver los detalles de la actividad de red / DNS. SMTPDiag es una herramienta antigua, pero es una herramienta de línea de comandos que no requiere instalación, por lo que creo que debería funcionar en todas las versiones de Exchange. - microsoft.com/en-us/download/details.aspx?id=11393
joeqwerty
Algunos dispositivos de red no reconocen y rechazarán los paquetes EDNS. ¿Su equipo de red introdujo un nuevo dispositivo / configuración recientemente? Para eliminar esta posibilidad, intente resolver el registro AAAA de google.com, debe devolver una dirección IPv6.
fuerte
Los paquetes de @strongline EDNS salen bien. Registro AAAA para Google Works, al igual que otros sitios que conozco tienen IPv6 ejecutándose. La única oportunidad que tuvimos recientemente fue deshacernos de nuestro último servidor DC / DNS Server 2008R2 y reemplazarlo con 2012R2.
Grant
¿IPv6 está deshabilitado de alguna manera en su entorno?
Jim B
@JimB no está realmente habilitado ni deshabilitado ... La pila IPv6 se está ejecutando en los servidores, porque está activada de forma predeterminada, con cualquier configuración predeterminada que tenga. La puerta de enlace y la conexión a Internet no tienen IPv6 en absoluto.
Grant

Respuestas:

3

He examinado la red un poco más y he leído un poco. La solicitud del registro AAAA, cuando no existe, devuelve un SOA. Resulta que SOA es para un dominio diferente al solicitado. Sospecho que por eso Windows está rechazando la respuesta. Solicite AAAA para mx.atomwide.com. Respuesta SOA para lgfl.org.uk. Veré si podemos avanzar con esta información. EDITAR: Solo para referencia futura, desactivar temporalmente "Caché segura contra la contaminación" permitirá que la consulta tenga éxito. No es ideal, pero demuestra que el problema es con un registro DNS poco fiable. RFC4074 también es una buena referencia: introducción y sección.

Shruti Chawla
fuente
Voy a tratar de probar esto hoy en mi entorno, ¡pero creo que puedes estar en algo!
Grant
También he editado su enlace: las firmas y los enlaces fuera de tema no están permitidos aquí, y no quiero ver que se elimine su excelente respuesta.
Grant
0

De acuerdo con KB832223

Porque

Este problema se produce debido a la funcionalidad de Mecanismos de extensión para DNS (EDNS0) que es compatible con DNS de Windows Server.

EDNS0 permite tamaños de paquetes de Protocolo de datagramas de usuario (UDP) más grandes. Sin embargo, algunos programas de firewall pueden no permitir paquetes UDP que tengan más de 512 bytes. Por lo tanto, el firewall puede bloquear estos paquetes DNS.

Microsoft tiene la siguiente resolución:

Resolución

Para resolver este problema, actualice el programa de firewall para reconocer y permitir paquetes UDP que tengan 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 los servidores DNS basados ​​en Windows. Para hacer esto, tome la siguiente acción:

En el símbolo del sistema, escriba el siguiente comando y luego presione Entrar:

dnscmd /config /enableednsprobes 0

Nota Escriba un 0 (cero) y no la letra "O" después de "enableednsprobes" en este comando.

Tim Penner
fuente
He visto este artículo: los cortafuegos que he probado con ambos pasan grandes dns packetd sin problemas, como lo demuestra el funcionamiento perfecto en Linux. Deshabilitar edns evita el uso de DNSSEC, por lo que, aunque soluciona el problema, no es una buena solución.
Grant
lo siento, no me di cuenta de que la guía de Microsoft también se aplicaría a Linux. Por curiosidad, ¿tiene algún sistema operativo de Microsoft que funcione a través del firewall?
Tim Penner