DNS IPv6: Registros AAAA, resolución dual-stack y mejores prácticas

DNS es donde el despliegue de IPv6 vive o muere. Publica un registro AAAA antes de que tu conectividad IPv6 funcione, y los usuarios esperan a través de timeouts. Omite el DNS inverso, y los servidores de correo rechazan tu tráfico. Configura mal la resolución dual-stack, y haces la red más lenta en lugar de más rápida.

Esta guía cubre cómo funciona DNS con IPv6, qué se rompe y cómo arreglarlo antes de que se convierta en un problema.

Registros AAAA: la respuesta de IPv6 a los registros A#

Un registro AAAA (pronunciado "quad-A") mapea un hostname a una dirección IPv6. Es el equivalente IPv6 de un registro A, pero contiene una dirección de 128 bits en lugar de 32 bits.

Formato y estructura#

example.com.    3600    IN    AAAA    2001:db8::1

La estructura coincide con los registros A: nombre, TTL, clase, tipo y dirección. La dirección usa notación IPv6 estándar con dos puntos y dígitos hexadecimales.

Los ceros iniciales en cada grupo pueden omitirse, y los grupos de ceros consecutivos colapsan a ::. Ambos son válidos e idénticos:

example.com.    IN    AAAA    2001:0db8:0000:0000:0000:0000:0000:0001
example.com.    IN    AAAA    2001:db8::1

Usa el formato comprimido. Es más fácil de leer y menos propenso a errores al escribir.

Consultar registros AAAA#

Consulta registros AAAA de la misma manera que consultas registros A, solo especifica el tipo.

Usando dig:

dig AAAA example.com
dig AAAA @2001:4860:4860::8888 example.com

Usando nslookup:

nslookup -type=AAAA example.com
nslookup -type=AAAA example.com 2001:4860:4860::8888

Usando host:

host -t AAAA example.com

También puedes usar nuestra herramienta de búsqueda DNS para consultar registros A y AAAA simultáneamente y comparar resultados.

Registros AAAA vs A#

Ambos sirven el mismo propósito — traducir nombres a direcciones — pero difieren en aspectos clave:

Los registros A y AAAA son completamente independientes. Pueden tener diferentes TTLs, apuntar a diferentes servidores o existir sin el otro. Esta flexibilidad es útil pero crea oportunidades de mala configuración.

Resolución DNS dual-stack#

La mayoría de las redes funcionan en dual-stack: tanto IPv4 como IPv6 funcionan simultáneamente. Cuando un cliente busca un hostname, recibe registros A y AAAA. El sistema operativo luego decide cuál usar.

Happy Eyeballs (RFC 8305)#

Los sistemas operativos modernos implementan Happy Eyeballs, un algoritmo que intenta tanto IPv4 como IPv6 pero prefiere IPv6 cuando funciona. El algoritmo:

1. Consulta DNS para registros A y AAAA
2. Comienza conectándose a la dirección IPv6 primero
3. Espera 50-250ms (dependiendo de la implementación)
4. Si IPv6 aún no se ha conectado, inicia una conexión IPv4 en paralelo
5. Usa la conexión que se complete primero

Este enfoque equilibra rendimiento con fiabilidad. IPv6 obtiene preferencia, pero IPv6 roto no detiene las conexiones por mucho tiempo.

Orden de resolución#

El orden en que los clientes consultan registros e intentan conexiones varía según el SO y la configuración.

La mayoría de sistemas Unix/Linux:

• Consultan A y AAAA simultáneamente o AAAA primero
• Prefieren direcciones IPv6 si existen
• Controlado por /etc/gai.conf (configuración getaddrinfo)

macOS:

• Consulta ambos tipos de registros en paralelo
• Implementa Happy Eyeballs estrictamente
• Prefiere fuertemente IPv6 cuando está disponible

Windows:

• Consulta ambos tipos de registros
• Prefiere IPv6 por defecto (configurable vía registro)
• Implementa Happy Eyeballs desde Windows 8

Navegadores:

• Chrome y Firefox implementan su propio Happy Eyeballs
• No dependen únicamente del comportamiento del SO
• Pueden cachear resultados de resolución agresivamente

Cuándo IPv6 gana (o pierde)#

IPv6 típicamente gana la carrera cuando:

• La conectividad IPv6 es nativa (no tunelizada)
• El enrutamiento IPv6 es directo sin saltos extra
• El destino está bien conectado a través de IPv6

IPv6 pierde cuando:

• Está tunelizado (6to4, Teredo) con latencia agregada
• El enrutamiento toma caminos más largos que IPv4
• El servidor está mal conectado a través de IPv6
• Problemas de firewall o middlebox ralentizan las conexiones

Probar el comportamiento dual-stack#

Fuerza IPv4 o IPv6 para probar el comportamiento:

# Forzar IPv4
curl -4 https://example.com
 
# Forzar IPv6
curl -6 https://example.com
 
# Dejar que el SO elija
curl https://example.com

Compara tiempos de respuesta. Si IPv6 es significativamente más lento, investiga problemas de enrutamiento o conectividad antes de publicar registros AAAA ampliamente.

DNS64 y NAT64#

