¿Cómo evitar retrasos asociados con los registros IPv6 AAAA?

Nuestros servidores de Windows están registrando AAAAregistros IPv6 con nuestros servidores DNS de Windows. Sin embargo, no tenemos habilitado el enrutamiento IPv6 en nuestra red, por lo que con frecuencia esto provoca comportamientos de bloqueo.

Microsoft RDP es el peor delincuente. Cuando se conecta a un servidor que tiene un AAAAregistro en DNS, el cliente de escritorio remoto intentará primero con IPv6, y no recurrirá a IPv4 hasta que se agote el tiempo de espera de la conexión. Los usuarios avanzados pueden solucionar esto conectándose directamente a la dirección IP. Resolver la dirección IPv4 con ping -4 hostname.foosiempre funciona al instante.

¿Qué puedo hacer para evitar este retraso?

• ¿Deshabilitar IPv6 en el cliente?
  • No, Microsoft dice que IPv6 es una parte obligatoria del sistema operativo Windows.
  • Demasiados clientes para garantizar que esto se establezca en todas partes de manera consistente.
  • Causará más problemas más adelante cuando finalmente implementemos IPv6.
• ¿Deshabilitar IPv6 en el servidor?
  • No, Microsoft dice que IPv6 es una parte obligatoria del sistema operativo Windows.
  • Requiere un hack de registro inconveniente para deshabilitar toda la pila de IPv6.
  • Asegurar que esto esté configurado correctamente en todos los servidores es inconveniente.
  • Causará más problemas más adelante cuando finalmente implementemos IPv6.
• ¿Enmascarar registros de IPv6 en el recurso de DNS de usuario-facnig?
  • No, estamos usando NLNet Unbound y no es compatible con eso .
• ¿Prevenir el registro de registros AAAA IPv6 en el servidor DNS de Microsoft?
  • No creo que eso sea posible.

En este punto, estoy considerando escribir un script que purgue todos los registros AAAA de nuestras zonas DNS. Por favor, ayúdame a encontrar una mejor manera.

ACTUALIZACIÓN: la resolución DNS no es el problema. Como @joeqwerty señala en su respuesta, los registros DNS se devuelven instantáneamente. Ambos Ay los AAAAregistros están disponibles de inmediato. El problema es que algunos clientes ( mstsc.exe) intentarán preferentemente una conexión a través de IPv6 y tardarán un tiempo en recurrir a IPv4.

Esto parece un problema de enrutamiento. El pingcomando genera un mensaje de error "Error general" porque la dirección de destino no se puede enrutar.

C:\Windows\system32>ping myhost.mydomain
Pinging myhost.mydomain [2002:1234:1234::1234:1234] with 32 bytes of data:
General failure.
General failure.
General failure.
General failure.
Ping statistics for 2002:1234:1234::1234:1234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

No puedo obtener una captura de paquetes de este comportamiento. La ejecución de este comando ping (fallido) no produce ningún paquete en Microsoft Network Monitor. Del mismo modo, intentar una conexión con mstsc.exeun host con un AAAAregistro no produce tráfico hasta que hace una reserva a IPv4.

ACTUALIZACIÓN: Todos nuestros hosts están utilizando direcciones IPv4 enrutables públicamente. Creo que este problema podría deberse a una configuración 6to4 rota. 6to4 se comporta de manera diferente en hosts con direcciones IP públicas frente a direcciones RFC1918.

ACTUALIZACIÓN: Definitivamente hay algo sospechoso con 6to4 en mi red. Cuando desactivo 6to4 en el cliente de Windows, las conexiones se resuelven instantáneamente.

netsh int ipv6 6to4 set state disabled

Pero como dice @joeqwerty, esto solo enmascara el problema. Todavía estoy tratando de descubrir por qué la comunicación IPv6 en nuestra red no funciona por completo.

Esta pregunta es bastante interesante y debo admitir que nunca he visto este comportamiento. Al hacer algunas maniobras para tratar de entenderlo mejor, tomé un fragmento de consulta nslookup para uno de mis servidores W2K8R2 RDS de otro servidor W2K8R2 y también capturé un fragmento de una sesión RDP en el mismo servidor RDS desde el mismo servidor de prueba . Nslookup no mostró demora en devolver el registro IPv6 y nslookup mostró que mi servidor de prueba consultaba el registro IPv4 antes de consultar el registro IPv6. El delta de tiempo en la captura no muestra un retraso apreciable (que pueda determinar) en ninguna de las consultas.

EDITAR

Ahora estás en algo.

Asegúrese de capturar el tráfico para el adaptador Microsoft 6To4, de lo contrario no verá IPv6:

Aquí está el resultado de nslookup para mi servidor RDS. Tome nota de las direcciones IPv6:

Ahora aquí hay un fragmento de mi captura:

Y finalmente, aquí hay un fragmento de netstat que muestra la conexión:

