Resumo

  • A versão IP que transporta uma consulta DNS não determina a família dos endereços pedidos: uma consulta AAAA pode passar por IPv4 e uma consulta A por IPv6.
  • A RFC 3596 adicionou o registro AAAA de 128 bits e atualizou partes do processamento de respostas, sem vincular o conteúdo DNS ao caminho que transporta a consulta.

“IPv6” em que camada?

Imagine um resolvedor enviando uma pergunta DNS dentro de um pacote IPv4: “Quais registros AAAA estão associados a este nome?” O cabeçalho IPv4 descreve como aquela mensagem viaja. O tipo da pergunta solicita dados de endereço IPv6. Não há contradição. A RFC 3596 afirma que a versão IP usada para consultar registros é independente da versão do protocolo representada por eles. A RFC 4472 explicita a consequência operacional: é possível consultar AAAA por IPv4 e A por IPv6.

A distinção é fácil de apagar porque as duas camadas usam os nomes IPv4 e IPv6. Uma designa o invólucro de rede da consulta; a outra, os dados de um registro DNS. Se o servidor ajustasse a resposta ao transporte observado, os fatos no DNS passariam a depender de um caminho que não determina quais endereços pertencem ao nome.

A independência vale nos dois sentidos. Um transporte IPv6 não obriga o resolvedor a pedir AAAA: ele pode carregar uma consulta A. A família do pacote recebido tampouco comprova que quem consultou conseguirá usar o endereço retornado. O padrão define a separação, não a alcançabilidade futura nem o sucesso de uma conexão da aplicação.

Acrescentar um registro sem trocar o caminho

O modelo DNS anterior usava o registro A para endereços IPv4 de 32 bits. A RFC 1886 introduziu AAAA para guardar endereços IPv6 de 128 bits e um mecanismo de consulta reversa. Depois, a RFC 3152 mudou a árvore reversa de IP6.INT para IP6.ARPA. A RFC 3596 consolidou essas mudanças, preservou o suporte IPv4 existente e definiu AAAA, tipo 28, como um registro que contém um endereço IPv6 completo.

Era uma extensão dos dados dentro do DNS, não um novo transporte IPv6 para mensagens DNS. Perguntas e respostas continuavam usando a troca DNS existente. O transporte IP podia ser IPv4 ou IPv6, independentemente de a consulta pedir A ou AAAA. O espaço global de nomes não precisava se dividir em “DNS IPv4” e “DNS IPv6” porque agora podia conter as duas famílias.

Havia uma alternativa concreta. Registros A6 podiam dividir um endereço em partes encadeadas por consultas DNS, o que teria potencial para reduzir algumas atualizações quando um prefixo mudasse. Essa flexibilidade também acrescentava consultas encadeadas e dependências. A RFC 3363 registrou a escolha de manter AAAA no caminho dos padrões e mover A6 e Bit Labels para Experimental; a RFC 3364 expôs os trade-offs. Assim, a RFC 3596 escolheu o endereço completo e simples de ler, não uma solução universal para renumeração ou implantação do IPv6.

As regras de resposta também mudaram

A RFC 3596 atualizou ainda o processamento da seção Additional para consultas NS, SRV e MX: endereços A e AAAA relevantes, disponíveis localmente, podiam ser incluídos. Uma consulta AAAA não provoca por si só esse processamento. Um RR solicitado diretamente e um endereço anexado como dado auxiliar em outra resposta são comportamentos diferentes.

“O servidor pode incluir” não quer dizer que a resposta comprove a existência de todos os endereços. Dados locais podem faltar, caches podem estar incompletos e um registro DNS não é um pacote de teste. A RFC 4472 alerta contra escolher ou filtrar respostas com base apenas na família do transporte: o caminho usado para alcançar o servidor muitas vezes não corresponde à família de registros necessária ao cliente. Suprimir uma família por esse motivo pode fazer o mesmo nome parecer ter fatos diferentes conforme a rota da consulta.

Uma resposta AAAA comprova somente que o DNS devolveu dados de endereço IPv6 para um nome. Ela não comprova uma rota IPv6 a partir deste resolvedor, um serviço escutando naquele endereço, uma sessão permitida pelo firewall, a validação dos dados por DNSSEC ou a conexão de uma aplicação. Receber a resposta por IPv4 tampouco indica qual versão IP uma conexão posterior com o serviço usará.

Uma fronteira que tornou a coexistência compreensível

A contribuição histórica da RFC 3596 costuma ser resumida como “o DNS ganhou AAAA”. Ela também preservou um invariante durante a inclusão de outra família de endereços: o pacote que transporta a consulta e a família codificada no registro são dimensões independentes. Durante a transição, o transporte IPv4 podia buscar dados IPv6; o IPv6 ainda podia buscar dados IPv4, no mesmo espaço de nomes.

Os RFCs definem o mecanismo e a separação pretendida. Não mostram com que frequência as implementações a respeitaram, como um resolvedor específico se comportou nem se os registros A e AAAA de um nome eram úteis ao mesmo tempo. Essas perguntas exigem provas separadas de implementação, configuração, medição e alcançabilidade.

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