Resumen

  • La versión IP que transporta un intercambio DNS no determina la familia de las direcciones que se solicitan: una consulta AAAA puede viajar por IPv4 y una A por IPv6.
  • RFC 3596 incorporó el registro AAAA de 128 bits y actualizó parte del comportamiento de respuesta de DNS, pero mantuvo separadas las consultas de su transporte de red.

Una palabra, dos capas

Imaginemos que un resolvedor envía una pregunta DNS dentro de un paquete IPv4: «¿Qué registros AAAA están asociados a este nombre?». La cabecera IPv4 describe cómo viaja ese mensaje concreto. El tipo de consulta pide datos de dirección IPv6. No hay contradicción. RFC 3596 afirma que la versión IP utilizada para consultar registros es independiente de la versión del protocolo de los registros. RFC 4472 recoge la consecuencia operativa: se puede preguntar por AAAA mediante IPv4 y por A mediante IPv6.

La distinción resulta fácil de perder porque ambas capas usan los nombres IPv4 e IPv6. Una designa la envoltura de red de la consulta; la otra, los datos contenidos en un recurso DNS. Si un servidor condicionara su respuesta al transporte observado, haría depender los hechos del DNS de una ruta que no determina qué direcciones pertenecen al nombre.

La independencia también opera en sentido inverso. El transporte IPv6 no obliga a solicitar AAAA: puede llevar una consulta A. La familia del paquete que llega tampoco demuestra que quien pregunta pueda usar la familia devuelta. El estándar define la separación, no la accesibilidad posterior ni el éxito de una conexión de aplicación.

Añadir un registro sin cambiar el camino

El modelo DNS anterior usaba A para una dirección IPv4 de 32 bits. RFC 1886 introdujo AAAA para almacenar una dirección IPv6 de 128 bits y un mecanismo de búsqueda inversa. RFC 3152 trasladó después el árbol inverso de IP6.INT a IP6.ARPA. RFC 3596 reunió esos cambios, mantuvo el soporte IPv4 y definió AAAA, tipo 28, como un registro que contiene una dirección IPv6 completa.

Era una ampliación del modelo de datos del DNS, no un nuevo transporte IPv6 para los mensajes DNS. Preguntas y respuestas seguían usando el intercambio DNS existente. El transporte podía ser IPv4 o IPv6 con independencia de que se solicitara A o AAAA. No hacía falta dividir el espacio global de nombres en un «DNS IPv4» y un «DNS IPv6» porque ahora pudiera contener ambas familias.

Había una alternativa real. Los registros A6 podían dividir una dirección en partes encadenadas mediante DNS, lo que ofrecía la posibilidad de reducir ciertas actualizaciones al cambiar un prefijo. Esa flexibilidad también exigía consultas encadenadas y nuevas dependencias. RFC 3363 dejó constancia de la decisión de mantener AAAA en la vía de estándares y mover A6 y Bit Labels a Experimental; RFC 3364 expuso los compromisos. RFC 3596 eligió así un registro de dirección completo y sencillo de recuperar, no una solución universal al renumerado o al despliegue.

Las reglas de respuesta también cambiaron

RFC 3596 actualizó además el procesamiento de la sección adicional para consultas NS, SRV y MX: podían incluirse direcciones A y AAAA pertinentes que estuvieran disponibles localmente. Una consulta AAAA no activa por sí misma ese procesamiento. El RR solicitado directamente y una dirección adjunta como dato de apoyo son comportamientos distintos.

«El servidor puede incluir» no significa que la respuesta pruebe que existen todas las direcciones. Puede faltar información local, las cachés pueden estar incompletas y un registro DNS no es un paquete de prueba. RFC 4472 advierte que no se deben escoger o filtrar datos según la familia del transporte: a menudo, esa familia no guarda relación con los registros que necesita el cliente. Suprimir una familia por esa razón puede hacer que un mismo nombre parezca tener datos distintos según la ruta de la consulta.

Una respuesta AAAA solo acredita que DNS devolvió datos de dirección IPv6 para un nombre. No demuestra que exista una ruta IPv6 desde este resolvedor, que un servicio escuche en esa dirección, que un cortafuegos permita la sesión, que DNSSEC haya validado los datos o que una aplicación se conectara. Recibir la respuesta por IPv4 tampoco revela qué versión IP usaría una conexión posterior al servicio.

Una frontera que hizo legible la coexistencia

La historia de RFC 3596 suele resumirse como «DNS recibió AAAA». También preservó un invariante mientras Internet incorporaba otra familia de direcciones: la envoltura que transporta una consulta y la familia codificada en el RR son dimensiones independientes. Durante la transición, IPv4 podía recuperar datos IPv6 y el transporte IPv6 podía recuperar datos IPv4 dentro del mismo espacio de nombres.

Los RFC definen el mecanismo y la separación prevista. No prueban con qué frecuencia la respetaron las implementaciones, cómo se comportó un resolvedor particular ni si los registros A y AAAA de un nombre eran útiles a la vez. Para responderlo se necesitan pruebas propias de implementación, configuración, medición y accesibilidad.

Fuentes: RFC 1034; RFC 1035; RFC 1886; RFC 3152; RFC 3363; RFC 3364; RFC 3596; RFC 3597; RFC 4472.