Llegó la dirección. El resolver, no: IPv6 aprendió a anunciar DNS

Resumen

SLAAC podía dar a un host IPv6 una dirección y una ruta sin entregarle el resolver recursivo necesario para convertir nombres en destinos.
RDNSS llevó la búsqueda del resolver a los Router Advertisements; DNSSL añadió sufijos de búsqueda y las normas posteriores fijaron vigencia, orden de fuentes y compatibilidad.

Una dirección no es un resolver

Un host IPv6 puede tener dirección válida, prefijo y router predeterminado, y aun así quedarse bloqueado antes de llegar a un sitio web: no tiene resolver recursivo que traduzca el nombre del sitio. La red le ha dicho por dónde pueden salir los paquetes. Todavía no le ha dicho a quién preguntar por los nombres.

Neighbor Discovery y Stateless Address Autoconfiguration resolvían la primera parte. Los Router Advertisements llevaban información del enlace; SLAAC permitía que el host formara una dirección sin un arrendamiento de dirección DHCPv6. El DNS viajaba por otro camino. En 2007, RFC 5006 decía que DHCP era el único mecanismo de configuración DNS del IETF en Standards Track. Para un portátil que cambiaba de red inalámbrica, sustituir a mano el resolver en cada parada era un mal trato.

RFC 5006 ofreció otra vía, aunque la marcó Experimental: un Router Advertisement de IPv6 podía llevar una opción Recursive DNS Server, o RDNSS. El host aprendía la dirección del resolver en el mismo anuncio que entregaba la configuración del enlace. No hacía falta un segundo intercambio de protocolo. El router aún debía estar configurado; el RFC no le enseñaba a descubrir sus propios servidores DNS.

El anuncio del router empezó a incluir nombres

En 2010, RFC 6106 llevó las opciones DNS a Standards Track y añadió DNSSL, la lista de búsqueda DNS. RDNSS entregaba una o varias direcciones de resolvers. DNSSL entregaba sufijos que el host podía añadir a un nombre no cualificado pedido por una aplicación. Un portátil podía recibir prefijo, router, resolver y lista de búsqueda en el mismo flujo de Router Advertisements.

DHCPv6 no desapareció. RFC 6106 presenta DHCPv6 y RA como mecanismos compatibles entre sí, útiles en redes y configuraciones de host distintas. Más tarde, RFC 8106 indicó al host que mantuviera una lista ordenada cuando varias RA o DHCP aportaran información DNS. La configuración estática elegida por el usuario seguía siendo otra opción. El problema pasó a ser el orden de las fuentes, no una competencia con un ganador universal.

Un temporizador dejó ver la pérdida

Las entradas RDNSS y DNSSL tienen un tiempo de vigencia. Cuando vence, el host elimina la entrada: el anuncio concede un plazo para usar la información DNS, no una configuración permanente. RFC 6106 acotó ese plazo a partir del intervalo máximo de los Router Advertisements. RFC 8106, publicado en 2017, registró que el límite inferior anterior, dos veces ese intervalo, podía dejar caducar las opciones DNS en enlaces con mucha pérdida de paquetes. Relajó ese límite y fijó un valor predeterminado mayor: tres veces el intervalo.

El cambio ocupa poco en un diagrama de paquetes y mucho en el registro de una incidencia: la dirección y la ruta pueden seguir válidas mientras desaparece el resolver. Una aplicación puede parecer desconectada aunque el host todavía alcance directamente una dirección IP.

La compatibilidad pasó a ser un requisito de IPv6

El nivel de exigencia siguió al mecanismo. En 2011, RFC 6434 decía que las implementaciones SHOULD admitieran la opción DNS de RA. En 2019, RFC 8504 dijo que los nodos IPv6 MUST la admitieran. La trayectoria fue de una opción experimental a una capacidad requerida: una dirección por sí sola no bastaba para ofrecer un servicio de Internet útil.

Las reglas de origen muestran el verdadero alcance de esta función. RFC 8106 pide que el host conserve una lista ordenada de información recibida por RA y DHCP; normalmente, la información de DHCP aparece primero. Una RA protegida mediante SEND tiene prioridad frente a una fuente DHCP no autenticada. La configuración DNS estática del usuario puede prevalecer sobre lo anunciado.

Estos RFC documentan los cambios de diseño y de requisitos; no ofrecen un censo oficial de hosts que usen RDNSS, así que no se puede indicar cuántos clientes hay desplegados.