DNS64 sintetiza registros AAAA desde registros A, permitiendo que redes solo IPv6 accedan a servicios solo IPv4. Se empareja con NAT64, que traduce paquetes entre IPv6 e IPv4.

Cómo funciona DNS64#

Cuando un cliente solo IPv6 consulta un hostname:

1. El servidor DNS64 recibe la consulta
2. Verifica la existencia de un registro AAAA
3. Si AAAA existe, lo devuelve normalmente
4. Si solo existe un registro A, sintetiza un registro AAAA usando un prefijo especial
5. El cliente se conecta a la dirección IPv6 sintetizada
6. El gateway NAT64 traduce la conexión a IPv4

El prefijo bien conocido: 64:ff9b::/96#

El prefijo DNS64 más común es 64:ff9b::/96, definido en RFC 6052. Los últimos 32 bits de la dirección incorporan la dirección IPv4.

Ejemplo de síntesis:

Registro A:    192.0.2.1
Prefijo:       64:ff9b::/96
Registro AAAA: 64:ff9b::192.0.2.1
               o 64:ff9b::c000:201 (en hex)

Algunas redes usan otros prefijos como 2001:db8::/96 o rangos personalizados. El prefijo debe configurarse de manera consistente en DNS64 y NAT64.

Cuándo necesitas DNS64/NAT64#

DNS64 es esencial para:

• Redes móviles solo IPv6 (común con T-Mobile, AT&T)
• Centros de datos solo IPv6 que acceden a servicios IPv4 heredados
• Probar comportamiento de cliente solo IPv6

No necesitas DNS64 si:

• Tu red es dual-stack
• Todos los servicios a los que accedes tienen IPv6 nativo
• Puedes exigir IPv6 en todos los servicios backend

Limitaciones y problemas#

DNS64 rompe varias cosas:

La validación DNSSEC falla – El registro AAAA sintetizado no coincide con la zona firmada. Los servidores DNS64 deben eliminar las firmas DNSSEC, reduciendo la seguridad.

Las aplicaciones que incrustan direcciones IP se rompen – Si una aplicación recibe una dirección IPv4 en JSON, XML u otros formatos de datos, DNS64 no la traducirá. La aplicación intenta conectarse a una dirección IPv4 desde una pila solo IPv6 y falla.

Los load balancers y CDNs se confunden – DNS64 hace que todos los clientes parezcan venir de la dirección del gateway NAT64. La geolocalización, limitación de velocidad e identificación de clientes se rompen.

Las referencias y redirecciones fallan – Si una respuesta DNS incluye direcciones IPv4 en secciones adicionales (como registros de pegamento NS), los clientes no pueden alcanzarlos.

DNS inverso (registros PTR)#

El DNS inverso mapea una dirección IPv6 de vuelta a un hostname. No es obligatorio para la conectividad pero es requerido para servidores de correo y útil para logging y herramientas de seguridad.

La zona ip6.arpa#

El DNS inverso IPv6 usa el dominio ip6.arpa. Cada nibble (4 bits, o un dígito hexadecimal) de la dirección se convierte en una etiqueta en el nombre de dominio, escrito en orden inverso.

Convertir direcciones a formato PTR#

Toma la dirección IPv6 completa sin comprimir, inviértela nibble por nibble y agrega ip6.arpa.

Ejemplo: 2001:db8::1

Paso 1: Expandir a forma completa:

2001:0db8:0000:0000:0000:0000:0000:0001

Paso 2: Escribir todos los nibbles:

2 0 0 1 0 d b 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

Paso 3: Invertir el orden:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 b d 0 1 0 0 2

Paso 4: Separar con puntos y agregar ip6.arpa:

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Ese es el nombre del registro PTR. Apunta a tu hostname.

Consultar DNS inverso#

Usando dig con conversión automática:

dig -x 2001:db8::1

Consultando el registro PTR directamente:

dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Usando host:

host 2001:db8::1

Delegar DNS inverso#

Las zonas DNS inversas son delegadas por tu ISP o RIR. Si tienes un /48, controlas un espacio DNS inverso /48. La mayoría de proveedores te permiten gestionarlo a través de una interfaz web o te permiten ejecutar tus propios servidores DNS para la zona inversa.

Para asignaciones más pequeñas (como un /64), algunos ISPs manejan registros PTR individuales por ti. Contáctalos con la dirección y el hostname.

Errores comunes de DNS con IPv6#

Publicar AAAA sin IPv6 funcionando#

Este es el error número uno. Habilitas IPv6 en un servidor, creas el registro AAAA y asumes que funciona. Pero si el firewall bloquea IPv6, el enrutamiento está roto o el servidor no está realmente escuchando en IPv6, los clientes esperan timeouts.

Síntoma: Cargas lentas de sitios web, especialmente en redes móviles que prefieren IPv6.

Solución: Prueba la conectividad desde múltiples redes IPv6 externas antes de publicar el registro AAAA. Usa nuestra herramienta Ping para verificar la accesibilidad.

Olvidar el DNS inverso#

El DNS directo funciona bien, pero omites el DNS inverso. Esto rompe la entrega de correo, confunde el análisis de logs y se ve poco profesional.

