Summary

  • Publicado em junho de 1999 como Best Current Practice, o RFC 2606 reservou .test, .example, .invalid e .localhost para funções distintas. O texto também documentou a reserva de example.com, example.net e example.org pela IANA.
  • Um nome inventado no laboratório pode se tornar um domínio público depois. Um URL de demonstração pode viajar para um programa real. A reserva criou um lugar estável para esses nomes antes da colisão.

O técnico escreve “por exemplo” e inventa um endereço. O leitor copia a linha inteira. O endereço então ganha uma carreira que seu autor jamais planejou: aparece num teste, entra num arquivo de configuração, acompanha uma biblioteca para outro ambiente. A frase que dizia “exemplo” ficou na página impressa. O DNS recebeu apenas o nome. É uma promoção espantosa para um figurante.

O RFC 2606, de D. Eastlake e A. Panitz, publicado em junho de 1999 como BCP 32, descreveu o risco em termos concretos. Um laboratório poderia criar um domínio de primeiro nível aparentemente sem uso para ensaiar código de DNS. Mais tarde, aquele rótulo poderia entrar no DNS global. A configuração local passaria a disputar a visão dos usuários com a zona real. O texto levantou também o caminho inverso: código experimental sai da bancada de testes e começa a procurar na Internet um domínio que seu autor considerava fictício.

A resposta foi reservar quatro etiquetas de primeiro nível. .test ficou recomendado para testes de código relacionado ao DNS. .example servia a manuais e ilustrações. .invalid oferecia um nome evidentemente inválido. .localhost preservava a associação local tradicional ao endereço de loopback nas implementações de hosts. Cada etiqueta tinha uma tarefa. Trocar uma pela outra só porque todas soam “especiais” jogaria fora a organização que a norma tentou construir.

O RFC também registrou três nomes de segundo nível que a IANA havia reservado: example.com, example.net e example.org. Eles resolviam outro problema da escrita técnica. Uma demonstração de formulário ou de endereço web costuma precisar de um nome que pareça normal, terminado em .com, .net ou .org. Esses três nomes tinham a aparência certa e uma destinação conhecida. O autor não precisava escolher o domínio de uma empresa que ainda nem existia.

A diferença de nível merece um momento. Em loja.example, o aviso de que se trata de exemplo está no próprio domínio de primeiro nível. Em example.com, o domínio .com continua comum; a reserva recai sobre o nome example imediatamente abaixo. São dois jeitos de separar a ficção do espaço que pode ser distribuído a outros titulares. Os dois aparecem no mesmo RFC porque manuais e testes não exigem sempre o mesmo formato de endereço.

A seção de segurança do documento deixa a piada mais séria. Programas de teste podem escapar do ambiente controlado. Endereços usados “apenas” em documentação podem acabar executados. Um rótulo inventado sem cuidado pode ganhar dono no futuro e criar confusão, inclusive em torno de direitos ligados ao nome. A solução de 1999 foi seca, quase cartorial: escolha poucos nomes, publique a finalidade de cada um, reserve-os. O site imaginário ganhou escritura para não invadir o lote vizinho.

A orientação atual da IANA mantém essa função. Os domínios de exemplo podem ser usados em documentos sem pedir coordenação prévia e não estão disponíveis para registro ou transferência. A IANA oferece uma página informativa neles, mas recomenda que aplicações não dependam do funcionamento desse serviço HTTP. O endereço foi reservado para mostrar, testar e explicar; o pequeno site informativo tem uma finalidade administrativa própria.