Resumo

  • RFC 10001 determina que cada zona tenha ao menos dois servidores autoritativos alcançáveis por IPv4 e dois por IPv6, que cada delegação funcione sem depender da outra família e que ambos os transportes sirvam dados equivalentes.
  • Recursão por NAT64 ou forwarding pode preservar o serviço de um recursor de pilha única, mas acrescenta autoridades e falhas. A prova precisa identificar a cadeia completa, o prefixo PREF64, o tradutor, o destino nativo e o resultado da aplicação.

O teste começou em uma rede IPv6-only e terminou com uma resposta DNS correta. No meio, porém, o recursor descobriu um PREF64, sintetizou um endereço IPv6 para uma autoridade que só aceitava IPv4 e passou por um tradutor. Se a operação registrar apenas “família de origem: IPv6”, apagará a dependência que de fato entregou o resultado.

Esse apagamento importa em uma falha. Quando a tradução cai, a equipe de DNS pode procurar uma delegação IPv6 quebrada; a equipe de rede pode assumir que o destino era nativo; e a direção pode acreditar que comprou dois caminhos independentes. A resposta anterior não autoriza nenhuma dessas conclusões.

RFC 10001, publicado em agosto de 2026 como BCP 91, trata o problema mais amplo. O espaço de nomes se parte quando um recursor segue a delegação e encontra autoridades alcançáveis apenas por uma família que ele não possui. A tradução pode recompor alcance, mas não transforma a arquitetura subjacente.

Antes da tradução, há uma cadeia de delegação

O recursor começa na raiz e percorre referências até a zona final. Um NS dentro da zona exige glue no pai. O filho deve publicar A e AAAA coerentes. Se o NS pertence a um domínio irmão, a delegação desse domínio também deve funcionar pela família usada. Um pai inacessível corta todos os filhos abaixo dele.

RFC 10001 enumera ainda o caso em que o endereço existe, mas o servidor não responde DNS naquela família. Logo, duas verificações são obrigatórias: a configuração publicada e o comportamento observado. A primeira não substitui a segunda.

O estudo de 2023 How Ready Is DNS for an IPv6-Only World?, usado pelo RFC, mediu a cadeia inteira e mostrou que um AAAA isolado não prova resolução IPv6-only. Também encontrou concentração de falhas em poucos operadores. Os percentuais pertencem ao período estudado, mas a dependência continua relevante: uma mudança de glue em uma plataforma pode alterar milhões de caminhos sem tocar nos arquivos das zonas clientes.

A nova simetria não significa transição concluída

RFC 3901 nasceu em 2004 para impedir que autoridades somente IPv6 removessem nomes da visão de hosts IPv4. Exigia pelo menos uma autoridade IPv4. RFC 10001 substitui essa proteção unilateral por uma regra para o mundo misto.

Cada zona DEVE ter dois servidores autoritativos alcançáveis por IPv4 e dois por IPv6. Um servidor dual-stack conta uma vez em cada família. O caminho IPv4 não pode depender de IPv6, nem o IPv6 de IPv4. Os dados servidos devem ser equivalentes.

Contagem de endereços não é diversidade. RFC 2182 continua exigindo separação topológica e operacional. Quatro endereços na mesma plataforma, na mesma rota e no mesmo processo de mudança podem falhar juntos. O inventário deve revelar operador, rede, anycast, dono da glue, listener e capacidade TCP.

Equivalência também não é mera resposta. Se IPv4 e IPv6 devolvem versões, RRsets ou estados DNSSEC diferentes, há duas realidades. Registrar fingerprint, SOA, autoridade e validação em cada lado permite detectar a divergência.

O tamanho do pacote atravessa as duas famílias

Uma delegação correta pode falhar quando uma resposta DNSSEC excede a PMTU. UDP fragmentado pode ser descartado sem aviso. TCP pode ficar preso se mensagens de descoberta de MTU forem bloqueadas e o servidor usar segmentos maiores do que o caminho suporta.

RFC 10001 segue RFC 9715 para evitar fragmentação. Ele discute teto de 1400 octetos e a alternativa de 1232 para UDP; para TCP, MSS de envio de 1388 ou 1220. RFC 9210 exige disponibilidade de TCP como fallback.

NAT64 pode reduzir a PMTU efetiva porque troca cabeçalhos e insere outro domínio operacional. Por isso, a mesma política de tamanho não produz necessariamente o mesmo resultado em um caminho nativo e em um traduzido. O registro deve incluir tamanho EDNS, bytes efetivos, tradução, retry, TCP, MSS e latência.

Evitar fragmentação transfere carga para TCP. O RFC cita observações de 3–5%, mas manda medir o ambiente local. Não é uma taxa universal para dimensionamento.

Forwarding pode delegar trabalho, não responsabilidade

Recursivos devem preferencialmente ser dual-stack. Um recursor IPv6-only pode usar NAT64 ou encaminhar consultas que não completa a um recursor dual-stack. Um recursor IPv4-only pode encaminhar o caso inverso. A permissão evita impor uma única arquitetura.

O arranjo precisa preservar proveniência. RFC 9872 orienta a descoberta segura de PREF64. Guardar somente o endereço sintetizado elimina o prefixo, sua fonte, o tradutor e o IPv4 real. Esses campos definem quem poderia ter alterado ou interrompido o caminho.

Dois recursivos de pilha única não devem encaminhar um para o outro. Quando uma zona não resolve em nenhuma família, a consulta circula indefinidamente. O destino do forwarding precisa realizar recursão dual-stack e não devolver a mesma obrigação.

No stub, o conjunto recebido também pode diminuir. Algumas implementações mantêm poucos servidores recursivos e ignoram endereços excedentes de forma não determinística. DHCP ou RA descreve o que foi oferecido; o estado do cliente mostra o que ganhou autoridade.

Um ledger de continuidade e proveniência

Para cada zona crítica, executar resolução iterativa de redes realmente IPv4-only e IPv6-only. Registrar vantage point, hora, software, cada referência, NS, A, AAAA, glue, dependências irmãs, endereço autoritativo, listeners UDP/TCP, EDNS, bytes, timeout, DNSSEC e fingerprint da resposta.

Se houver tradução, anexar PREF64, método de descoberta, tradutor, destino IPv4 e PMTU observada. Se houver forwarding, registrar remetente, destinatário, motivo e proteção contra retorno. Por fim, registrar qual endereço a aplicação usou e se completou a transação.

As exigências técnicas da IANA não mudaram por efeito automático. RFC 10001 não contém ação IANA; apenas recomenda que a organização avalie uma atualização por seu processo. Publicação, procedimento e aplicação são evidências diferentes.

A Primazia do Código em Execução de Heng Lu impede que um RFC ou um AAAA seja tratado como implantação. O modelo de Especificação Inicial Mínima e Adoção Voluntária preserva o invariante comum de interoperabilidade, mas deixa arquitetura, tradução, fornecedor e rollback sob decisão local verificável.

IPv6 na origem não prova IPv6 em todo o caminho. A proveniência deve sobreviver ao sucesso.