Resumo

  • O RFC 3405 exigiu esquema URI ou namespace URN previamente registrado, especificação estável e autoridade reconhecida antes de publicar NAPTR em uri.arpa. ou urn.arpa.. Sintaxe DNS válida não concedia autoridade.
  • As zonas comuns teriam TTLs extremamente longos. Regras com maior chance de mudar deveriam ficar numa zona delegada de TTL menor, atrás de uma dica inicial estável.

TTL longo costuma parecer obstáculo. O RFC 3405 o transformou em material arquitetural. Se uma entrada global podia sobreviver anos em caches, não deveria carregar a política mais volátil; deveria apontar de forma durável para quem a mantinha.

Publicado como BCP 65 em outubro de 2002, o texto fechou a série DDDS. O RFC 3401 apresentou o sistema, o 3402 o algoritmo, o 3403 as regras NAPTR no DNS, o 3404 os serviços URI/URN e o 3405 as atribuições sob uri.arpa. e urn.arpa..

Não era apêndice burocrático. Decidia quem podia escrever o primeiro passo num espaço DNS global, como provava essa condição e qual camada podia mudar rápido. O registro fazia parte da execução.

O esquema URI fornecia a chave inicial de uri.arpa.. Para URN, a regra urn extraía o identificador do namespace e transferia a busca para urn.arpa.. Um registro pequeno no ponto de entrada podia redirecionar uma classe inteira.

O NAPTR não criava a autoridade que afirmava representar. O esquema precisava de registro e especificação estável; o NID, de seu próprio processo concluído. A dica vinha depois da legitimidade do espaço, sem produzi-la retroativamente.

Essa ordem impedia usar urn.arpa. para contornar análise do namespace e evitava delegar URI baseado em DNS a alguém diferente do titular do domínio incorporado. Uma expressão correta ainda podia ser sequestro de autoridade.

A revisão examinava correção técnica, consistência com a especificação e propriedade do nome. Se o documento era mantido fora do IETF, adição ou mudança posterior exigia aprovação do dono ou mantenedor. Parecer técnico e autorização eram recibos distintos.

Num NID, o controle abrangia todos os NAPTR, mesmo quando uma regra afetava apenas parte do espaço. Restringir a expressão não apagava a autoridade do namespace.

O modelo de pedido trazia Key, Authority e Records. Key definia o espaço global; Authority identificava o requerente legítimo; Records descrevia a delegação executável. Era proveniência, não simples trecho de zona.

O processo original usava listas abertas e duas semanas para objeções. Elas se limitavam ao impacto sobre a zona ou DNS; o mérito do esquema já aprovado pertencia ao fórum anterior. Cada camada revia sua própria decisão.

A IANA operava zonas e listas, mas não escrevia toda regra. Autoridades do identificador forneciam direito e especificação, especialistas avaliavam impacto comum, a IANA publicava e operadores delegados mantinham a parte mutável.

O ponto central era temporal. Para reduzir a carga, os registros compartilhados teriam TTLs possivelmente medidos em anos. Política de ajuste frequente não podia morar nessa superfície.

A resposta foi delegação temporal. Um NAPTR estável na zona comum apontava para outra zona com TTL curto. A primeira camada buscava estabilidade; a segunda, agilidade. Havia dois relógios na mesma trajetória.

Um cache podia conservar o primeiro ponteiro enquanto atualizava regras posteriores. Alterar a zona delegada não revogava uma dica antiga; alterar a dica demorava a se difundir. A auditoria precisa atribuir camada, TTL e autoridade a cada versão.

Nem todo esquema exigia uma zona dinâmica. O URI HTTP já carrega o host e uma regra estável pode extraí-lo. Namespaces flexíveis se beneficiam de uma zona separada. A localização da próxima chave forma a geometria de controle.

A regra urn ilustrava governança aninhada: o URN entrava por uri.arpa., fornecia o NID e seguia para decisão específica em urn.arpa.. Uma entrada comum não uniformizava políticas locais.

Duas erratas técnicas verificadas mudam a execução. As 2687 e 2688 corrigem \2 para \1 em expressões com um único grupo. Os exemplos impressos são inválidos e não devem ser copiados para produção.

A elegibilidade também envelheceu. O RFC 3405 exigia o “IETF tree” do RFC 2717, mas árvores de nomes foram abandonadas. Uma tentativa de mudar a norma por errata foi rejeitada porque precisava de novo RFC.

O RFC 8958 fez a atualização em 2020: removeu a árvore e exigiu registro permanente conforme BCP 35, hoje RFC 7595. Mudou a porta, preservando a sequência: primeiro o espaço autorizado, depois a dica compartilhada.

O registro atual de esquemas da IANA distingue permanentes, provisórios e históricos; presença não basta para URI.ARPA. O registro de namespaces URN segue RFC 8141. Registrar nome e publicar dica são atos diferentes.

A página .arpa atual ainda lista uri.arpa sob RFC 3405/8958 e urn.arpa sob RFC 3405. Isso prova finalidade, não implantação universal nem sucesso do resolvedor.

As zonas comuns concentravam riscos de negação e falsificação. DNSSEC autenticava dados DNS, mas não a aprovação do mantenedor, a conduta da autoridade delegada ou o recurso final.

O recibo completo guarda estado do esquema/NID, especificação, autoridade, aprovação, pedido, datas, objeções, aceitação IANA, registro, DNSSEC, TTL longo, chave, autoridade e TTL posteriores, mudança, observação do cache, regra e resultado.

O princípio da especificação inicial mínima de Lu Heng explica os ritmos: padronizar o menor relevo durável e localizar futuras decisões atrás dele. A primazia do código em funcionamento pede observar DNS, aplicar erratas, mudar apenas a zona posterior, comparar TTLs e provar que autoridade segue o mantenedor registrado, não quem escreve NAPTR.

O RFC 3405 transformou estabilidade em escolha de localização. A dica inicial mudava devagar porque não fingia ser a regra corrente. O sistema mudava porque cada alteração tinha lugar, dono e relógio.

Fontes