Resumo

  • A RFC 6761, de fevereiro de 2013, criou o registro de nomes de domínio de uso especial da IANA. Uma nova designação precisa responder a sete perguntas, dos usuários até os registros e registradores.
  • A lista inicial reuniu nomes antes reservados e zonas de reverso para endereços privados. O rótulo comum não produz uma resposta comum: localhost volta ao loopback, invalid pede resposta negativa e uma zona privada pode ser atendida dentro da rede.
  • Em 2017, a RFC 8244 registrou problemas de coordenação entre IETF e ICANN, a indefinição de “uso técnico” e o uso de nomes por terceiros sem consulta prévia. Para saber o que aconteceu em uma máquina, é preciso observar sua configuração e suas consultas.

O carimbo fica no papel

Um programa recebe um nome de teste. Ele pode entregá-lo a uma biblioteca de resolução, que consulta um servidor recursivo, que por sua vez pode buscar um servidor autoritativo. Em paralelo, um registrador decide se alguém pode comprar aquele nome. Esses participantes não compartilham um único botão. A entrada no registro da IANA é pública, mas não atualiza automaticamente o código de cada um.

A RFC 2606 já havia reservado, em 1999, nomes para testes, exemplos, falha proposital e o computador local. Sua preocupação era impedir que um nome inventado em documentação ou código colidisse com um domínio alheio. A RFC 6761 retomou a questão em outro ponto: quem reconhece a reserva quando a consulta acontece, qual resposta devolve e quem continua a busca? Separar os dois momentos impede que a história se resuma a uma lista de nomes curiosos.

O registro da IANA começou com as reservas existentes e com zonas de mapeamento reverso de endereços privados. Cada linha traz uma referência. É um índice de especificações, não uma central por onde passa cada pergunta do DNS. A distinção parece burocrática até o dia em que um sistema entrega um resultado diferente daquele que o nome sugere.

Sete perguntas, nenhum piloto automático

A RFC 6761 exige que uma nova reserva venha de uma especificação aprovada por Standards Action da IETF ou pelo IESG. O documento deve identificar precisamente os nomes abrangidos e responder às considerações de reserva em sete frentes. O usuário precisa reconhecê-los? A aplicação? A API e a biblioteca de resolução? O servidor DNS de cache? O autoritativo? O operador de servidores? O registro ou registrador que recebe pedidos de domínio?

Cada pergunta aponta para uma responsabilidade diferente. Para zonas de reverso privado como 10.in-addr.arpa, aplicações e APIs devem continuar a fazer a consulta normal ao servidor de cache configurado. O cache, por padrão, deve evitar consultas a servidores autoritativos externos e responder localmente. Em uma rede privada com servidor próprio, pode haver configuração para buscar a resposta nele. Portanto, ver um pacote sair da aplicação não encerra a análise. É no cache que a regra relevante pode entrar em ação.

O tratamento de localhost ocorre mais cedo: consultas por endereço devem receber o endereço de loopback sem uma viagem pelo DNS público. Para invalid, o caminho esperado é a resposta negativa imediata. Ambos são “especiais”, mas a função do nome e o lugar da decisão não coincidem. Uma captura de uma única etapa pode acusar o componente errado; uma linha do registro nem sequer mostra a etapa.

Hoje o registro oficial inclui localhost, invalid, local, onion, home.arpa e zonas privadas, cada qual remetendo ao documento correspondente. Algumas exceções ainda usam DNS; outras dependem da rede local ou de um contexto da aplicação. A RFC 6761 não restringiu o mecanismo aos domínios de topo nem decretou um atalho universal que ignore DNS. O campo compartilhado na tabela é a designação; o comportamento mora nas referências.

Quando o nome viaja sozinho

Alguém copia um nome interno para uma mensagem. O destinatário abre a mensagem em outra rede. A grafia permanece igual, mas o ambiente que lhe dava sentido não acompanha o texto. O nome pode apontar para outro lugar ou para nenhum. A RFC 8244 usa esse tipo de desencontro para mostrar o custo das interpretações locais dentro de uma sintaxe que parece global.

Publicada em outubro de 2017, a RFC 8244 organizou problemas observados no processo de designação. Havia ligação institucional entre IETF e ICANN, mas faltava um procedimento formal para coordenar essas alocações. Também faltava consenso sobre o que seria “uso técnico”. As duas organizações tinham papéis no espaço de nomes; nenhuma conseguia impedir que um terceiro simplesmente começasse a usar uma parte dele.

O texto descreveu outras fontes de atrito: um nome privado pode vazar, um uso informal pode encontrar uma alocação oficial posterior, e um desenvolvedor pode desconhecer o processo ou prever uma recusa. O relatório não associa essas hipóteses a um produto específico. Para julgá-lo, faltariam a configuração daquela época e o rastro de consultas. A designação tem data e referência; a execução precisa de outro recibo.

A ironia administrativa é exata. A instituição abriu uma gaveta para nomes especiais e descobriu que cada cartão chamava sete equipes distintas. As perguntas de 2013 tentaram pôr esses deveres no papel antes de abrir mais uma gaveta. O inventário de 2017 mostrou que também havia disputa sobre quem podia pedir a chave.