Claramente, como has confirmado, la resolución DNS no es el problema. El problema es que la conexión RDP prefiere IPv6 sobre IPv4 (que es el valor predeterminado para Windows; Windows prefiere IPv6 sobre IPv4) y debido a que IPv6 no funciona correctamente, está causando el retraso (como ha dicho) al retroceder de IPv6 a IPv4. Puede solucionar esto configurando los clientes para que prefieran IPv4 sobre IPv6, pero creo que eso simplemente estaría enmascarando el problema. La mejor solución sería descubrir por qué IPv6 no funciona y solucionarlo. No sé lo suficiente sobre IPv6 para ayudar, pero supongo que los registros de IPv6 que devuelve DNS son direcciones "locales" válidas solo en la subred donde existen los hosts RDS y, dado que los clientes están en una subred diferente, pueden " t llegar a esas direcciones IPv6.

La tecnología de transición IPv6 llamada 6to4 es infame por causar problemas como este. Hay varios factores en el trabajo. Individualmente son inofensivos, pero el efecto combinado es que los usuarios finales pueden experimentar retrasos en la conexión.

A continuación se presenta una lista de factores y reflexiones sobre su mitigación.

Windows habilita 6to4 por defecto

Si sus hosts ejecutan una versión reciente de Windows (Vista o posterior), Windows habilitará de manera oportunista el túnel 6to4 cuando esté disponible una dirección IPv4 enrutable públicamente. Críticamente, esto se aplica tanto a los servidores como a los clientes.

Para averiguar si un sistema está usando 6to4, ejecute ipconfigy busque una dirección IPv6 que comience con el prefijo 6to4 2002:. Se vería algo así.

C:\> ipconfig
Tunnel adapter 6TO4 Adapter:
IPv6 Address. . . . . . . . . . . : 2002:1111:2222::1111:2222

• Si sus puntos finales están conectados a Active Directory, puede usar la Política de grupo para deshabilitar protocolos de transición como 6to4 y Teredo. Esto está bien documentado en KB929852 . (Aplicar esto a sus clientes o servidores sería suficiente, pero si está dando este paso, probablemente tenga sentido deshabilitarlo en todas partes, tanto en clientes como en servidores).
• Si solo administra unos pocos hosts, puede deshabilitar 6to4 caso por caso. Esto es mucho mejor que deshabilitar IPv6 por completo.netsh int ipv6 6to4 set state disabled
• Use un sistema operativo de cliente diferente. Por ejemplo, Mac OS X no tiene habilitado 6to4 de manera predeterminada.

Se están utilizando direcciones IPv4 enrutables públicamente

6to4 solo funciona en hosts que tienen direcciones IPv4 enrutables públicamente, por lo que este problema nunca afecta a los hosts detrás de un firewall NAT.

• Puede mover clientes y / o servidores detrás de un firewall NAT y comenzar a usar el direccionamiento RFC1918. Pero en algunos casos, se prefieren las direcciones enrutables públicamente. Cambiar el direccionamiento de una red completa también podría ser una opción poco realista.

6to4 no funciona correctamente en la red

Es infamemente difícil solucionar problemas de 6to4 en cualquier modo de difusión. Es tan problemático que hubo una solicitud formal al IETF de que 6to4 debería ser reclasificado como histórico . En opinión de este autor, 6to4 ha quedado en desuso.

En resumen, 6to4 funciona encapsulando paquetes IPv6 en paquetes IPv4 utilizando un protocolo llamado 6in4 (protocolo IP = 41). Los paquetes IPv4 se dirigen a cualquier dirección de difusión 192.88.99.1con la esperanza de que llegue a un relé 6to4 que funcione en algún lugar de Internet. Incluso podría estar geográficamente cerca, si tienes suerte.

En la práctica, algunos relés 6to4 están configurados incorrectamente, y muchas redes ni siquiera permiten que el tráfico 6in4 cruce el firewall. Por lo general, esto sucede cuando un firewall permite todo el tráfico saliente, pero no permite explícitamente que los paquetes del protocolo IP 41 regresen a través del firewall. (TODO tenga en cuenta el RFC relevante para la resolución de problemas). Esta falla ("agujero negro entrante") y muchos otros se describen en RFC 6343 .

• Configure su firewall para rechazar en voz alta el protocolo IP 41 (con restablecimientos de TCP) cuando lo envíe desde hosts internos a su red. Esto debería dar como resultado un comportamiento de "falla rápida" que tiene más sentido que los retrasos de conexión no deterministas. Se ha demostrado que esto funciona en entornos de prueba limitados .
• Pídale a su ISP o proveedor de tránsito de primer salto que configure un relé 6to4 que funcione. Si se hace bien, dará como resultado la mejor experiencia para los usuarios finales. Cualquier usuario final con una dirección IPv4 enrutable públicamente podría participar en Internet IPv6.

