Resumen

  • El correo de Jon Postel del 28 de enero de 1998 pidió a los servidores secundarios de la raíz que obtuvieran la zona desde DNSROOT.IANA.ORG; señaló que la copia sería idéntica a la de A-root y que las reglas para modificar la zona raíz no cambiarían.
  • El 3 de febrero, Postel dio por terminada la verificación y pidió a los operadores que volvieran a A-root. Los mensajes documentan solicitudes, no la configuración de cada operador.

Un servicio DNS, dos tipos de tráfico

Un resolutor que busca un nombre y un servidor secundario que actualiza su copia de una zona realizan tareas diferentes. El resolutor envía una consulta DNS a un servidor autoritativo. El secundario obtiene, mediante una relación de transferencia independiente, los datos que luego servirá. Ambos papeles pueden convivir en una máquina, pero no son la misma operación de red.

Esa distinción ya formaba parte del diseño operativo del DNS. La RFC 1034 describe un servidor primario que coordina los cambios y servidores secundarios que consultan el número de serie SOA y obtienen una copia actualizada cuando este avanza. La RFC 1035 define AXFR como una solicitud para transferir una zona completa. Un resolutor que solicita un registro no está pidiendo un AXFR de la zona raíz.

En enero de 1998, una misma máquina podía responder consultas como servidor raíz y servir como fuente para que otros servidores raíz actualizaran sus datos. La petición de Postel se refería a esta segunda función. No pedía que los resolutores de Internet enviaran sus consultas habituales al servidor de IANA.

El correo delimitó una solicitud de transferencia

El correo conservado está fechado el 28 de enero de 1998 y lleva el asunto «root zone secondary service». Postel pidió a los secundarios del dominio raíz que obtuvieran la zona «por transferencia de zona» directamente de DNSROOT.IANA.ORG, en 198.32.1.98. El mensaje decía que los datos serían una copia exacta de la zona disponible entonces en A.ROOT-SERVERS.NET. También afirmaba que no se modificaría ninguna política ni procedimiento para cambiar la zona raíz.

La frase que limita el alcance importa tanto como el nombre del servidor. La instrucción se aplicaba solo a la zona raíz. Los operadores que ofrecían servicio secundario para otras zonas, incluidos los dominios de nivel superior, debían seguir usando sus fuentes habituales. El correo describía un cambio propuesto en una ruta de replicación, no una redirección de todo el DNS ni el reemplazo de todas las relaciones ascendentes.

El mismo archivo conserva una declaración pública de Postel que describía el ensayo como una reorganización del flujo de información de la zona raíz. Dijo que el contenido seguiría decidiéndose y preparándose de la misma forma. Son dos afirmaciones distintas: los datos debían seguir siendo los mismos y otro servidor de IANA debía probarse como origen de las copias secundarias. No aportan la configuración de cada servidor ni el resultado de todas las transferencias.

El ensayo coexistía con otra cuestión administrativa: quién podía autorizar cambios en los registros. El mensaje de enero dejaba intactos esos procedimientos. Una fuente de transferencia puede entregar una copia sin convertirse en autora de todos sus registros. Los mensajes disponibles no muestran que IANA empezara a editar o publicar una nueva versión de la zona raíz durante la prueba.

Cambiar el origen no redirige las consultas

Es fácil confundir el episodio porque A-root ocupaba dos posiciones: respondía consultas como uno de los servidores raíz y se describía como el origen establecido del archivo de zona. Ambas funciones se asociaban a una misma máquina, pero el protocolo de transferencia permitía separar el origen de distribución de los servidores que respondían a los resolutores.

La consecuencia puede formularse como una inferencia condicional. Si un servidor secundario obtiene una copia idéntica y la carga correctamente, cambiar el servidor que entrega esa copia no altera por sí solo los registros que recibe un resolutor. El correo conservado dice que se pretendía que la copia de IANA fuera idéntica; no ofrece una comparación de cada servidor ni mediciones de consultas que demuestren que la condición se cumplió en todas partes.

En una audiencia posterior ante el Congreso, NSI afirmó que actuaba como servidor raíz «primario» al amparo de su acuerdo con el Gobierno, que no había contratos entre los trece operadores y que los demás no estaban obligados a descargar el archivo a diario. Ese testimonio ayuda a entender que «primario» describía un arreglo operativo, no una orden contractual a cada servidor secundario. No establece quién aceptó la petición de Postel en 1998.

La solicitud de retorno acota el episodio

El 3 de febrero, en un mensaje titulado «root zone transfer verification completed», Postel declaró terminado el ensayo y pidió a los operadores que volvieran a obtener la zona de A-root. La petición seguía limitada a la zona raíz. La historia posterior RSSAC-023v2 dice que Postel pidió a Jim Koda y Paul Vixie que crearan y operaran un servidor raíz primario en ISI para la prueba, notificó a varios operadores para que obtuvieran la zona de allí y días después pidió que todos volvieran al servidor primario anterior.

Ese relato posterior corrobora la secuencia y habla de «varios» operadores. Ni esa historia ni los correos conservados incluyen la lista de los operadores que cambiaron la configuración, un registro AXFR completo o comprobantes del momento en que cada uno volvió a A-root. Una petición demuestra intención; no prueba que todos los destinatarios la ejecutaran.

El registro tampoco permite medir el impacto en el servicio. La declaración de Postel expresaba mucha confianza en que la transición no interrumpiría el servicio, pero una expectativa no es telemetría. Los mensajes no vienen acompañados de series de consultas, registros de interrupciones ni una comparación independiente de todas las copias activas.

Fuentes

Los registros más próximos al hecho son las copias conservadas de la petición de Postel del 28 de enero y el mensaje de retorno del 3 de febrero. El archivo reproduce un bloque de firma PGP, cuya validez este artículo no ha verificado de forma independiente. La retrospectiva de RSSAC aporta un relato institucional posterior. Las RFC 1034 y 1035 definen el mecanismo de transferencia, no la configuración de cada operador en 1998. La versión de NSI consta en una transcripción de una audiencia del Comité Judicial de la Cámara de Representantes y se atribuye a la empresa.