Resumen

  • RFC 897 permitió cambiar primero la forma oficial de los nombres y después el mecanismo de consulta; un nombre jerárquico aún podía vivir en HOSTS.TXT.
  • RFC 921 conservó el calendario anterior y señaló qué llegó a tiempo, qué llegó tarde y qué seguía pendiente.
  • La transición se completaba por comunidad y por aplicación, de modo que servidor, datos, biblioteca y programa eran controles distintos.

La infraestructura anterior al DNS ya era una cadena. RFC 810 definía la tabla central de hosts mantenida por el NIC, pero cada sitio debía obtenerla y transformarla al formato que entendiera su sistema. RFC 811 describía un servidor para consultar nombres o recuperar la tabla completa. Que el centro hubiera publicado una línea correcta no demostraba que el receptor la hubiera instalado ni que un programa la estuviera usando.

RFC 881 planteó un problema de coordinación. Los primeros nombres con puntos aparecerían en mensajes que atravesaban sistemas aún no preparados. Esperar a que todos estuvieran listos era irreal. El puente sería una tabla paralela con nombres de dominio, su posterior sustitución por la tabla principal y, al final, una función de resolución que pudiera reemplazar la vieja llamada de biblioteca sin obligar a cada aplicación a conocer el origen de la dirección.

RFC 882 y RFC 883 explicaban la nueva distribución de nombres, datos, zonas, servidores, referencias, resolutores y cachés. Especificaban un idioma común. No aportaban por sí solas una observación de que correo, Telnet o FTP hubieran dejado de consultar archivos.

La sintaxis nueva podía viajar por la tubería vieja

RFC 897, de febrero de 1984, separó dos cambios. Uno convertía nombres globales planos en nombres jerárquicos. El otro reemplazaba copias locales de una tabla central completa por acceso dinámico a servidores que poseían porciones de la base.

Su secuencia tenía cuatro pasos. Primero se añadía .ARPA al nombre existente. Luego se abrían unos pocos dominios. Después cambiaba la consulta de tablas a servidores. Por último se admitían muchos dominios. La etapa inicial mostraba la diferencia con precisión: USC-ISIF.ARPA podía ser el nombre principal aunque su dirección siguiera saliendo de una tabla local.

Los alias reducían la ruptura, pero no devolvían el control sobre las copias remotas. Un mensaje antiguo podía contener el remitente anterior; una respuesta podía dirigirse a él; una lista podía conservarlo durante meses. Un host podía aceptar el apodo, no editar la memoria de toda la red.

Además, la base distribuida debía mantener la relación entre dirección y nombre principal. Esa relación era una propiedad de coherencia. No convertía el nombre en credencial, ni una respuesta inversa en prueba de identidad.

Un mismo nombre no significaba la misma obligación

RFC 897 fijó fechas: nombres jerárquicos principales desde el 14 de marzo de 1984, eliminación de los nombres antiguos el 2 de mayo, dominios generales y multinivel el 6 de junio, dominios de organizaciones el 18 de julio, retiro de la tabla completa para la comunidad de investigación ARPA el 5 de septiembre y un plan DDN el 3 de octubre.

La comunidad ARPA debía hacer la transición completa. La comunidad operativa DDN cambiaría los nombres en el mismo calendario, pero no estaba obligada a dejar las tablas al mismo tiempo. Su oficina de programa decidiría más adelante y el NIC mantendría una tabla central para ella.

Por eso no existía una inferencia válida desde el punto en el nombre hasta el origen de la respuesta. La presentación externa podía coincidir mientras el control de datos seguía dividido.

Un calendario revisado funcionó como acta

RFC 920 publicó en octubre los requisitos para crear dominios y modificó el plan de niveles superiores. RFC 897 lo había previsto para febrero. La política estaba cambiando a la vez que se desplegaba el sistema.

RFC 921 revisó la cronología sin borrar el primer intento. Marcó la tabla inicial y el cambio de nombres de marzo como realizados a tiempo. Los servidores ARPA llegaron, pero hacia septiembre y no en abril. La tabla de dominios superiores, los nuevos dominios, los nombres multinivel, la indirección para organizaciones, el retiro de HOSTS.TXT y el plan DDN seguían sin hacerse.

La revisión separó tres fases: colocar la maquinaria, instalar la base y cambiar los programas. En octubre de 1984 ya había servidores para TOPS-20 y Unix, y la base contenía ARPA e inicialización para otros dominios. Sin embargo, se había hecho poco para que los programas de usuario llamaran a los nuevos procedimientos.

Las nuevas metas llegaron hasta octubre de 1985. No eran comprobantes de cumplimiento futuro. La evidencia más valiosa estaba en la clasificación del pasado: hecho, hecho tarde, no hecho todavía.

La coexistencia terminó dentro de cada aplicación

En 1987, RFC 1031 seguía describiendo la migración de MILNET en tres estados simultáneos: solo tabla, mezcla de tabla y DNS, y solo DNS. Un sistema podía convertir Telnet y FTP antes que el correo o adoptar el orden contrario. La unidad administrativa del host no implicaba una única etapa técnica.

El texto decía que la mayoría de los hosts seguía usando únicamente la tabla. Algunos sistemas antiguos o inmodificables quizá nunca migrarían. Cuando terminara la tabla común, tendrían que obtener un equivalente por acuerdo bilateral, depósito comunitario o mantenimiento local. La excepción compraba continuidad a costa de crear otra autoridad de datos.

RFC 1034 registró después el problema de escala de HOSTS.TXT y describió interfaces de resolución que imitaban la vieja función. Esa compatibilidad facilitaba el cambio de backend, pero impedía deducirlo a partir del comportamiento visible de la aplicación.

RFC 1401 reprodujo correspondencia de 1992 en la que el IAB consideraba incompleta la transición de MILNET y vinculaba las bases no sincronizadas con fallos de alcance. Es una intervención institucional, no un censo cuantitativo. Aun así, demuestra que la rama separada de la transición seguía abierta años después.

Fuentes y límites

El análisis usa RFC 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 y 1401. Esos documentos prueban diseños, decisiones, fechas y observaciones atribuidas. No prueban una fecha universal de adopción, cumplimiento de todos los sitios, autenticación, alcance actual ni comportamiento de productos presentes.