Registro dinámico de DNS

En un entorno típico de Active Directory, cada computadora puede registrar sus propias direcciones con el servidor DNS. Cuando un host es multihomed, registrará todas sus direcciones, incluso desde un túnel 6to4.

La mayoría de los servicios de Internet no usan DNS dinámico, por lo que este problema generalmente está restringido a sitios empresariales donde los clientes y servidores son todos "internos" en la misma red.

• Puede optar por deshabilitar las actualizaciones dinámicas de DNS. Luego, si no coloca ningún registro de recursos AAAA en el archivo de zona, nunca se publicarán. Sin embargo, el DNS dinámico a menudo es deseable para los servidores DNS internos. (Si hace esto, asegúrese de eliminar también cualquier registro AAAA que pueda estar presente).
• Configure el servidor DNS para que no proporcione respuestas para los registros de recursos AAAA. Pero no haga esto, porque realmente le dará problemas cuando desee comenzar a implementar IPv6. (¿Alguien sabe de un firewall DNS gratuito / de código abierto?)

La aplicación cliente no falla correctamente

El cliente RDP de Microsoft es un ejemplo de una aplicación cliente que no trata con gracia los problemas de enrutamiento IPv6. La mayoría de los navegadores web son mejores para tratar casos extremos de IPv6 como este, por lo que no tienden a mostrar este comportamiento.

• Intenta usar un cliente diferente. Quizás tengas suerte.

Me doy cuenta de que no es muy útil para esta situación, pero para los implementadores que enfrentan un dilema similar, existe una técnica de implementación conocida como "Happy Eyeballs" (RFC 6555) que especifica una técnica para conectarse a ipv4 e ipv6 simultáneamente y elegir el que se conecte primero.

Aquí estaba mi solución. De manera predeterminada, Windows otorga a las rutas IPv6 una prioridad más alta que las rutas IPv4. Si edita la política de prefijo de IPv6, puede cambiar este comportamiento para que use IPv4 con preferencia a IPv6.

Para asegurarme de que todos los sistemas de mi red estén configurados de la misma manera, puse los siguientes comandos en un script .bat que se ejecuta durante la instalación del software después de construir o restaurar una máquina.

netsh int ipv6 isatap set state disabled
netsh int ipv6 6to4 set state disabled
netsh interface teredo set state disable

netsh interface ipv6 delete prefixpolicy ::1/128
netsh interface ipv6 delete prefixpolicy ::/0
netsh interface ipv6 delete prefixpolicy 2002::/16
netsh interface ipv6 delete prefixpolicy ::/96
netsh interface ipv6 delete prefixpolicy ::ffff:0:0/96
netsh interface ipv6 delete prefixpolicy 2001::/32

netsh interface ipv6 add prefixpolicy ::1/128 50 0
netsh interface ipv6 add prefixpolicy ::ffff:0:0/96 40 1
netsh interface ipv6 add prefixpolicy ::/0 30 2
netsh interface ipv6 add prefixpolicy 2002::/16 20 3
netsh interface ipv6 add prefixpolicy ::/96 10 4
netsh interface ipv6 add prefixpolicy 2001::/32 5 5

Para explicar lo que esto hace:

Las primeras 3 líneas deshabilitan las interfaces de túnel integradas, ya que son redundantes para la mayoría de las redes. Es posible que no desee utilizar esas 3 líneas si no le está dando a sus máquinas direcciones IPv6 propias, en mi caso tengo un servidor DHCPv6 y la infraestructura asociada que asigna IPv6 para conectividad en túnel

El segundo bloque de comandos elimina todas las políticas de prefijos de enrutamiento IPv6 existentes.

Luego, el tercer bloque recrea las políticas de prefijo IPv6, pero usa un conjunto diferente de prioridades. De esta manera, el prefijo correspondiente a IPv4 tiene preferencia sobre IPv6, y la máquina querrá usar IPv4 a menos que la aplicación especifique el uso de IPv6.

Esta solución conserva la capacidad funcional de doble pila, pero la preferencia de usar IPv4 significa que los sitios con IPv6 incompleto, poco confiable o de bajo rendimiento evitarán usarlo a menos que un programa del sistema se lo indique.

Es mi opinión que hacer que los sistemas operativos usen IPv6 en lugar de IPv4 en realidad está obstaculizando la adopción. Durante el período de transición, habrá momentos en que un host piense que tiene conectividad IPv6, pero en realidad no tiene una conexión totalmente funcional, lo que ocasiona un mal funcionamiento del software y grandes retrasos. Muchas personas que conozco han deshabilitado IPv6 por completo en su enrutador como una solución alternativa para los ISP que implementan IPv6 de manera interrumpida inicialmente antes de establecer una conectividad completa, y estas personas simplemente olvidarán habilitarlo nuevamente dejándolos sin IPv6 hasta que vuelvan a configurar su enrutador.