Resumo

  • O A6 podia montar um endereço IPv6 a partir de partes mantidas separadamente no DNS. Isso reduzia algumas alterações durante uma renumeração, mas transformava cada elo em nova consulta, novo estado de cache, nova oportunidade de falha e nova dependência administrativa.
  • A RFC 3363 transferiu o A6 e os rótulos binários do status Proposed Standard para Experimental e preferiu AAAA em produção. A decisão mudou a recomendação formal; não apagou código nem zonas já implantados.

Há uma solução sedutora para armazenar um endereço sujeito a mudança: não guardar o endereço inteiro em um único lugar. O identificador estável do host fica perto do host. O provedor mantém o prefixo que ele pode trocar. Quando alguém consulta o nome, o resolvedor compõe as partes.

Essa era a promessa particular do registro A6 definido na RFC 2874. O desenho fazia o DNS refletir uma realidade administrativa: o prefixo IPv6 e a parte local de um endereço podiam mudar em ritmos diferentes. Numa renumeração, a substituição de um prefixo superior dispensaria a edição de todos os registros terminais. Para multihoming, a mesma estrutura podia expressar mais de uma relação de prefixo. Era uma ferramenta mais geral do que um registro AAAA com os 128 bits completos.

O custo só aparecia quando a representação precisava virar resposta. O resolvedor talvez não pudesse ler um registro e terminar. Precisava seguir o nome do prefixo até outro A6, e talvez a outro. Cada etapa podia exigir consulta a um servidor autoritativo distinto. Cada resultado tinha tempo de vida, estado de cache, operador e possibilidade de ausência próprios.

A RFC 3363 transformou esse grafo de dependências em decisão de padronização. Publicada em agosto de 2002 como documento Informational, ela atualizou as RFCs 2673 e 2874 e moveu as duas especificações de Proposed Standard para Experimental. O texto registrou o consenso percebido nas comunidades DNSEXT e NGTRANS: AAAA era preferível para produção; A6 conservava propriedades interessantes que mereciam estudo; e ainda não se sabia se os benefícios superavam os custos e riscos.

Essa formulação importa. Não foi uma conclusão de que a composição não tinha valor. A RFC 3364, publicada como análise complementar, reconheceu a vantagem real do A6. Ele representava endereços cujos prefixos podiam mudar sem aviso de uma forma que registros AAAA estáticos não reproduziam durante a consulta. Seria possível pré-processar e regenerar dados AAAA, mas nesse caso a informação de dependência apenas sairia do protocolo e iria para o sistema de provisionamento.

A RFC 3363 examinou o caminho que a consulta precisava percorrer. Sem respostas já em cache, calculou que o tempo de resolução de uma cadeia A6 com N elos seria aproximadamente proporcional a N. A probabilidade de falha também cresceria mais ou menos com N, pois cada subconsulta trazia sua própria chance de fracasso. Trata-se de raciocínio arquitetural, não de uma medição mundial: o documento não publicou censo de latência nem um multiplicador universal.

A fronteira administrativa pesava tanto quanto o número de consultas. Algumas das disposições mais úteis do A6 apontavam para fora da zona terminal, até uma zona operada por outra organização. O DNS permite essas referências; a dificuldade é conservá-las. A experiência com glue e ponteiros reversos já mostrava que referências entre instituições envelheciam mal quando nenhuma equipe controlava o reparo completo.

Assim, uma cadeia podia estar correta em cada edição local e falhar como sistema. O administrador do host preservava o sufixo. O provedor publicava o prefixo. Um terceiro cuidava de outra delegação. Para produzir a resposta, o resolvedor precisava de um retrato temporal mutuamente coerente. Um cache antigo podia levar dois observadores a montar endereços diferentes, embora nenhum registro isolado fosse sintaticamente inválido.

