Resumo

  • A RFC 10001 exige para cada zona ao menos dois servidores autoritativos alcançáveis por IPv4 e dois por IPv6. Um servidor dual-stack conta uma vez em cada família; quatro comprovantes não significam necessariamente quatro máquinas.
  • NS, A, AAAA e glue documentam a delegação pretendida. O comprovante operacional ainda precisa demonstrar cadeia independente por família, resposta real em UDP e TCP e dados autoritativos equivalentes.
  • Tobias Fiebig escreveu a Best Current Practice de agosto de 2026 com Momoka Yamamoto. O registro mostra contribuição coletiva e consenso do IETF, não invenção individual, controle de produção nem adoção por uma organização específica.

Uma empresa pequena troca de provedor DNS e imagina que a decisão afeta apenas seu domínio. Ela publica dois NS, confere A e AAAA, atualiza a delegação e aguarda os TTLs. O site abre. A mudança parece encerrada.

Por trás desses dois nomes, porém, o novo provedor atende milhares ou milhões de outras zonas. Uma falha no mesmo conjunto de glue, na mesma rota ou no mesmo processo de implantação pode atravessar clientes que nunca se relacionaram entre si.

A RFC 10001 foi publicada em agosto de 2026 para disciplinar exatamente o ponto em que uma configuração vira serviço. Momoka Yamamoto e Tobias Fiebig são seus autores. O documento permanece em BCP 91, substitui a RFC 3901 e trata IPv4 e IPv6 como caminhos que precisam preservar a continuidade do espaço de nomes.

O termo alcançável tem um significado operacional. Um servidor alcançável por IPv4 recebe consultas DNS por IPv4 e responde. O equivalente vale para IPv6. Uma entrada de endereço não atende à definição por si só.

Para cada zona, são necessários ao menos dois servidores alcançáveis por IPv4 e dois por IPv6. Dois servidores dual-stack podem fornecer os quatro comprovantes. Portanto, o número não garante quatro equipamentos, quatro datacenters, quatro rotas ou quatro equipes.

Essa ressalva importa em ambientes concentrados. Se os dois servidores compartilham um load balancer, um prefixo, uma automação e uma janela de mudança, uma única ação pode retirar os quatro comprovantes. A contagem descreve serviço por família; o mapa de falhas comuns precisa ser construído à parte.

A delegação inteira precisa caber em uma família

O caminho de resolução começa no pai, não no endereço final. O resolver aprende os NS, recebe glue quando necessário e resolve os nomes que estejam fora da zona. Cada dependência pode introduzir outra zona e outro operador.

A RFC 9471 explica a função da glue nas respostas de delegação. A RFC 10001 impõe a simetria: o caminho IPv4, incluindo pai, nomes irmãos e glue, não pode depender de IPv6. O caminho IPv6 não pode depender de IPv4.

Um teste dual-stack frequentemente esconde essa condição. Se a tentativa IPv6 falha e o resolver termina por IPv4, a aplicação recebe a resposta. O mecanismo de resiliência cumpre sua função para aquela sessão, mas o operador perde a evidência de que usuários IPv6-only continuam excluídos.

O estudo How Ready is DNS for an IPv6-Only World?, publicado em 2023, investigou a cadeia completa. Fiebig aparece entre sete coautores. O trabalho mostrou por que contar AAAA não basta: glue ausente, NS fora da zona, pai quebrado ou servidor sem resposta podem interromper a resolução exclusiva em IPv6.

Os números são históricos e limitados ao método publicado. Em agosto de 2022, 44,9% das zonas observadas no conjunto do estudo não eram resolvíveis por IPv6. Dez operadores respondiam por 24,8% das zonas ainda não resolvíveis. Em janeiro de 2017, a inclusão de glue IPv6 por um provedor alterou o resultado de mais de 45,6 milhões de zonas.

Esses valores não medem a Internet de setembro de 2026. Eles preservam amostra, período, fontes passivas, validação ativa e vantage points próprios. O efeito de concentração, porém, permanece relevante: uma correção compartilhada pode alterar muitas zonas de uma vez.

Responder a uma consulta pequena não encerra o teste

Chegar ao endereço é apenas mais um estágio. Respostas pequenas em UDP podem funcionar enquanto DNSSEC ou outros conjuntos maiores encontram limite de MTU, fragmentação ou descarte no caminho. A RFC 8900 descreve a fragilidade da fragmentação IP, e a RFC 9715 orienta como evitá-la no DNS sobre UDP.

A RFC 10001 exige DNS sobre TCP como fallback, em vez de depender de UDP fragmentado. A RFC 9210 fornece o requisito operacional. Assim, o comprovante deve diferenciar uma resposta UDP, uma transação DNS completa por TCP e a passagem de um caso truncado para TCP dentro do tempo do resolver.

