Resumo
- A RFC 920 não apenas listou nomes de nível superior: associou cada categoria a um administrador, a um agente de registro e a condições de autorização.
- ARPA era explicitamente temporário; GOV, EDU, COM, MIL e ORG formavam as categorias institucionais. Códigos de países e multinstituições ainda eram possibilidades sem domínios estabelecidos.
- Mais de 500 hosts era a expectativa geral para um domínio de nível superior. Para o segundo nível, mais de 50 era uma orientação muito flexível, e uma organização importante podia ficar abaixo disso.
Uma lista que também controlava a entrada
Os primeiros nomes de nível superior não foram apresentados como opções abertas para qualquer interessado. Em outubro de 1984, RFC 920, de Jon Postel e Joyce Reynolds, declarou-se uma política oficial do Internet Activities Board e da DARPA para estabelecer domínios na ARPA-Internet e na comunidade de pesquisa da DARPA. O documento não tratava apenas de como uma árvore de nomes seria organizada. Também especificava quais tipos de domínio poderiam existir, quem os administraria e como uma proposta chegaria à autorização.
A política veio depois de uma sequência técnica. RFC 881 havia apresentado o plano de nomes de domínio; RFC 882 e RFC 883 detalharam os conceitos e a implementação. A RFC 920 diz que refinou os requisitos anteriores e acrescentou um conjunto limitado de domínios de nível superior. A arquitetura para resolver nomes e a regra para decidir quem poderia ocupar o topo eram assuntos ligados, mas distintos.
A lista inicial reunia um nome temporário, categorias institucionais e duas classes que ainda não tinham entradas criadas:
| Posição na lista inicial | Nome ou categoria | O que o texto dizia em 1984 |
|---|---|---|
| Temporário | ARPA | Hosts da ARPA-Internet naquele momento; marcado como temporário |
| Categorias institucionais | GOV, EDU, COM, ORG | DARPA administrava; o NIC atuava como agente |
| Categoria militar | MIL | DDN-PMO administrava; o NIC atuava como agente |
| Países | Códigos ISO alpha-2 em inglês, com duas letras | Nenhum domínio nacional havia sido estabelecido |
| Multinstituições | Ainda sem etiqueta definida | Nenhuma havia sido criada; um grupo internacional fora das demais categorias poderia ser considerado |
A relação não prova que todos esses ramos já estivessem em uso. A RFC 920 afirma que os domínios de países e de multinstituições ainda não haviam sido estabelecidos. A distribuição de autoridade também não era uniforme. DARPA administrava ARPA, GOV, EDU, COM e ORG, com o Network Information Center como agente. MIL ficava sob a administração do DDN-PMO, enquanto o NIC também atuava como agente e registrador. Um nome plausível não bastava para criar um domínio de nível superior: havia autorização e registro.
As quantidades de hosts não formavam uma barreira única. Um domínio de nível superior exigia autorização especial e, em geral, só seria autorizado se se esperasse que superasse 500 hosts. Para o segundo nível, a orientação era mais de 50, mas a RFC 920 a chamou de exigência muito flexível; uma grande universidade ou empresa poderia ser aceita com poucos hosts. O texto também dizia que ninguém precisava formar um domínio apenas por passar do limite. Tamanho era apenas um dos elementos: administração responsável, serviço de nomes confiável e registro junto à autoridade do nível acima também importavam.
A exceção para multinstituições mostra por que o sistema precisava de mais do que uma classificação fechada. Um grupo grande, internacional e formado por várias organizações poderia ser considerado para o nível superior se não se encaixasse facilmente nas categorias. Como exemplo hipotético, a RFC 920 descreveu um consórcio chamado CSNET, composto por universidades e laboratórios industriais, com uma administração responsável. O exemplo explica a função da exceção: uma comunidade poderia atravessar fronteiras institucionais.
O próprio documento ressalta que ainda não havia um domínio multinstitucional estabelecido; portanto, esse cenário não prova que o CSNET tenha recebido tal status.
A cadeia de registro continuava nos níveis inferiores. O administrador de um domínio de segundo nível se registrava com a administração do nível superior; os níveis seguintes tratavam com o administrador imediatamente acima ou com a pessoa responsável por ele. A autoridade superior precisava confirmar que os requisitos haviam sido atendidos antes de aprovar a nova ramificação. Um administrador podia repassar parte do trabalho a um subdomínio, mas continuava responsável pela árvore maior. A hierarquia repartia tanto os nomes quanto as obrigações de mantê-los funcionando.
Essa responsabilidade tinha consequências práticas. Cada domínio precisava de uma pessoa identificada para coordenar questões, com conhecimento técnico e autoridade para resolver problemas. Se um host afetasse as interações com hosts externos, essa pessoa deveria receber a reclamação e agir até que a falha fosse eliminada. O serviço de nomes também precisava ser confiável. Duas máquinas independentes, com fontes de alimentação separadas, eram uma forma de evitar um ponto comum de falha, mas não a única. Domínios podiam cooperar ou contratar um terceiro. A exigência era sustentar os dados e o serviço, não adotar uma topologia única.
ARPA era a exceção com prazo mais explícito. A RFC 920 explicava que o nome refletia a história do sistema e que seu uso deveria terminar. Recomendava que os hosts existentes se preparassem para ingressar em outro domínio. Hosts do DDN que não participassem do novo serviço de nomes poderiam continuar usando HOSTS.TXT, mantido pelo NIC, embora o texto também previsse que mudassem seus nomes no futuro. São planos e recomendações publicados em 1984, não prova de que todos os hosts migraram ou de que ARPA desapareceu numa data específica.
A RFC 1032, publicada em 1987 como guia para administradores, registra uma etapa posterior. Ela descreve funções do NIC no registro e na zona raiz e diz que as equipes de CSNET e UUCP filtravam solicitações de suas próprias organizações antes de enviar informações ao NIC. A lista de domínios de nível superior já inclui NET e domínios de países. Esse é um retrato posterior, que não deve ser projetado sobre a lista inicial de 1984 nem tratado como prova de que todo plano anterior foi executado sem alterações.
A primeira lista de RFC 920 era, portanto, uma política de elegibilidade. Ela separou categorias, nomeou administradores, abriu uma exceção para grupos que as atravessavam e definiu quem podia autorizar um novo ramo. Os nomes eram poucos; a decisão sobre quem chegava ao topo já era institucional.
Fontes
- RFC 920 — Domain Requirements
- RFC 881 — The Domain Names Plan and Schedule
- RFC 882 — Domain Names: Concepts and Facilities
- RFC 883 — Domain Names: Implementation and Specification
- RFC 1032 — Domain Administrators Guide
Estes documentos relacionados foram consultados para delimitar o tema; seu estado posterior não é projetado de volta para 1984.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

