Resumen

  • RFC 849 distinguió la versión vigente en SRI-NIC de las copias locales que los sitios utilizaban realmente para resolver nombres.
  • Su solución preferida combinó un envío rápido de un solo intento con una consulta de versión al arrancar y una comprobación periódica para reparar entregas perdidas.

La copia más peligrosa no siempre es la que produce un error. Puede ser la que sigue funcionando con normalidad, responde a todas las llamadas y no ofrece ninguna señal de que pertenece a una edición anterior.

Eso podía ocurrir con HOSTS.TXT. El NIC modificaba el archivo maestro, pero una máquina fuera de servicio no recibía el cambio. Al volver, su sistema local continuaba usando el mapa que tenía instalado. El registro y la máquina eran coherentes consigo mismos; eran incoherentes entre sí.

Mark Crispin dedicó RFC 849, Suggestions for Improved Host Table Distribution, a ese intervalo. La publicó en mayo de 1983 y advirtió que ninguna de sus propuestas se presentaba como norma. Era una petición de comentarios en sentido literal. Por tanto, el documento no demuestra que se desplegara el mecanismo descrito. Sí demuestra que la comunidad técnica ya podía separar la corrección del archivo maestro de la frescura operacional de sus copias.

La tabla central resolvía autoría, no llegada

RFC 608 había propuesto que el NIC mantuviera una fuente y generara desde ella un archivo ASCII actualizado con nombres, direcciones y atributos. El proceso se ejecutaría periódicamente, cada semana o cuando hiciera falta. El resultado, <NETINFO>HOSTS.TXT, quedaría disponible por FTP.

Así se evitaba que cada sitio inventara su propia fuente autorizada. No se evitaba que cada sitio descargara en momentos diferentes.

RFC 810 modernizó la tabla en 1982 para incluir redes, pasarelas, hosts, sistemas operativos e información de protocolos. Permitía obtenerla mediante FTP anónimo en SRI-NIC o mediante el Host Name Server. También hacía responsable al usuario de traducirla al formato que necesitara localmente.

Ese trabajo posterior a la descarga impide tratar “el archivo” como un único estado. Existían el original publicado, la transferencia recibida, la conversión local y la base que el resolvedor tenía activa. Una transición podía completarse y la siguiente no.

RFC 811 añadió un servicio en el puerto TCP 101. HNAME buscaba por nombre, HADDR por dirección y ALL devolvía la tabla completa entre las marcas BEGIN y END. El servicio daba acceso en línea a los datos del NIC. No ofrecía una respuesta barata a otra pregunta: ¿mi copia ya instalada es la misma que la actual?

Sin identidad de versión, tanto esperar como descargar era una apuesta

Crispin partía de una limitación práctica. Los sitios conservaban HOSTS.TXT porque SRI-NIC no se consideraba suficientemente fiable para ser el único servicio de nombres disponible en todo momento. El NIC facilitaba el volcado completo y el acceso por FTP, pero alguien tenía que enterarse de que había una edición nueva. Según su experiencia, los cambios no siempre se anunciaban con cuidado.

La falta de comparación automática generaba dos comportamientos malos. Un administrador podía no recuperar un cambio y quedarse atrás. También podía transferir de nuevo exactamente la edición que ya usaba. El primer caso desperdiciaba frescura; el segundo, recursos.

RFC 849 propuso que el NIC informara de la “versión” actual. En Tenex y TOPS-20, el número de generación de archivo era una elección natural. Crispin ya guardaba SYSTEM:HOSTS.TXT con la misma generación que la copia del NIC y miraba de vez en cuando si el número remoto había cambiado. Quería convertir esa rutina en protocolo.

Un número de generación no certifica el contenido. No demuestra que la conversión terminó ni que el resolvedor abrió el fichero nuevo. Su afirmación es más limitada: esta edición es igual o distinta de aquella.

Esa evidencia mínima evita mover todo el conjunto de datos solo para descubrir que no cambió. También hace visible una copia vieja antes de que un fallo de resolución la delate. La observación decide si el transporte merece comenzar.

Un envío inmediato acumulaba ausencias en el centro

La primera propuesta era un protocolo de envío desde el NIC. Cada sitio ejecutaría un proceso que escuchara en un puerto registrado y aceptara actualizaciones procedentes de determinados sitios “trusted”, en especial SRI-NIC. Si el host receptor estaba encendido, el cambio podía llegar casi de inmediato.

