Resumo

  • RFC 3152 escolheu IP6.ARPA, solicitou delegação conforme instruções do IAB e alinhou as subdelegações à distribuição dos endereços IPv6; não criou cada zona ou registro PTR.
  • Depreciar IP6.INT significava evitar o nome em implementações novas e eliminá-lo de modo ordenado. A etapa de retirada de 2005 mostra que consenso e corte operacional não foram simultâneos.
  • Evidência confiável separa status do RFC, delegações, dados PTR, sufixo consultado, cache, resposta, validação e decisão do aplicativo. Nome reverso não é identidade autenticada.

O destino comum veio antes da chegada de todos

Documentos anteriores já tratavam da busca de nome a partir de um endereço IPv6, mas apontavam para IP6.INT. Ao mesmo tempo, o IAB consolidava .ARPA como casa dos espaços técnicos de infraestrutura. RFC 3152 resolveu a localização, não toda a operação.

O BCP atualizou referências em cinco RFCs, pediu à IANA que delegasse IP6.ARPA segundo instruções do IAB e determinou uma hierarquia coerente com as atribuições IPv6. Os RIRs receberiam partes da árvore correspondentes aos blocos sob sua administração.

O documento definiu depreciação com cautela. O uso antigo não servia para implementações novas e provavelmente seria encerrado em ordem. Isso deixava espaço para clientes antigos, publicação paralela e caches remanescentes. A norma apontava a direção sem inventar um instante global de atualização.

Uma cadeia de delegação não era uma cadeia de provas

IETF controlava a convenção; IAB orientava o domínio de infraestrutura; IANA operava a delegação superior; RIRs e titulares administravam partes sucessivas; operadores DNS publicavam os PTRs. RFC 3172 descreveu .ARPA como domínio restrito e operacionalmente crítico, confirmando a relação entre IP6.ARPA e a distribuição dos recursos numéricos.

Mas uma alocação de endereço não prova delegação reversa. A referência do pai não prova que o filho responde. Autoridade do filho não prova existência do PTR. E o PTR não prova que o nome retornará ao endereço numa consulta AAAA.

Cada camada tem operador, instante e recibo próprios. Resumir tudo como reverse_dns_ready apaga exatamente onde uma migração pode estar incompleta.

A consulta correta ainda podia terminar em ausência

RFC 3596 consolidou a forma estável: inverter os nibbles hexadecimais do endereço, separá-los em rótulos e acrescentar IP6.ARPA. Formar esse QNAME corretamente comprova apenas a entrada da busca.

Depois podem surgir referral, NXDOMAIN, SERVFAIL, timeout, resposta em cache, resposta insegura ou resposta validada. Um PTR é dado publicado por uma zona, não certificado de propriedade, alcance ou autorização. Nem sequer garante correlação direta.

Assim, cliente e autoridade migravam em eixos diferentes. O software podia consultar a árvore nova antes de a zona existir; a zona podia estar pronta enquanto o cliente ainda perguntava à árvore antiga.

A convivência evitava ruptura e escondia origem

Manter os dois sufixos por algum tempo reduzia o custo de um lançamento simultâneo. Porém um fallback silencioso tornava o sucesso ambíguo. O nome exibido não revelava qual árvore respondeu. Dados divergentes podiam coexistir, e cache negativo podia ocultar uma delegação recém-publicada.

O comprovante precisa do QNAME, versão do resolvedor, cache, fallback, cadeia de referrals, autoridade, RCODE, RRset, TTL e validação. Sem isso, “funcionou” não identifica o mecanismo.

A cronologia confirma a transição. RFC 3596 incorporou IP6.ARPA ao padrão IPv6 em 2003. RFC 4159 orientou que, a partir de 1º de setembro de 2005, implementações conformes deixassem de usar IP6.INT e que RIRs combinassem o fim do suporte com suas comunidades. A escolha de 2001 não encerrou sozinha a retirada.

Um documento obsoleto podia deixar seu resultado vigente

RFC 3596 tornou RFC 3152 obsoleto porque absorveu sua mudança. Não aboliu IP6.ARPA. Outros componentes evoluíram separadamente: RFC 3363 favoreceu AAAA diante de A6 e Bitstring Labels; RFC 5855 estabilizou nomes de servidores das zonas reversas; RFC 9121 registrou IP6.INT como domínio histórico removido de .INT.

Formato de registro, raiz, hospedagem e retirada eram superfícies distintas. Uma narrativa de simples renomeação apagaria essa engenharia.

“Nenhuma ameaça nova” não significava confiança

RFC 3152 reconheceu exploração de spoofing no mapeamento reverso IPv4 e disse que a delegação nova não criava ameaças adicionais. A frase limitava a mudança; não autenticava PTR.

RFC 3596 afirmou que dados DNS deveriam ser tratados como inseguros sem técnicas adequadas. DNSSEC pode validar o dado dentro da cadeia DNS, mas não comprova o significado humano do nome, a posse atual da máquina nem o direito concedido pelo aplicativo.

Validação, correlação direta e política de uso exigem recibos independentes. Um nome agradável em log não deve virar credencial.

O código em execução media o estado real

Com delegação e PTR corretos, um cliente antigo ainda consulta IP6.INT; outro usa a árvore nova, mas conserva NXDOMAIN em cache; um terceiro recebe o nome. O padrão é um só, os fatos operacionais são três.

A primazia do código em execução preserva essa diferença. RFC 3152 governa raiz e modelo de delegação. A execução informa o sufixo escolhido, a autoridade alcançada, o dado recebido e a consequência.

A especificação inicial mínima coordenou sem exigir atualização atômica: raiz comum, delegação, hierarquia por endereço e depreciação. Foi suficiente para mover a Internet e pequena o bastante para admitir transição. Por isso IP6.ARPA podia estar certo antes do último vestígio de IP6.INT desaparecer.

Fontes