Porta aberta não é resposta DNS. Um handshake TCP não prova que a zona está carregada. A verificação precisa guardar consulta, código, autoridade, tamanho, duração, família e ponto de observação.

Os dados servidos formam outra fronteira. IPv4 e IPv6 devem expor dados DNS equivalentes. Uma implantação gradual pode deixar SOA, DNSKEY, delegação ou registros críticos em versões distintas. Duas respostas autoritativas não resolvem o problema se descrevem estados incompatíveis.

Equivalência não significa bytes idênticos. Ordem, assinaturas, anycast e políticas legítimas podem variar. A organização deve declarar quais fatos compara e quais diferenças interrompem a aceitação.

Um comprovante precisa dizer de onde veio

“IPv6 está funcionando” não é reproduzível sem NS, endereço, consulta, protocolo, hora e vantage. Também é preciso registrar a origem do A ou AAAA, a glue usada, o caminho da delegação e o conteúdo observado.

Um probe dentro do provedor prova o caminho interno. Um probe externo acrescenta outro caminho, mas não representa a Internet inteira. A resposta profissional é escolher pontos correspondentes a mercados, redes e domínios de falha relevantes, preservando o limite de cada conclusão.

O controle está distribuído. O titular da zona mantém os dados filhos. O pai ou registro publica delegação e glue. O provedor autoritativo opera listeners, versões e capacidade. Redes controlam rotas, filtros e parte do MTU. Monitoramento escolhe o experimento. Negócio decide se uma linha ausente impede a mudança.

Sem esse último responsável, cada equipe traz seu verde. O DNS mostra AAAA, a rede mostra rota e o provedor mostra teste interno. Todos podem estar corretos enquanto a cadeia IPv6-only falha antes de chegar ao serviço.

A matriz mínima tem quatro linhas e campos para dependência comum. Se uma única automação, rota ou organização derruba várias linhas, esse fato deve acompanhar os resultados. Diversidade nominal não pode ser vendida como independência operacional.

O papel público de Fiebig

O perfil oficial da TU Wien registra que Tobias Fiebig assumiu em 1º de março de 2026 o cargo de professor universitário de Computer Networks e lidera o grupo Internet Infrastructures. A descrição inclui medição da Internet, segurança, protocolos, DNS, SMTP, BGP e coordenação entre pessoas e organizações.

Esse contexto combina pesquisa empírica com padronização, mas não transfere autoridade operacional. A RFC 10001 é coautoria com Momoka Yamamoto e consenso do IETF. O estudo de 2023 reúne sete pesquisadores. Nenhuma fonte prova implantação pela TU Wien, pelo Max Planck Institute ou por um provedor citado.

O método se aproxima da primazia do código em funcionamento de Heng Lu. A publicação de um registro é necessária para coordenar, mas a consulta executada e a resposta observada testam o serviço. Uma camada não deve usar o comprovante da outra.

A especificação inicial mínima dá o limite complementar. O padrão comum fixa alcance por família, independência da delegação, equivalência e TCP, sem escolher fornecedor, topologia ou produto de monitoramento. Essa liberdade aumenta a responsabilidade local de mostrar como o requisito foi cumprido.

Usar o mesmo registro na mudança e no incidente

Antes de retirar o provedor antigo, as quatro linhas novas devem permanecer válidas durante uma janela definida. Pai e filho precisam estar coerentes, TTLs devem passar conforme o plano, as duas famílias devem completar a cadeia, e UDP, TCP, respostas grandes e conteúdo crítico devem ser exercitados.

Remover cedo demais a autoridade anterior reduz a capacidade de rollback enquanto resolvers ainda mantêm estados intermediários. A sobreposição não é desperdício: é um instrumento de comparação e recuperação.

Durante um incidente, a tabela identifica o primeiro handoff quebrado: NS, endereço, glue, dependência externa, pai, rota, filtro, UDP, TCP, versão da zona ou timeout. “DNS fora do ar” vira uma falha específica com dono.

A RFC 10001 também orienta resolvers recursivos. Em geral, devem ser dual-stack. Um resolver de uma só família pode usar tradução ou encaminhar falhas a um resolver dual-stack. Dois resolvers de famílias opostas não podem encaminhar a mesma impossibilidade um ao outro, pois uma zona indisponível nos dois lados geraria um loop.

Fallback, portanto, é um sistema com direção, capacidade e risco. Quando salva a resposta, deve deixar visível o fracasso original.

Quatro comprovantes não provam disponibilidade universal. Têm data, vantage e dependências. Seu valor é tornar a promessa refazível. Um cliente pode perguntar o que foi observado, quem responde pelo próximo estágio e qual evidência falta antes de chamar a zona de dual-stack.

Fontes