La excepción define el coste. Para completar un sistema basado únicamente en push, el NIC tendría que recordar qué receptores estaban caídos y reintentarlos después. Junto al registro de nombres aparecería otra base: suscriptores, intentos, disponibilidad y obligaciones pendientes. La autoridad central pasaría a conservar la historia de las ausencias locales.

RFC 849 añadió una suma de comprobación para saber que el registro actualizado había llegado completo e intacto. No conviene ampliar esa frase. El texto no diseñó autenticación criptográfica del emisor, no afirmó resistencia a una sustitución maliciosa y no validó la verdad de las entradas. Integridad de transporte, autoridad de origen, corrección semántica e instalación eran afirmaciones diferentes.

El correo ocultaba trabajo detrás de una entrega

La tercera alternativa consistía en enviar la tabla por correo a una lista de receptores y dejar que cada sitio estableciera su procedimiento. Era fácil para el NIC, pero Crispin consideraba que el correo servía mal para distribuir archivos grandes a muchos destinos, sobre todo cuando el fichero seguiría creciendo.

Además, la aceptación de un mensaje no activaba una tabla. Faltaban la cola, el buzón, la extracción, la conversión y el cambio de estado de los programas. El transporte podía registrar “entregado” mientras el servicio local permanecía en la versión anterior.

La cuarta propuesta usaba la vuelta de la máquina como señal

La solución que Crispin prefirió mezclaba la primera y la segunda. El NIC enviaría la actualización una vez a los hosts registrados. No cargaría con reintentos ilimitados. Cada sitio consultaría al NIC como parte del arranque del sistema y recuperaría la tabla si existía una edición nueva. Una consulta periódica —por ejemplo diaria— serviría como respaldo.

El arranque era un buen momento porque revelaba precisamente la condición que el push no podía observar desde fuera: el receptor había vuelto. La máquina que se perdió el aviso durante su apagado revisaba su propio estado al reincorporarse. La consulta diaria cubría equipos que no habían recibido la actualización ni se habían reiniciado.

La consulta de versión mantenía barato ese camino de reparación. El NIC no tenía que recordar indefinidamente quién estuvo ausente; el sitio no tenía que descargar una tabla idéntica en cada comprobación. La ruta rápida y la ruta de recuperación compartían la misma fuente, pero no la misma obligación.

El esquema no eliminaba el retraso. El NIC podía ser inaccesible durante el arranque. La descarga podía cortarse, el control de integridad fallar, la conversión detenerse o el sistema conservar la edición anterior. La mejora consistía en que cada resultado tenía un nombre y una acción siguiente. “Actualizado” dejaba de borrar la topología del fallo.

Una base distribuida tampoco actualiza todo a la vez

RFC 881, de noviembre de 1983, todavía describía a casi todos los hosts de Internet usando alguna tabla basada en el maestro HOSTS.TXT del NIC. Su plan para los nombres de dominio contemplaba un periodo de convivencia.

RFC 882 diagnosticó después que el tamaño de la tabla global, y especialmente su frecuencia de cambio, se acercaban al límite de lo manejable. La respuesta sería una base distribuida. RFC 883 dividió el espacio entre servidores, separó datos autoritativos de datos en caché y estableció refrescos periódicos. Reconoció expresamente que una modificación del maestro no actualizaba las copias de inmediato, sino que iba atravesando el sistema de forma gradual.

Eso no convierte RFC 849 en un anteproyecto implantado por DNS. Sus propuestas no eran estándar y los documentos de dominio cambiaban la unidad de autoridad, las consultas y el mantenimiento. La conexión válida es operacional: toda copia tiene una versión, una edad y una vía de recuperación. Distribuir no equivale a sincronizar instantáneamente.

La realidad local empieza donde terminó la última transición

El registro autorizado podía expresar cuál era la asignación vigente de nombre y dirección. No podía modificar con una declaración a una máquina apagada. El aviso no hacía la conversión. La suma de comprobación no activaba la base. El número de versión no obligaba al resolvedor a leerla.

RFC 849 permite auditar la actualización como una secuencia: edición maestra, intento de aviso, bytes recibidos, integridad aceptada, conversión terminada, estado activo y recuperación posterior. Si una organización utiliza una sola marca verde para todos esos pasos, vuelve a crear el problema que el documento separó.

En el tránsito histórico entre una tabla mundial y un servicio de nombres distribuido, Crispin formuló una idea que sigue siendo incómoda. Publicar ocurre en el origen. Estar al día es una condición que debe demostrarse donde se usan los datos. El archivo maestro podía vivir en el presente y la red, todavía, en el pasado.

Fuentes