Resumen

  • ZONE, el programa descrito en RFC 1296, mantenía una lista de dominios y servidores, verificaba mediante SOA que un servidor contactado era autoritativo y después solicitaba AXFR. Con los registros recibidos construía una tabla; para el estudio, un host era un agrupamiento de nombre(s) y dirección(es) IP descubiertos en DNS.
  • Las transferencias rechazadas o abandonadas y los hosts no registrados en DNS dejaban observaciones fuera del conjunto. Entradas mal formadas, servidores no autoritativos y nombres antiguos retenidos durante un cambio podían añadir observaciones o duplicarlas. Tras revisión manual, el memo describió el resultado como número mínimo de hosts, no como cifra real.

El argumento más valioso de RFC 1296, Internet Growth (1981-1991) no está en la curva de crecimiento. Está en la negativa a permitir que una consulta a un árbol de nombres responda por sí sola cuánto era Internet. Mark Lottor separó el acto de obtener registros del acto de definir una población. Entre ambos dejó una serie de decisiones visibles: a quién preguntar, qué servidor considerar autoritativo, qué transferencia aceptar, qué campos guardar, cómo agruparlos y cómo interpretar los errores que quedaban.

ZONE significa Zealot Of Name Edification. El programa había sido escrito en 1986 para acompañar la transición desde la host table hacia DNS: podía recorrer el árbol y armar una tabla de hosts con lo que recogía, útil en teoría para sitios aún no migrados. No acabó cumpliendo ese papel de transición. Se volvió una herramienta para extraer estadísticas sobre el tamaño del sistema de dominios y de Internet. Ese cambio de uso exige prudencia: una tabla elaborada para fines de recolección no se vuelve automáticamente una lista completa de seres o máquinas que pertenecen a un conjunto.

Un servidor autoritativo no era un host alcanzable

La mecánica de ZONE era más cuidadosa que una búsqueda superficial. Conservaba una lista de dominios y de sus servidores, junto con una marca que indicaba si la información del dominio había sido cargada satisfactoriamente desde alguno de ellos. Por otro problema de BIND, debía empezar con una lista de dominios de nivel superior y sus servidores de nombres. Para cada dominio que aún no había sido transferido, intentaba conectar con un servidor mediante TCP. Primero enviaba una consulta Start of Authority, SOA, para asegurarse de que el servidor era autoritativo para el dominio solicitado.

Sólo entonces enviaba AXFR para pedir los registros de recursos de la zona.

Al recibir un NS, incorporaba el dominio y el servidor citados a la lista de trabajo. Al recibir A, CNAME, HINFO o MX, añadía los datos a una tabla de información de hosts en memoria. La caminata terminaba cuando había recorrido la lista completa sin obtener información nueva; después volcaba la tabla a un archivo con formato HOSTS.TXT. Cada paso tiene un objeto propio. La respuesta SOA se relaciona con la base para consultar a ese servidor sobre ese dominio. AXFR se relaciona con registros que el colector logró recibir. La tabla refleja una regla de procesamiento aplicada a esos registros.

Ninguna de estas observaciones equivale a una prueba de accesibilidad directa. Una respuesta DNS no indica necesariamente que la máquina detrás de un nombre acepta tráfico desde Internet. Un servidor que respondió como autoritativo no certifica que todos los registros transferidos describan hosts vigentes. Un registro añadido a una tabla no demuestra que la organización correspondiente entre en una definición de Internet. Y una tabla que se estabiliza tras una vuelta sin novedades no demuestra que fuera del alcance del programa no haya más nada.

La distinción importa porque la palabra “host” parecía esconder varias preguntas. Para el estudio, RFC 1296 definió un host como un agrupamiento [nombre(s), dirección(es)-IP] encontrado en DNS. Así, varias denominaciones o direcciones no convertían automáticamente una misma unidad en varios hosts. Era una regla de conteo, no una prueba de identidad física. El propio texto dice que no tiene en cuenta la accesibilidad directa. Definir una unidad evita cierta forma de doble conteo; no decide qué máquinas están encendidas, qué redes admiten conexiones o quién debe figurar en una población.

La ausencia tenía un signo, no una cifra conocida

El límite de la colección comienza con lo que ZONE no podía obtener. Algunos sitios no permitían transferencias de zona desde sus servidores. El programa acababa abandonando un dominio tras demasiados fallos. En la ejecución del 1 de enero de 1992, alrededor de 800 de 17.000 dominios no pudieron transferirse. Además, el memo supone que no todos los hosts de Internet estaban registrados en un servidor de dominio. Ambas condiciones quitan del conjunto posibles registros que el método habría contado si hubiera podido verlos. Por ello, RFC 1296 dice que las estadísticas recogidas quedan por debajo de las cantidades reales.

Esa frase no estima el tamaño de la sombra. No permite asignar un número de hosts a cada transferencia fallida ni declarar que todo host sin entrada DNS era accesible. Conserva únicamente una dirección de error bajo los supuestos descritos: si el instrumento cuenta aquello que recibe de zonas transferibles, no puede transformar lo que no recibió en presencia observada. Llamar al resultado un mínimo evita la pretensión de convertir una ausencia conocida en una corrección inventada.

La historia previa del propio instrumento refuerza el punto. DNS se introdujo alrededor de 1984 y necesitó casi cuatro años para quedar plenamente implementado; para entonces, muchos hosts ya no aparecían en la antigua Host Table de SRI-NIC. Las primeras versiones de BIND tuvieron problemas importantes con las transferencias de zona, de modo que ZONE no pudo recopilar datos DNS completos hasta aproximadamente 1988. La obtención pasó de horas a una semana y la tabla se acercó a 50 megabytes.

