Resumen

  • El 11 de julio de 1997, un operador informó que un resolvedor asociaba www.internic.net con una dirección de AlterNIC y marcaba el registro como dato adicional.
  • El episodio unió una disputa sobre quién podía registrar dominios comerciales con un fallo técnico distinto: un resolvedor confió en una asociación y la conservó como respuesta.

Una dirección web, dos autoridades

AlterNIC impugnaba el papel de Network Solutions en el registro de dominios comerciales de nivel superior. La discusión era quién podía añadir nombres como .com y .net, y bajo qué reglas. Sin embargo, el registro que mejor muestra el mecanismo es mucho más acotado. El 11 de julio de 1997, Kevin Brintnall, operador de redes, publicó en NANOG una consulta y el volcado de caché del servidor de nombres de Visi Internet. www.internic.net resolvía a 207.51.48.15; una consulta de esa dirección la identificó como aragorn.alternic.net.

El volcado marcaba el registro de dirección inesperado como addtnl, abreviatura de datos adicionales en la respuesta DNS. Brintnall también escribió que la caché de raíz de su resolvedor no contenía indicios de AlterNIC. En ese caso, el usuario no había seleccionado una raíz alternativa. Un dato encontrado durante la resolución recursiva había alterado lo que ese resolvedor devolvía para el servidor web de InterNIC.

La diferencia importa porque los nombres del conflicto cumplían funciones distintas. La zona raíz delega los dominios de nivel superior. Un registrador acepta inscripciones bajo un dominio de nivel superior. Un resolvedor recursivo sigue las delegaciones DNS y conserva registros en caché para responder localmente a consultas posteriores. El desafío político de AlterNIC apuntaba a las reglas del sistema de nombres; la evidencia de Brintnall muestra una asociación almacenada por un resolvedor. No muestra que AlterNIC hubiera reescrito la zona raíz pública.

Lo que demuestra la caché —y lo que no

El mensaje original de NANOG es excepcionalmente concreto para una historia del DNS. Incluye la dirección del servidor, el registro A devuelto, la dirección de origen guardada y la anotación de procedencia del resolvedor. La dirección de origen correspondía a un host de AlterNIC. Esa marca addtnl concuerda con la explicación posterior de WIRED: las respuestas DNS podían llevar registros adicionales, y un resolvedor que confiara demasiado en ellos podía guardar uno para un nombre distinto de la consulta original.

La evidencia establece una respuesta errónea en una caché. No cuenta todos los resolvedores afectados, no prueba que cada visitante fuera redirigido ni demuestra que AlterNIC controlara los servidores raíz públicos. Algunos relatos contemporáneos describieron la redirección como si afectara a “Internet”; el registro técnico acota esa afirmación: un resolvedor ofreció otro destino para un nombre web concreto. El valor 146598 del volcado es un campo del registro, no la duración de una caída global ni una cifra de usuarios.

El contexto político sí era real. The Washington Post informó que Network Solutions tenía, bajo un acuerdo con la National Science Foundation, derechos exclusivos de registro para .com, .org y .net. AlterNIC se presentaba como un registro competidor y objetaba lo que su operador describía como la pretensión de NSI de ser dueña de esos nombres. Ese papel contractual era importante, pero no equivalía a poseer todos los nombres ni toda la raíz de Internet. Redirigir a los visitantes hacia AlterNIC hizo visible el reclamo; no resolvió quién tenía autoridad legítima sobre el espacio público de nombres.

Un incidente de caché no era una decisión de política

La respuesta pasó por el software y la operación. En agosto de 1997, el aviso de CERT sobre BIND describía el envenenamiento de caché como datos de un servidor de nombres remoto que otro servidor guardaba y ofrecía a los programas cliente. Indicaba que la vulnerabilidad se había corregido en BIND 4.9.6 y recomendaba una ruta de actualización que incluía BIND 8.1.1. El aviso trataba una clase de comportamiento de los resolvedores, no solo el caso de AlterNIC.

Publicado en julio de 1997, el RFC 2181 coloca la información adicional entre los datos DNS menos confiables e indica que los registros adicionales no autenticados no deberían devolverse después como respuestas. El documento aclara cómo tratar esos datos; las fuentes disponibles no prueban que se redactara a raíz de este episodio. Tampoco la publicación de un estándar demuestra que los operadores hubieran actualizado o configurado todos sus resolvedores.

El debate estadounidense sobre nombres de dominio siguió su propio curso. El Departamento de Comercio abrió una consulta pública en julio de 1997; el Green Paper, el White Paper y la creación de ICANN llegaron en 1998. La cronología de Internet Society registra esa secuencia, pero no atribuye su causa a la redirección de AlterNIC. En 2000, el IAB sostuvo después, en el RFC 2826, que el DNS público necesitaba una raíz única para conservar la coherencia de los nombres. Esa es una posición institucional posterior, no un análisis forense de la caché de Brintnall.

El episodio pertenece, por tanto, a dos historias a la vez: la protesta contra un papel concentrado de registro y la demostración operativa de que un resolvedor local podía convertir datos adicionales dudosos en un destino diferente. La primera pregunta era quién debía fijar las reglas de los nombres. La segunda, qué datos debía confiar un resolvedor. Confundirlas convertiría una línea de caché en una transferencia de la zona raíz y una redirección visible en prueba de control universal.

Fuentes