AAAA fez outra escolha. O endereço IPv6 completo passou a caber num único registro. Uma renumeração podia exigir mais atualizações, e automação continuava necessária, mas a dependência da consulta ficava claramente limitada. A RFC 3363 recomendou manter a RFC 1886 no caminho de padronização e avançá-la, enquanto o A6 seguiria como Experimental. A RFC 3596 posteriormente definiu o modelo AAAA e IP6.ARPA que se tornou a referência normal de produção.

A árvore reversa forneceu uma segunda correção. A RFC 2673 introduzira rótulos binários, o primeiro tipo novo de rótulo DNS desde a RFC 1035. O mecanismo reunia rótulos de um bit em cadeias e oferecia uma notação compacta para mapeamento reverso. A implantação revelou um problema mais duro: servidores sem suporte ao novo formato podiam rejeitar a própria consulta como malformada.

A RFC 3363 concluiu que rótulos textuais hexadecimais eram suficientes para os esquemas de delegação reversa então esperados. Os rótulos binários também passaram a Experimental. O uso planejado de DNAME na árvore reversa foi desaconselhado junto com o A6 fragmentado. A escolha da raiz da árvore reversa era questão distinta, fora do escopo, tratada pela RFC 3152.

Foi padronização por subtração. Duas propostas já tinham alcançado Proposed Standard, mas a experiência de implantação mostrou que sua novidade aumentava a superfície de compatibilidade antes de existir evidência operacional suficiente. A resposta não apagou a pesquisa. O status Experimental a preservou para estudo e a retirou do caminho preferido de produção.

O alcance dessa mudança precisa permanecer exato. Um documento pode mudar o nível formal de outro. Não pode remover código de um resolvedor, reescrever uma zona, limpar caches, consertar um ponteiro entre organizações nem provar migração para AAAA. Status normativo, capacidade da implementação, dados publicados e resultado observado são recibos diferentes.

A mesma separação impede que AAAA vire mito de vitória. Um registro completo evita a montagem serial do endereço, mas não garante provisionamento atual, reverso correto, validação DNSSEC, rota alcançável ou serviço funcional. A RFC 4472 ainda encontrou muitos problemas operacionais de DNS IPv6 depois que AAAA se tornou a forma comum. A estrutura mais simples removeu uma classe de incerteza; não aboliu a operação.

A RFC 3597 acrescenta uma lição vizinha. Software DNS precisa transportar tipos de registro desconhecidos sem exigir compreensão semântica imediata. Mas aceitar dados de tipo desconhecido e entender uma nova sintaxe de rótulo são superfícies de compatibilidade distintas. Um servidor podia preservar um registro que não conhecia e, mesmo assim, rejeitar uma codificação de nome que não sabia analisar.

O registro atual de parâmetros DNS da IANA conserva códigos e status. É um artefato de coordenação durável, não um censo histórico de implantação. Ele não revela quais versões de resolvedor suportavam A6, quais zonas o publicaram, por quanto tempo os registros sobreviveram à mudança de status ou o que os usuários observaram.

Dois ensaios de Lu Heng oferecem o enquadramento analítico aqui declarado. “Minimum Initial Specification” sustenta que a camada comum deve conter somente a estrutura determinística necessária à compatibilidade, deixando a adoção posterior a participantes que executam código. O A6 colocou mais composição dinâmica no caminho comum de resolução; AAAA deixou mais trabalho de renumeração com o provisionamento e os operadores. “On Reality Layers” impede que a mudança de status seja confundida com um acontecimento operacional instantâneo. O documento mudou primeiro; código, zonas, caches e resultados podiam mudar em relógios diferentes.

A lição histórica não é que elegância seja suspeita. É que composição consome confiabilidade. Um componente é valioso quando pode mudar de modo independente. A mesma independência vira risco quando a resposta final depende da presença simultânea de cada componente, administrador e consulta.

A RFC 3363 executou um recuo disciplinado. Conservou a ideia como experimento, estreitou a recomendação de produção e deixou que sistemas em funcionamento demonstrassem a adoção. O endereço ainda podia ser montado em partes. O DNS de produção deixou de fingir que cada nova parte era gratuita.

Fontes