En el modo citado por el memo, el programa guardaba sólo nombres de hosts y direcciones IP, ignoraba datos de protocolo, de información de host y MX, y luego usaba utilidades como sort, uniq y grep para producir las estadísticas. SRI lo ejecutaba cada tres meses.

Una semana de recolección no es un instante común para todos los registros. Una ejecución trimestral no es una lectura permanente. Ignorar un tipo de dato para reducir volumen no permite recuperarlo después como si se hubiese observado. El total depende de la fecha, del conjunto de arranque, de la disponibilidad de servidores, de las transferencias completadas y de la regla de consolidación. El método no es una explicación añadida al número: es parte del significado del número.

Los registros sobrantes no convirtieron la tabla en un censo

RFC 1296 describe también errores que empujan en la dirección contraria. Una revisión manual encontró muchas entradas aleatorias en DNS. Datos mal formados podían producir registros falsos de servidores o hosts. A veces un servidor no era autoritativo para el dominio al que aparecía asociado. En otras ocasiones se renombraba un dominio entero y se dejaban sus entradas antiguas durante un período de transición, con lo cual cada host podía contarse dos veces. Son problemas de adición o repetición dentro de los datos recogidos.

La conclusión del documento no borra ese hecho. Lo compara con los elementos perdidos. El escaneo manual indicó que las entradas adicionales eran insignificantes frente a las ausencias expuestas antes; por eso los datos de ZONE podían verse como número mínimo de hosts y no como las cifras reales. No es una ley que diga que cualquier recorrido DNS subestima siempre. Es una evaluación documentada para esa colección, esas fuentes de error y esa revisión.

No conviene permitir que una operación de deduplicación lleve más autoridad de la que posee. Un algoritmo puede agrupar nombres y direcciones conforme a una regla. Puede evitar que las múltiples etiquetas conocidas de una unidad sumen varias veces. No puede saber cuántos hosts había tras un AXFR rechazado, si una entrada residual representaba aún una máquina o si la dirección anunciada era utilizable desde un punto de la red. El paso de registros a población requiere una decisión de alcance que la tabla no ejecuta sola.

Encontrar un nombre no resolvía qué contaba como Internet

El RFC formula el problema de alcance sin disfrazarlo de detalle técnico. Hallar entradas de hosts en DNS no implica que el host sea alcanzable desde Internet. Algunas empresas mantenían gateways de correo entre Internet y sus redes locales, impidiendo el acceso directo; unas anunciaban todos sus hosts y otras sólo el gateway. ¿Cuáles debían contar? Además, algunos dominios DNS consistían sólo en entradas MX que reenviaban correo para sitios fuera de Internet, como Usenet. ¿Pertenecían a un estudio sobre el tamaño de Internet?

Son preguntas sobre el objeto, no sobre la precisión de un contador. Un nombre visible puede demostrar que un registro fue publicado. Una transferencia completada puede demostrar que el colector recibió una zona. Una regla de agrupamiento puede demostrar cómo se evitó un doble conteo definido. Para afirmar acceso directo, pertenencia institucional, población económica o tamaño total hay que aportar otra definición, otra medición o otra autoridad. Una curva no adquiere esos predicados porque sus puntos estén ordenados.

El costo de ZONE añade una dimensión operativa. Descargar información de todos los dominios generaba tráfico y añadía carga de CPU a cada servidor contactado. El memo sugiere que un esfuerzo organizado podría usar un único programa en intervalos regulares para evitar el problema de muchos recolectores. Es una propuesta sobre coordinación y carga, no evidencia de que hubiera un censor central autorizado para interrogar sin límite ni para definir por sí solo el conjunto observado.

Más frecuencia no borraba la diferencia de categorías

En sus asuntos futuros, el RFC describe ZONE ejecutándose en un DECsystem-20 y escrito en ensamblador. El espacio de direcciones se acercaba al límite; el programa reunía los datos en memoria antes de volcarlos para poder relacionar apodos con nombres oficiales, incluso cuando un apodo pertenecía a otro dominio. Lottor propuso una nueva arquitectura: datos en disco, transferencias múltiples en paralelo y un ciclo continuo de semanas a un mes que actualizara una base local por dominio. Era una propuesta de diseño, no la prueba de que esa arquitectura se hubiese implementado ni de que una base continua hubiese vuelto completa la estadística.

Recoger más seguido puede reducir la edad de ciertas observaciones. Paralelizar puede acortar el período durante el que una caminata está en curso. Guardar datos en disco puede limitar una pérdida tras un fallo. Ninguna mejora convierte un registro en prueba de alcance, una agrupación de nombres en identidad estable o una cota observada en una cantidad total. El valor histórico del RFC consiste precisamente en mantener esas categorías separadas.

Fuentes y límites de la evidencia

La única fuente es RFC 1296. Sustenta el estatus Informational de enero de 1992, las series procedentes de la Host Table y de ZONE, el orden SOA/AXFR, los tipos de registros, la definición de host, los fallos de transferencia, las entradas residuales, la conclusión de mínimo, las preguntas de alcance, las cifras de enero de 1992, el costo de recolección y la propuesta futura. No demuestra una población DNS actual, una transferencia AXFR viva, una propiedad actual de BIND, una política vigente de enumeración, el alcance de un host, la pertenencia de una organización, una postura de seguridad, un recolector posterior desplegado ni un resultado posterior.