Resumen

  • RFC 920 no se limitó a enumerar nombres: vinculó cada categoría de nivel superior con una administración, un agente registrador y un procedimiento de autorización.
  • ARPA era temporal; GOV, EDU, COM, MIL y ORG componían las categorías institucionales. Los códigos de país y las multinstituciones seguían siendo opciones sin dominios ya establecidos.
  • El umbral de más de 500 hosts para un dominio de nivel superior era una expectativa general. Para el segundo nivel, más de 50 era una pauta muy flexible, y una organización grande podía quedar por debajo.

La cifra no decidía por sí sola

Los umbrales parecen ser la primera respuesta a una pregunta sencilla: ¿cuántos hosts necesita una organización para tener su propio dominio? Pero RFC 920, publicada en octubre de 1984 por Jon Postel y Joyce Reynolds, planteaba una cuestión más amplia: ¿qué clase de dominio podía existir y quién tenía autoridad para admitirlo? Era una declaración oficial de política del Internet Activities Board y DARPA para establecer dominios en ARPA-Internet y la comunidad de investigación de DARPA. No era una regla universal para todas las redes ni solo una especificación técnica.

El documento partía de una secuencia previa. RFC 881 había descrito el plan de nombres; RFC 882 y RFC 883 desarrollaban los conceptos y la implementación. RFC 920 dice que refinaba aquel plan y añadía un conjunto limitado de dominios de nivel superior. La arquitectura distribuida de nombres y la política para decidir quién podía usar cada rama estaban conectadas, pero no eran la misma cuestión.

El conjunto inicial combinaba nombres temporales, categorías y dos clases que todavía no tenían entradas establecidas:

Lugar en el conjunto inicial Nombre o clase Situación descrita en 1984
Temporal ARPA Hosts de ARPA-Internet; la etiqueta debía desaparecer con el tiempo
Categorías institucionales GOV, EDU, COM, ORG DARPA figuraba como administradora; NIC, como agente
Categoría militar MIL DDN-PMO administraba; NIC actuaba como agente
Países Códigos ISO alpha-2 ingleses de dos letras Aún no se había establecido ningún dominio de país
Multiorganizaciones Sin etiqueta asignada todavía No había ninguna establecida; podía considerarse un grupo internacional que no encajara en las demás categorías

La tabla no certificaba que ya existiera un dominio para cada clase. El propio texto dice que todavía no se habían establecido dominios de países ni de multiorganizaciones. Tampoco trataba a todos los nombres con la misma cadena de mando: DARPA administraba ARPA, GOV, EDU, COM y ORG, con el Network Information Center como agente; para MIL, la administración correspondía a DDN-PMO y el NIC seguía siendo el agente. El NIC registraba los dominios y recibía las consultas sobre la posibilidad de crear una nueva categoría de nivel superior.

La autorización estaba separada de la clasificación. Los dominios de nivel superior necesitaban aprobación especial y registro en el NIC. En general, la autorización se reservaría para dominios que se esperara que superaran los 500 hosts. Para el segundo nivel, la guía era superar los 50, pero RFC 920 la calificó expresamente como muy flexible: una universidad o empresa importante podía ser admitida aunque tuviera solo unos pocos hosts. El texto añade que no era obligatorio crear un dominio por el mero hecho de superar el umbral.

El tamaño contaba, pero también la administración responsable, el servicio de resolución y el registro ante el nivel superior.

La excepción multinstitucional revela lo que un árbol categórico no podía resolver con una lista cerrada. Un consorcio grande, compuesto por varias organizaciones, internacional y difícil de ubicar en una sola categoría podía ser candidato al nivel superior. Como ejemplo hipotético, los autores propusieron un CSNET que reunía universidades y laboratorios industriales bajo una administración responsable. La RFC lo describe como una comunidad y no como una red única. Aquí importa solo la función de ese ejemplo dentro de la regla: mostraba por qué el documento reservaba espacio para una comunidad que atravesaba las categorías.

RFC 920 también aclara que aún no se había establecido ningún dominio de ese tipo; el ejemplo no prueba que CSNET obtuviera tal condición.

Por debajo del nivel superior, el registro seguía una cadena. El administrador de un dominio de segundo nivel se inscribía ante la administración del nivel superior; los niveles sucesivos acudían al responsable inmediatamente superior. Antes de conceder autorización, esa autoridad debía comprobar que se cumplían los requisitos aplicables. Un administrador podía delegar parte del trabajo en un subdominio, pero el responsable del dominio de nivel superior seguía siendo responsable del conjunto. La jerarquía, por tanto, repartía no solo nombres, sino también obligaciones.

La tarea no era puramente administrativa. Cada dominio necesitaba una persona identificada que coordinara cuestiones del espacio de nombres, tuviera autoridad y conocimientos técnicos para corregir problemas y respondiera cuando un host perjudicara sus intercambios con otros. También debía ofrecer un servicio robusto. Dos servidores independientes en máquinas y fuentes de alimentación separadas eran una forma de reducir fallos comunes, pero no la única: los dominios podían cooperar o contratar servicio a terceros. Lo que se exigía era capacidad de mantener el servicio y los datos, no un diseño único de servidor.

ARPA tenía la excepción más claramente temporal. RFC 920 explicaba que el nombre procedía de la historia del sistema y que se esperaba que dejara de usarse. Recomendaba que los hosts actuales buscaran otro dominio. Los hosts del DDN que no participaran en el nuevo servicio podían seguir usando el archivo HOSTS.TXT que mantenía el NIC, aunque el documento preveía que también cambiaran sus nombres en el futuro. Esa previsión no demuestra que todos los hosts migraran ni que ARPA desapareciera en una fecha determinada.

La RFC 1032, publicada en 1987 como guía para administradores, permite ver una etapa posterior del trabajo de registro. Describe las funciones del NIC en la zona raíz y el registro, y dice que las administraciones de CSNET y UUCP filtraban solicitudes de sus propias organizaciones antes de transmitir información al NIC. Su inventario ya incluye NET y dominios de países. Es un estado posterior, no una lista que deba atribuirse a RFC 920 en 1984 ni una prueba de que cada previsión anterior se cumpliera sin cambios.

La primera lista de RFC 920 fue, en suma, una política de elegibilidad. Separó categorías, asignó responsables, dejó una excepción para grupos que las cruzaban y definió quién debía aprobar una nueva rama. La lista era pequeña; la decisión de quién podía entrar nunca fue solo una cuestión de elegir una etiqueta.

Fuentes

Estos documentos relacionados se consultaron para acotar el tema; su situación posterior no se proyecta hacia 1984.