Síntoma: Rechazo de correo, errores de "Reverse DNS lookup failed".

Solución: Configura registros PTR para todas las direcciones de servidor. Verifica con dig -x desde múltiples ubicaciones.

Desajuste de TTL entre A y AAAA#

Tu registro A tiene un TTL de 3600 segundos, pero AAAA tiene 300. Cuando actualizas DNS, los clientes obtienen resultados inconsistentes durante horas.

Síntoma: Algunos clientes resuelven a direcciones antiguas, otros a nuevas. Difícil de solucionar.

Solución: Haz coincidir los TTLs para registros A y AAAA. Deben ser idénticos. Baja ambos antes de hacer cambios, luego súbelos nuevamente después.

Firewall bloqueando DNS sobre IPv6#

Tu servidor DNS tiene una dirección IPv6 y registro AAAA, pero el firewall bloquea UDP y TCP puerto 53 sobre IPv6. Los clientes no pueden consultarlo.

Síntoma: Las consultas DNS fallan desde clientes o redes solo IPv6.

Solución: Permite UDP y TCP puerto 53 para IPv4 e IPv6. Prueba desde un host solo IPv6. Recuerda que DNS sobre TCP es obligatorio, no opcional.

Configuración dual-stack incompleta#

Configuras registros AAAA para tu sitio web pero no para tu CDN, servidores de correo o endpoints de API. Los usuarios obtienen resultados mixtos.

Síntoma: El sitio principal funciona sobre IPv6, pero el contenido incrustado, llamadas API o correo vuelven a IPv4, perdiendo beneficios de rendimiento.

Solución: Habilita IPv6 para todos los servicios en la cadena, no solo el frontend. Prueba flujos de trabajo completos desde clientes solo IPv6.

Direcciones IPv4 hardcodeadas en configuración#

Tu DNS resuelve bien, pero los archivos de configuración de la aplicación contienen direcciones IPv4 hardcodeadas. Los servicios se rompen cuando los clientes solo IPv6 intentan conectarse.

Síntoma: La aplicación falla con errores de conexión en redes solo IPv6.

Solución: Usa hostnames, no direcciones IP, en archivos de configuración. Deja que DNS resuelva a la familia de direcciones apropiada.

Mejores prácticas#

Prueba exhaustivamente antes de publicar#

Antes de agregar registros AAAA al DNS de producción:

1. Verifica que el servicio escucha en IPv6: netstat -an | grep :80 (o tu puerto)
2. Prueba desde una dirección IPv6 externa: curl -6 https://[2001:db8::1]/
3. Verifica que las reglas de firewall permiten tráfico IPv6
4. Verifica que el enrutamiento es correcto con traceroute6
5. Prueba desde múltiples redes IPv6 (móvil, banda ancha, centro de datos)

No asumas que funciona porque el SO tiene una dirección IPv6.

Haz coincidir los TTLs para registros A y AAAA#

Establece TTLs idénticos. Esto mantiene el comportamiento de caché consistente y simplifica las actualizaciones de DNS.

example.com.    3600    IN    A       192.0.2.1
example.com.    3600    IN    AAAA    2001:db8::1

Si necesitas cambiar direcciones, baja el TTL 24-48 horas antes del cambio, haz la actualización, luego súbelo de nuevo.

Configura el DNS inverso#

Configura registros PTR para todas las direcciones IPv6 públicamente enrutables. Es requerido para servidores de correo y útil para todo lo demás.

Trabaja con tu ISP o RIR para delegar la zona inversa. Mantén los registros PTR sincronizados con el DNS directo — deben coincidir.

Monitorea ambos protocolos#

Rastrea el volumen de consultas DNS, tiempos de respuesta y tasas de error por separado para registros A y AAAA. Monitorea la resolución sobre transporte IPv4 e IPv6.

Configura alertas para:

• Consultas AAAA fallando cuando las consultas A tienen éxito
• Diferencias de tiempo de respuesta entre IPv4 e IPv6
• Caídas repentinas en el volumen de consultas IPv6

El monitoreo separado atrapa problemas antes de que los usuarios se quejen.

Usa servidores DNS capaces de IPv6#

Tus servidores DNS deben responder consultas sobre IPv4 e IPv6. Configura ambas familias de direcciones incluso si tu red aún no es completamente dual-stack.

Prueba desde clientes solo IPv6. Un número sorprendente de servidores DNS tienen registros AAAA pero en realidad no aceptan consultas sobre IPv6.

Implementa DNSSEC cuidadosamente#

DNSSEC funciona con IPv6, pero DNS64 lo rompe. Si usas DNS64 en tu red, no puedes validar DNSSEC en registros sintetizados.

Para despliegues de producción, diseña para dual-stack nativo y evita DNS64 donde sea posible.

Artículos relacionados#

• Fundamentos de IPv6 – Entiende el direccionamiento IPv6 y cómo difiere de IPv4
• Solución de problemas IPv6 – Diagnostica y soluciona problemas comunes de conectividad IPv6
• Lista de verificación de despliegue IPv6 – Guía completa para desplegar IPv6 en producción

Preguntas frecuentes#