IPv6 aprende a anunciar DNS: RDNSS, DNSSL e os RFCs 5006, 6106 e 8106

Resumo

O SLAAC podia dar a um host IPv6 um endereço e uma rota sem fornecer o resolvedor recursivo necessário para transformar nomes em destinos.
O RDNSS levou a descoberta do resolvedor para os Router Advertisements; o DNSSL acrescentou sufixos de pesquisa, e os RFCs seguintes trataram de validade, ordem das fontes e suporte obrigatório.

Um endereço não é um resolvedor

Um host IPv6 pode ter endereço válido, prefixo e roteador padrão e ainda falhar antes de abrir um site: falta um resolvedor recursivo para descobrir o destino por trás do nome. A rede explicou para onde enviar pacotes. Não explicou onde fazer a pergunta sobre nomes.

O Neighbor Discovery e o Stateless Address Autoconfiguration cuidavam da primeira parte. Os Router Advertisements levavam informações do enlace; com SLAAC, o host formava um endereço sem obter um aluguel de endereço DHCPv6. O DNS seguia por outra via. Em 2007, o RFC 5006 registrou que DHCP era o único mecanismo de configuração de DNS da IETF no Standards Track. Para um notebook que mudava de rede sem fio, trocar o resolvedor manualmente a cada parada era uma solução ruim.

O RFC 5006 propôs uma alternativa Experimental: um Router Advertisement IPv6 podia carregar a opção Recursive DNS Server, ou RDNSS. O host aprendia o endereço do resolvedor na mesma mensagem que trazia a configuração do enlace. Não era preciso abrir uma segunda troca de protocolo. O roteador, porém, ainda precisava ser configurado; o RFC não ensinava o equipamento a descobrir seu próprio DNS.

O anúncio do roteador passou a carregar nomes

Em 2010, o RFC 6106 levou as opções DNS ao Standards Track e acrescentou o DNSSL, uma lista de sufixos de pesquisa. O RDNSS entregava um ou mais endereços de resolvedores. O DNSSL fornecia sufixos que o host podia acrescentar a um nome incompleto consultado por um aplicativo. O mesmo fluxo de Router Advertisements podia levar prefixo, roteador, resolvedor e lista de pesquisa.

O DHCPv6 continuou no jogo. O RFC 6106 descreveu DHCPv6 e RA como mecanismos que podiam coexistir, úteis em redes e configurações de host diferentes. Mais tarde, o RFC 8106 orientou o host a manter uma lista ordenada quando recebesse informações DNS por vários Router Advertisements ou por DHCP. Um DNS configurado pelo usuário continuava sendo uma escolha à parte. O problema passou a ser a ordem das fontes, não a busca de um vencedor universal.

A perda de pacotes mudou o relógio

As entradas RDNSS e DNSSL têm prazo de validade. Quando o tempo acaba, o host remove a informação; um anúncio é uma concessão temporária de configuração, não um ajuste permanente. O RFC 6106 limitava a validade pelo intervalo máximo entre Router Advertisements. Publicado em 2017, o RFC 8106 observou que o limite anterior de duas vezes esse intervalo podia deixar as opções DNS expirarem em enlaces com muita perda de pacotes. O texto elevou o padrão para três vezes o intervalo máximo.

É uma diferença pequena no diagrama de pacotes e grande no registro de incidentes: o endereço e a rota podem continuar válidos enquanto a entrada do resolvedor desaparece. Um aplicativo pode parecer sem rede mesmo quando o host ainda alcança diretamente um endereço IP.

O suporte entrou na linha de base do IPv6

O nível de exigência subiu junto com o mecanismo. Em 2011, o RFC 6434 dizia que implementações SHOULD oferecer suporte à opção DNS em RA. Em 2019, o RFC 8504 passou a exigir que nós IPv6 MUST oferecessem esse suporte. A sequência foi da saída Experimental a uma capacidade requerida: um endereço, sozinho, não basta para usar a Internet como as pessoas a usam.

As regras de origem dão à opção seu verdadeiro peso operacional. O RFC 8106 recomenda que o host mantenha uma lista ordenada com informações de RA e DHCP; em geral, as informações de DHCP vêm primeiro. Um RA protegido por SEND tem preferência sobre uma fonte DHCP sem autenticação. Uma configuração estática feita pelo usuário pode prevalecer sobre os dados anunciados.

Os RFCs estabelecem mudanças de projeto e de requisito; não trazem um censo oficial de hosts que usam RDNSS, portanto não permitem afirmar quantos clientes o adotaram.