Los primeros registros de contacto del WHOIS y la deriva

Resumen

RFC 812 definió NICNAME/WHOIS en 1982 como un directorio legible por humanos para localizar usuarios de la red. RFC 954 amplió la población susceptible de búsqueda en 1985, pero ninguna de las dos especificaciones convirtió un nombre, handle, organización, host o campo de contacto devuelto en prueba de titularidad legal o control operativo actual.
Cuatro familias de registros se desarrollaron por caminos distintos: entradas de directorio personal, contactos de host y red DDN, registros de dominio y sus visualizaciones WHOIS públicas, y registros de recursos numéricos. Su interfaz de consulta común no las convirtió en un único sistema continuo de titularidad.
Un incidente de diciembre de 1990 proporciona evidencia directa de dependencia operativa y atribución limitada de responsabilidad: un registro de red del NIC de DDN orientó a los sitios afectados y al CERT/CC hacia una institución, mientras que los registros, la administración local y la investigación directa siguieron siendo necesarios para identificar la máquina y el operador.
Una disputa de febrero de 1996 sobre el registro de CLUE.COM proporciona un caso completo de legitimación administrativa en el procedimiento de registro subyacente de Network Solutions. El registrante registrado recibió notificación, impugnó el cambio amenazado y obtuvo una medida cautelar que preservó el registro. El expediente judicial no muestra que una consulta WHOIS pública creara de forma independiente esa legitimación.
El litigio Kremen documenta una colisión diferente en octubre de 1995: Network Solutions modificó su base de datos de registro autoritativa tras recibir una instrucción falsificada, lo que produjo consecuencias prácticas de uso. El WHOIS público podía reflejar el estado alterado, pero las pruebas no muestran que una consulta pública causara el cambio ni confiriera la propiedad.
En 1996, los datos de registro y reasignación de recursos numéricos eran insumos obligatorios para las decisiones de contacto operativo y asignación adicional. RFC 2050, sin embargo, exigía documentación de respaldo, protegía el material sensible designado por el solicitante y proporcionaba revisión a través de la jerarquía del registro. Ningún caso examinado aquí muestra que una fila pública de recursos numéricos decidiera por sí sola la titularidad.

Leer el esquema antes de atribuirle autoridad

Las primeras especificaciones se abordan mejor como arqueología de esquemas. Antes de preguntar cuándo el WHOIS se convirtió en evidencia, es necesario preguntar qué se diseñó que contuvieran sus registros, quién se esperaba que apareciera y qué pretendía hacer una respuesta.

RFC 812, escrito por Ken Harrenstien y Vic White y fechado el 1 de marzo de 1982, describió NICNAME/WHOIS como un servidor de consulta y respuesta transaccional en la máquina SRI-NIC. Proporcionó un directorio para toda la red a los usuarios de ARPANET en nombre de la Defense Communications Agency. Un usuario enviaba una línea de comando, recibía una respuesta y se desconectaba. La respuesta estaba destinada a un lector humano y no a una interpretación automatizada.

La población prevista era personal. La Defense Communications Agency solicitaba el registro de cada individuo que tuviera un directorio en un host de ARPANET y pudiera transmitir tráfico a través de la red. La información de registro incluía un nombre, detalles de contacto institucional o postal, un contacto telefónico y un buzón de red. Esos campos muestran cuánta información de contacto personal exponía el servicio, pero no es necesario reproducir entradas reales. Su función original era el descubrimiento.

RFC 954, redactada por K. Harrenstien, M. K. Stahl y E. J. Feinler y fechada en octubre de 1985, mantuvo el puerto 43 y la arquitectura de una consulta, una respuesta. Describió el servicio como un directorio para usuarios de Internet y reiteró que su salida era legible por humanos. Su población susceptible de búsqueda era más amplia: personas y buzones registrados, organizaciones de red, nodos DDN y hosts asociados, y usuarios de acceso terminal MILNET registrados.

Los campos ya desempeñaban funciones diferentes. Un nombre ayudaba a un usuario a encontrar a una persona. Un handle distinguía a esa persona de otras con nombres similares y actuaba como referencia reutilizable en la base de datos. Una organización proporcionaba una afiliación. Los campos de buzón y teléfono ofrecían canales de comunicación. Las asociaciones de host y nodo ubicaban a una persona dentro de las operaciones de red.

Ninguna de esas proposiciones, por sí misma, decía que la persona siguiera empleada por la organización, pudiera vincularla, controlara todos los sistemas asociados o poseyera un derecho legal o contractual sobre un identificador de Internet.

La diferencia entre un directorio y un sistema probatorio radica en parte en lo que rodea a los campos mostrados. Un sistema probatorio suscita preguntas sobre la procedencia, la autoridad para presentar, la autenticación, las fechas de vigencia, las versiones reemplazadas, las correcciones impugnadas, los motivos del cambio y la revisión. RFC 812 y RFC 954 especificaban el servicio de consulta pública. No especificaban una pista de auditoría pública que respondiera a esas preguntas.

Esa omisión no debe exagerarse. Un documento de protocolo no es un manual de operaciones completo. La ausencia de una regla de autenticación en la especificación de consulta no prueba que el personal del NIC aceptara cada actualización sin correspondencia, verificaciones telefónicas, relaciones establecidas con el sitio o criterio humano. Establece algo más limitado: al destinatario de la respuesta pública no se le proporcionaba una relación normalizada de quién suministró cada campo, cómo se había probado la autoridad de esa persona, qué valores anteriores habían sido desplazados o si otra parte cuestionaba el registro actual.

Por lo tanto, cinco componentes deben permanecer separados:

la base de datos de registro o identificación subyacente de la institución;
la respuesta WHOIS pública generada a partir de esa base de datos;
el procedimiento mediante el cual se añadía, modificaba o eliminaba un registro o contacto;
los sistemas operativos asociados con el identificador, incluida la administración de hosts, el enrutamiento y la delegación de DNS;
los contratos, la correspondencia de asignación, los nombramientos organizativos, el consentimiento y los registros legales externos a la base de datos.

Confundir esas capas hace que la consulta pública parezca más poderosa de lo que permite la evidencia histórica. Una respuesta WHOIS podía describir un registro. Una transacción de registro podía modificar la base de datos autoritativa de un registrador. Un cambio operativo separado podía alterar el servicio DNS o el uso de la red. Un tribunal o un registro podía decidir más tarde si la transacción era válida. Eran eventos relacionados, no un solo evento.

La escalera probatoria que se examina aquí es:

conveniencia de directorio -> dependencia operativa -> atribución de responsabilidad -> legitimación administrativa -> inferencia cuasi-titular

Cada escalón ascendente requiere más que una especificación que muestre que existía un campo. Requiere un actor fechado, un registro concreto, una decisión, una fuente de verdad competidora y un resultado observable. Cuando el archivo solo proporciona un procedimiento prescrito, la conclusión debe seguir siendo una expectativa documentada y no un acto de dependencia consumado.

Nombre y handle: el registro de directorio personal

Para qué servían los campos

El campo de nombre respondía a la pregunta más simple: ¿a qué persona se está buscando? El handle hacía que esa respuesta fuera más estable dentro de la base de datos. Un usuario podía buscar de forma amplia y luego seleccionar una entrada concreta por su handle. Otros registros podían apuntar al handle sin reproducir todos los campos de contacto.

Ese fue un logro técnico importante. Los nombres no son únicos, las iniciales varían y las afiliaciones organizativas cambian. Un identificador duradero reducía la ambigüedad dentro de los registros del NIC. Era una prueba sólida de qué fila de la base de datos había seleccionado un usuario.

No era una credencial de identidad. RFC 812 y RFC 954 no describían una prueba documental de identidad, una firma vinculada al handle o una autoridad externa que certificara cada afiliación. Un handle establecía continuidad en la base de datos con mayor claridad que la continuidad en el empleo, las responsabilidades o la capacidad legal de la persona.

El campo de organización era igualmente descriptivo. Ayudaba a distinguir a las personas e indicaba dónde podían ser encontradas. Un registro podía reflejar fielmente una asociación institucional en el momento de su introducción y quedar obsoleto después de un traslado, una reorganización o una salida. El campo no contenía un acuerdo laboral ni una delegación de autoridad.

Presentación, actualización y autenticación

RFC 812 instruía a los individuos a enviar información de registro al NIC. RFC 954 utilizaba un canal de registrador para envíos similares. Las especificaciones identifican el remitente y el destino esperados de la información, pero no describen un protocolo de actualización autenticado separado.

Las especificaciones supervivientes respaldan la siguiente auditoría limitada:

Remitente y procedencia:la información provenía de una persona que buscaba o estaba obligada a registrarse en el NIC.
Autoridad de actualización:los RFC no establecen una regla exhaustiva para decidir quién podía reemplazar un registro de persona existente.
Autenticación:no se especifica ningún método uniforme de verificación de identidad en los documentos de protocolo público.
Corrección:existían canales de asistencia y registro, pero los RFC no describen un procedimiento de corrección impugnada.
Reemplazo y tiempo actual:la respuesta pública representaba la respuesta actual de la base de datos; las especificaciones no definen un historial de fechas de vigencia por registro.
Conservación histórica:no se especifica ninguna secuencia pública de valores anteriores.
Revisión de conflictos:los RFC no explican cómo el personal decidiría entre reclamaciones incompatibles relativas a la misma entrada personal.
Límite de privacidad:la información de contacto personal se exponía deliberadamente porque el descubrimiento personal era el propósito original del servicio.

Desconocido no significa inexistente. La correspondencia interna o la práctica del personal podrían haber proporcionado controles que los RFC no documentaron. La conclusión defendible es que esos controles no formaban parte de la prueba presentada al usuario de la respuesta pública.

El escalón que respalda esta familia

El registro de directorio personal establece directamente la conveniencia de directorio. En 1982 y 1985, el usuario identificado era un participante de ARPANET o DDN que buscaba a una persona, buzón, organización o asociación de host. La decisión era a dónde dirigir un mensaje o una consulta. Las fuentes competidoras incluían un directorio de empleador, una cuenta de host, una lista del sitio, un contacto telefónico o la confirmación de la persona o institución.

Las fuentes examinadas aquí no documentan un caso anterior a 1997 en el que la presencia de un handle personal del NIC, por sí mismo, decidiera la titularidad legal, la autoridad organizativa o el control técnico. La durabilidad del campo podía invitar a esas inferencias, pero su función documentada seguía siendo el descubrimiento.

Host y red: el registro de contacto operativo DDN

La segunda familia conectaba a las personas con las máquinas, las redes y los roles operativos definidos. Aquí el registro comenzó a tener más peso que la mera localización.

De la afiliación al deber de actuar

Un operador remoto que se enfrentaba a un fallo de funcionamiento o a un incidente de seguridad no solo necesitaba el nombre de alguien de una institución. Necesitaba a alguien que pudiera investigar un host, cambiar una configuración, desconectar un sistema o ordenar al personal local que lo hiciera.

Las fuentes contemporáneas definen esa responsabilidad. LaGuía de Administradores de Dominio, RFC 1032, de noviembre de 1987, distinguía al administrador de dominio de los contactos técnicos y de zona. Se esperaba que el administrador coordinara y gestionara el dominio y que tuviera autoridad para actuar o delegar. Los contactos técnicos y de zona mantenían el software y los datos del servidor de nombres y trabajaban con personal técnico de otros lugares.

RFC 1173, de agosto de 1990, describía las responsabilidades de los administradores de host y red. Era explícitamente un resumen informativo de la "tradición oral" de Internet, no una norma del IAB. Incluso con esa limitación, su prueba sustantiva es reveladora. Exigía que las personas responsables de las redes conectadas estuvieran registradas en el NIC correspondiente y se mantuvieran actualizadas. Se esperaba que un administrador de red tuviera acceso a la gestión del sistema o autoridad para deshabilitar, desconectar o dejar de reenviar tráfico de un sistema que se comportara mal. Un administrador de host necesitaba igualmente la autoridad, el acceso y las herramientas necesarias para controlar el host.

Por lo tanto, el registro y la realidad externa estaban vinculados pero no eran idénticos. El registro nombraba a la persona. Los privilegios reales, el acceso físico, la autoridad del empleador y la cooperación local determinaban si esa persona podía desempeñar el rol.

LaGuía de 2011 de los Registros SRI ARC/NICproporciona un mapa retrospectivo de la colección e identifica materiales relativos a Enlaces Técnicos, Administradores de Host, Coordinadores de Sitio de Nodo y otros grupos de contacto. Ayuda a localizar registros relevantes; no se trata como prueba contemporánea de por qué se creó cada rol o exactamente qué autoridad poseía cada titular. Esas proposiciones requieren documentos de la época como RFC 1032, RFC 1173, directivas, materiales de registro e informes operativos.

Un relato fechado de cómo se mantenían los archivos de contacto

Un registro operativo más preciso sobrevive enDescripciones de Tablas y Listas del NIC, un informe final fechado el 5 de abril de 1991. El Centro de Sistemas de Información de Red de SRI International preparó el informe para la Defense Communications Agency bajo el contrato DCA200-90-C-0027, Proyecto SRI ECU 1050, CDRL No. 027. Aparece en la colección del Museo de Historia de la Computación tituladaMateriales de la Defense Communication Agency, 9 de 13.

El informe identifica varios derivados distintos en lugar de un único archivo WHOIS indiferenciado.

La sección 3.1, en la página 7 del informe, describe los archivos de administrador de host de MILNET. Sus datos se extraían de la base de datos WHOIS del NIC. La información inicial provenía de Directivas de Cambio de Red, después de lo cual el Hostmaster del NIC solicitaba correcciones a los Administradores de Host cada mes. El archivo derivado se generaba semanalmente.

La sección 3.7, en la página 10 del informe, describe un archivo que organiza a los administradores de host por dirección de red. También dice que los datos iniciales provenían de Directivas de Cambio de Red y se mantenían actualizados mediante solicitudes mensuales de correcciones en línea. El archivo se generaba semanalmente.

El informe también indica que los archivos y tablas llevaban un número de versión o fecha de última actualización a nivel de archivo. Esto proporcionaba información temporal útil: un usuario podía identificar una generación publicada concreta. No proporcionaba necesariamente un historial público de cada valor anterior para cada contacto.

Para los registros de host y red DDN, la auditoría se vuelve más concreta:

Remitente y procedencia:la información inicial del host podía originarse en Directivas de Cambio de Red; los cambios posteriores provenían de Administradores de Host reconocidos, Coordinadores de Sitio de Nodo o personal de red.
Autoridad de actualización:se esperaba que los titulares de roles presentaran correcciones, y el Hostmaster las solicitaba. El informe no define todas las pruebas utilizadas cuando un nuevo corresponsal afirmaba reemplazar a un titular de rol existente.
Autenticación:un rol establecido y un canal de correspondencia creaban confianza procedimental, pero el informe no describe un sistema uniforme de verificación de identidad o autenticación de mensajes para todas las actualizaciones.
Corrección:las solicitudes mensuales y los envíos voluntarios proporcionaban vías de corrección recurrentes.
Reemplazo y tiempo actual:los archivos regenerados semanalmente y las versiones a nivel de archivo mostraban ciclos de publicación, no necesariamente la fecha efectiva de cada cambio organizativo externo.
Conservación histórica:el informe describe los derivados actuales y su generación. No establece una secuencia pública, completa, por registro, de contactos reemplazados y motivos.
Revisión de conflictos:el Hostmaster ocupaba una posición interpretativa, pero el informe no describe un procedimiento de adjudicación general para reclamantes competidores al mismo rol.
Límite de privacidad:algunos derivados operativos contenían amplios datos personales y de contacto de roles. Esos detalles no se reproducen aquí.

El sistema de mantenimiento era estructurado. No era equivalente a una cadena de pruebas autenticadas inspeccionable públicamente. Un registro actual podía seguir estando desfasado con respecto a un cambio de personal sin que nadie actuara de forma deshonesta.

Dependencia operativa y atribución de responsabilidad en diciembre de 1990

Un incidente real proporciona el movimiento anterior a 1997 más claro más allá del uso prescrito.

En un artículo presentado en el Simposio de Seguridad USENIX de 1992,Alessandro Berni, Paolo Franchi y Joy Marino describieron incidentes de seguridad en Internet en Italia. Su relato afirma que dos sitios observaron intentos de intrusión asociados con una red en Italia y contactaron con el Centro de Coordinación CERT. Durante la respuesta, la base de datos WHOIS del NIC de DDN asociaba la red con la Universidad de Milán.

Los elementos probatorios pueden exponerse sin revelar detalles de contacto históricos:

Fecha:diciembre de 1990, documentada en el artículo de 1992.
Actores:los sitios afectados y CERT/CC.
Registro utilizado:la asociación de red del NIC de DDN y la información de contacto.
Decisión:qué institución debía recibir el informe inicial del incidente y ser instada a investigar antes de que los operadores consideraran aislar la red.
Fuentes de verdad competidoras:registros del sistema y de paquetes, información de enrutamiento, administración real de la máquina implicada, registros institucionales locales y confirmación directa.
Resultado:la consulta identificó una institución relevante e inició el contacto, pero el administrador de la máquina responsable no se estableció de inmediato y la comunicación siguió siendo difícil.

Este caso prueba la dependencia operativa. El registro cambió lo que los respondedores hicieron a continuación: seleccionó una institución con la que contactar.

También respalda una forma limitada de atribución de responsabilidad. La entrada de red asociaba el tráfico observado con una red organizativa y situaba a esa organización en la ruta de respuesta. No identificaba al individuo que realizó la actividad, no localizaba de forma concluyente la máquina específica ni probaba quién tenía la capacidad de detenerla.

Los registros establecían los eventos observados. WHOIS proporcionaba una asociación institucional. La investigación local tenía que conectar el tráfico con una máquina. La autoridad organizativa y el acceso técnico determinaban quién podía actuar. El registro era un puente entre un identificador y una institución, no un sistema de atribución completo.

La evidencia alcanza de forma segura la dependencia operativa y la atribución de responsabilidad. No muestra que una entrada pública de contacto de red confiriera legitimación en un cambio administrativo impugnado o estableciera la titularidad del número de red.

Organización, dominio, contactos y servidores: el registro de dominio

La tercera familia situaba varias proposiciones en un solo registro visible: una organización, un nombre de dominio, contactos diferenciados y servidores de nombres. Su proximidad animó a los usuarios posteriores a leerlas como una sola declaración de control. Históricamente, cada una tenía una base probatoria diferente.

La organización y el dominio

RFC 1032 instruía al administrador de dominio a presentar un cuestionario de registro y lo describía como responsable de mantener actualizados los datos del dominio. Su sección de verificación decía que WHOIS podía utilizarse para revisar la organización asociada a un dominio, el nombre de dominio, los contactos administrativo, técnico y de zona, y los servidores de nombres enumerados.

Esto era más que un descubrimiento personal. Era un uso prescrito de WHOIS para comparar un registro con la configuración de dominio prevista.

Sin embargo, RFC 1032 también aportaba una contraprueba contemporánea a cualquier teoría de titularidad. Decía que el NIC no actuaría como árbitro en disputas locales sobre quién tenía el "derecho" a registrar un dominio. Dichas disputas debían resolverse entre las partes antes del registro. El NIC podía responder preguntas técnicas pero no pretendía adjudicar el derecho subyacente.

Por lo tanto, los campos deben leerse por separado:

Organización:la entidad representada en la solicitud de registro.
Contacto administrativo:la persona responsable de la política o coordinación organizativa.
Contactos técnico y de zona:las personas responsables del funcionamiento del servidor de nombres y los datos relacionados.
Servidores de nombres:los sistemas destinados a responder de forma autoritativa para el dominio.
Visualización WHOIS:la representación legible por humanos que el registrador hace de los hechos registrados.
Delegación DNS:la ubicación operativa del dominio en el sistema de nombres jerárquico.

Una respuesta WHOIS pública podía compararse con una solicitud y un DNS activo. No podía, sin más pruebas, demostrar que el contacto administrativo siguiera poseyendo autoridad corporativa o que la organización tuviera todos los derechos legales implicados por el nombre.

RFC 1032 establece un usuario y una decisión normativos: en noviembre de 1987, se le dijo a un administrador de dominio que inspeccionara WHOIS al comprobar si los datos del dominio estaban correctamente representados. Las fuentes competidoras eran la solicitud presentada, los registros del dominio superior, el DNS activo y los nombramientos organizativos. El RFC no documenta que un administrador concreto hiciera esa comparación y obtuviera un resultado registrado. Prueba la verificación operativa esperada, no un evento de dependencia consumado.

Corrección de dominio en el registro DDN de 1991

El informe de Stahl de abril de 1991 otorga al archivo de contactos de dominio una procedencia específica. La sección 3.8, en la página 10 del informe, dice que el derivadoDOMAIN-CONTACTSextraía información de las solicitudes de registro de dominio procesadas por el Hostmaster del NIC y de las correcciones presentadas por los Administradores de Dominio. Los datos brutos se almacenaban en la base de datos WHOIS del NIC, y el archivo de contactos se generaba semanalmente.

El informe también distingue los contactos administrativo, técnico y de zona. Esos roles no eran intercambiables simplemente porque aparecieran juntos.

El informe respalda una ruta de corrección definida, pero deja otras preguntas abiertas:

un Administrador de Dominio reconocido podía presentar una corrección;
el Hostmaster procesaba la solicitud o corrección de origen;
un nuevo derivado semanal podía exponer el estado actual modificado;
el informe no establece un método de autenticación universal para cada corrección;
no establece que cada usuario público pudiera recuperar todos los contactos reemplazados;
no describe un procedimiento uniforme para adjudicar solicitudes de corrección incompatibles.

Eso es evidencia de mutación gestionada. No es evidencia de que un contacto administrativo mostrado adquiriera autoridad legal simplemente por ser mostrado.

El flujo de trabajo de solicitudes de InterNIC en 1993

RFC 1400, de marzo de 1993, documentó la transición de los servicios de registro no DDN a InterNIC. A partir del 1 de abril de 1993, el WHOIS de InterNIC debía contener información sobre direcciones IP, dominios, números de sistema autónomo y puntos de contacto individuales asociados a nodos activos. La cobertura general de directorio personal dejó de ser la población principal del servicio de registro central.

El documento también describía un proceso de solicitud estructurado. Un solicitante enviaba una plantilla a un buzón de registro automatizado. Un analizador comprobaba la información que podía verificarse mecánicamente, incluidos los conflictos de nombres de dominio, y devolvía un mensaje de verificación o rechazo. El solicitante revisaba cómo el analizador había interpretado el envío. Las correcciones podían devolverse y volver a comprobarse. Una verificación satisfactoria liberaba la solicitud para su procesamiento final por el personal de registro. Una verificación sin respuesta caducaba a los siete días. Un número de ticket exponía el estado de la solicitud, y una visualización WHOIS podía llevar una fecha de última actualización.

Estos controles mejoraban la forma, el tiempo y la trazabilidad, pero su modalidad importa.

El formulario de verificación se enviaba alsolicitante original. RFC 1400 no dice que un contacto administrativo existente lo recibiera porque una lista WHOIS anterior confiriera autoridad. La posición procedimental del solicitante surgía de haber presentado la solicitud. El formulario devuelto verificaba la interpretación del analizador de los datos presentados; no era, por sí mismo, prueba de que el solicitante poseyera autoridad legal para representar a la organización.

RFC 1400 también dice que las cuestiones de seguridad no se trataban en el memorando. Esa ausencia no prueba que el personal no utilizara verificaciones telefónicas, registros en papel, correspondencia previa o criterio institucional. Impide que el flujo de trabajo automatizado sea citado como evidencia de una norma universal de verificación de identidad.

Para el flujo de trabajo de dominio de 1993:

Procedencia:el sistema vinculaba una solicitud, un solicitante, un formulario analizado y un ticket.
Autenticación:el RFC no especifica una prueba independiente universal de autoridad organizativa.
Corrección:los errores del analizador y los envíos rechazados tenían una ruta de corrección explícita.
Tiempo:la información de apertura de ticket y un campo de última actualización proporcionaban marcadores temporales actuales.
Historial:los ejemplos públicos no establecen una secuencia completa de versiones presentadas y decisiones del personal.
Revisión:el personal de registro realizaba el procesamiento final, pero el RFC no define la adjudicación de dos reclamaciones competidoras.
Legitimación administrativa:el documento prueba la posición del solicitante original en esa solicitud, no la legitimación adquirida de un campo de contacto público existente.

Una comparación delimitada de RFC 1591

RFC 1591, de marzo de 1994, trataba sobre la estructura y delegación del DNS. Solo es útil como comparación específica de dominio.

El documento exigía contactos administrativos y técnicos para un dominio delegado, pero la responsabilidad se basaba en algo más que un campo. Se esperaba que el gestor designado sirviera a la comunidad relevante, operara el dominio de forma competente, respondiera a las solicitudes, mantuviera un servicio preciso y resistente, y conservara el apoyo de las partes significativamente interesadas. Una transferencia de la responsabilidad del gestor designado requería comunicaciones tanto de la organización antigua como de la nueva, siendo también relevantes las partes afectadas.

En disputas sobre derechos a un nombre, RFC 1591 limitaba el papel de la autoridad de registro a proporcionar información de contacto y decía que el registro no creaba estatus de marca registrada. También contemplaba la revisión cuando las partes no pudieran llegar a un acuerdo.

Los actores fechados eran IANA, el gestor de nivel superior, las organizaciones antigua y nueva, y las partes afectadas. Un registro de contacto podía identificar a quién dirigirse. Una decisión de delegación dependía del rendimiento operativo, el acuerdo, las comunicaciones y la revisión.

Esto es una comparación dentro del DNS. No puede establecer la propiedad de un bloque de direcciones IP, y no prueba que cada cambio de dominio de segundo nivel siguiera el mismo proceso.

Un caso completo de legitimación administrativa: CLUE.COM en 1996

La política de disputas de nombres de dominio de Network Solutions de julio de 1995 prescribía notificación y opciones procedimentales para el registrante registrado cuando se presentaba una reclamación de marca cualificada. Las descripciones posteriores de esa política, por sí solas, establecen el procedimiento en lugar de la dependencia consumada. Un caso específico proporciona las pruebas que faltan.

La opinión de 1998 enOppedahl & Larson v. Network Solutionsdescribe el registro que rodea la adopción de la política de julio de 1995. Identifica las admisiones de las partes, la prueba de la política y la respuesta de esta a un registro de marca federal certificado idéntico a un nombre de dominio registrado. El registrador podía escribir al registrante del dominio y ofrecer opciones especificadas. Ese relato judicial confirma el procedimiento, al tiempo que registra disputas sobre su aplicación a los registrantes existentes.

Un procedimiento judicial separado y contemporáneo documenta la aplicación de la política a un registro concreto. EnNetwork Solutions, Inc. v. Clue Computing, Inc., el Tribunal de Distrito de los EE. UU. para el Distrito de Colorado registró que Clue Computing poseía el registro de CLUE.COM gestionado por Network Solutions y que Hasbro afirmaba una reclamación de marca competidora.

El 1 de febrero de 1996, Network Solutions informó a Clue Computing de que su uso del dominio podría infringir la marca de Hasbro. El registrador exigió a Clue Computing que presentara una certificación de marca o aceptara la asignación de un nuevo nombre de dominio. Clue Computing no permaneció como un nombre pasivo en una pantalla. Respondió como el registrante reconocido, presentó una demanda estatal contra Network Solutions y trató de impedir que el registrador pusiera el registro en espera.

El 25 de junio de 1996, el Tribunal de Distrito del Condado de Boulder prohibió a Network Solutions cambiar el registro y uso de CLUE.COM. Mientras tanto, Network Solutions había presentado una acción federal de interpleito, presentándose como un depositario dispuesto a asignar el registro y uso según lo ordenara el tribunal. El tribunal federal desestimó esa acción. Concluyó que la medida cautelar estatal existente impedía a Network Solutions poner el dominio bajo control federal y que la disputa también implicaba los deberes contractuales de Network Solutions hacia Clue Computing.

Los elementos probatorios son inusualmente completos:

Fecha:notificación el 1 de febrero de 1996, seguida de la acción estatal, la medida cautelar de junio y la decisión federal en 1996.
Actores:Network Solutions, Clue Computing, Hasbro, el Tribunal de Distrito del Condado de Boulder y el tribunal federal de distrito.
Registro específico:el registro de CLUE.COM en el sistema de registro autoritativo de Network Solutions, junto con el expediente de disputa del registrador y la presentación de marca competidora.
Decisión:si el registrante registrado tenía que presentar pruebas válidas, aceptar un nombre de sustitución, enfrentarse a una suspensión u obtener protección judicial.
Fuentes de verdad competidoras:el registro de registro, las pruebas de marca de Hasbro, la relación de registro, el uso real, los deberes contractuales y las órdenes judiciales.
Resultado:el registrante registrado recibió notificación, entró en el procedimiento contencioso y obtuvo una medida cautelar que preservaba el registro mientras continuaba la disputa; el interpleito federal fue desestimado.

Este caso demuestra la legitimación administrativa dentro del procedimiento de registro subyacente del registrador. El registro actual determinaba a qué parte trataba Network Solutions como el registrante cuyo uso se veía amenazado y cuya respuesta importaba.

No muestra que Network Solutions adquiriera la identidad de esa parte únicamente ejecutando una consulta WHOIS pública. La opinión se refiere al registro autoritativo gestionado por Network Solutions, la política del registrador, su correspondencia y el litigio resultante. El WHOIS público podía exponer la información de registro y contacto, pero el caso no establece que la visualización pública creara la posición procedimental de Clue Computing.

Tampoco decidió el registro la cuestión última de la marca. El registro de marca de Hasbro proporcionaba una reclamación competidora. Clue Computing se basó en el proceso contractual y judicial. La medida cautelar preservaba el statu quo; no era una declaración final de que los datos de contacto públicos probaran la propiedad.

El escalón de la legitimación administrativa está, por tanto, probado, pero solo con una calificación importante: está probado para el tratamiento por parte del registrador de la parte registrada en su sistema de registro autoritativo, no como un poder constitutivo general de los campos WHOIS públicos.

La colisión de octubre de 1995: mutación de la base de datos y control práctico

El posterior registro de apelación federal enKremen v. Cohenreconstruye un cambio de registro diferente de octubre de 1995.

Network Solutions recibió una carta que pretendía autorizar la eliminación de un registro de dominio existente y el registro por otra parte. Actuando sobre la carta, Network Solutions eliminó el registro anterior de su base de datos, registró el dominio a una organización diferente y listó un nuevo contacto administrativo. Más tarde se descubrió que la carta era falsa. El nuevo registrante utilizó el dominio. Cuando se exigió la restauración, Network Solutions solicó inicialmente una orden judicial. El litigio finalmente resultó en la restauración del registro.

La opinión fue redactada años después de la transacción. Es evidencia de la secuencia reconstruida y de las conclusiones judiciales, no un registro de operaciones contemporáneo.

Deben permanecer separadas cinco realidades:

Base de datos de registro autoritativa:Network Solutions eliminó un registro e introdujo otro.
Salida WHOIS pública:una consulta podía mostrar información derivada del sistema de registro actual, pero la opinión no dice que una consulta pública causara el cambio.
Procedimiento de cambio:Network Solutions actuó sobre la carta presentada.
DNS y uso:el nuevo registro fue seguido por el uso práctico del dominio.
Prueba documental y legal:la autorización aparente entraba en conflicto con el consentimiento genuino y más tarde se determinó que era falsa.

El actor fechado era Network Solutions. El registro específico era su entrada de registro de dominio subyacente, no una respuesta WHOIS pública. La decisión era poner fin a un registro, reconocer otro y, posteriormente, negarse a la restauración administrativa sin una orden judicial. Las fuentes competidoras eran la solicitud original, la autoridad organizativa real, la carta en disputa, el testimonio y las conclusiones judiciales. El resultado fue un cambio en quién podía utilizar el registro en la práctica, seguido posteriormente por la restauración judicial.

Este es el ejemplo más sólido anterior a 1997, en el material examinado aquí, de una consecuencia similar a la titularidad producida por la mutación de un sistema de registro autoritativo. La operación de la base de datos del registrador hizo más que enviar un mensaje equivocado; alteró el estado de registro operativo y el uso práctico.

No prueba que el WHOIS público transfiriera el dominio, confiriera la propiedad o hiciera que Network Solutions actuara. A lo sumo, una respuesta pública habría reflejado el estado modificado después de la transacción. La operación constitutiva ocurrió en los sistemas de registro autoritativo y administración de DNS.

Tampoco prueba el caso que todos los procedimientos de actualización tempranos no estuvieran autenticados o no fueran fiables. Documenta un fallo trascendental que implicó una instrucción falsificada. Generalizar a partir de él excedería la evidencia.

Número de red, ASN y contacto: el registro de recursos numéricos

La cuarta familia se desarrolló bajo presiones diferentes: escasez de direcciones, escala de enrutamiento, delegación a proveedores y registros regionales, y la necesidad de identificar redes durante incidentes operativos.

El precursor de contacto de red DDN

El informe de Stahl de abril de 1991 describíaNETWORK-CONTACTS, un archivo legible por humanos para números de red de Internet registrados. La sección 3.10, en la página 11 del informe, dice que la información provenía de solicitudes de registro de números de Internet procesadas por el Hostmaster del NIC y de correcciones presentadas por los coordinadores de red. Los datos brutos se almacenaban en la base de datos WHOIS del NIC. El derivado se generaba semanalmente.

El archivo de contactos unía un número de red y un nombre de red a un contacto y un handle del NIC. Su propósito operativo era claro: pasar de un número a una organización o persona responsable. No contenía toda la correspondencia de asignación, el acuerdo del proveedor, la evidencia de utilización o el estado de enrutamiento.

Este precursor no debe confundirse con un registro creado por un registro regional posterior. El linaje institucional continuó, pero el operador del registro y el proceso circundante cambiaron.

La población de InterNIC después de abril de 1993

RFC 1400 colocó las direcciones IP y los números de sistema autónomo, con los puntos de contacto asociados, en el servicio InterNIC después de la transición. Eso formalizó una población centrada en objetos: una persona aparecía cada vez más porque estaba vinculada a un objeto de infraestructura registrado.

La transición mejoró la descubribilidad central, pero la existencia de un objeto de dirección o ASN no demostraba por sí misma un derecho. La correspondencia de asignación, la decisión administrativa del registro, las relaciones con los proveedores, el enrutamiento real y el cumplimiento continuo seguían siendo cuestiones separadas.

RWhois como comparación de diseño

RFC 1714, de noviembre de 1994, proponía el protocolo WHOIS de Referencia para un entorno de registro distribuido. Distinguía las respuestas autoritativas y las almacenadas en caché, definía áreas de autoridad y utilizaba valores de serie que cambiaban cuando los datos cambiaban. También permitía operaciones de registro y preveía información de autenticación.

Esas características muestran que los diseñadores reconocían la procedencia, la autoridad, la replicación y la mutación como preocupaciones distintas. No prueban que cada actualización de producción de InterNIC o de un registro regional utilizara los mecanismos propuestos.

El método de autenticación seguía abierto. RFC 1714 decía que se necesitaba más trabajo para la delegación no supervisada y que se requería más investigación para la autenticación de clientes. Su sección formal de seguridad no analizaba las cuestiones de seguridad. El documento también permitía que los datos eliminados desaparecieran de un servidor primario en lugar de exigir una retención permanente solo para la actualización secundaria.

RWhois es, por lo tanto, una comparación de diseño de 1994, no evidencia de un sistema de auditoría universal desplegado. Sus valores de serie rastreaban el estado de un área de autoridad; no eran necesariamente una explicación pública de quién cambió cada objeto, bajo qué autoridad y por qué.

RFC 2050 y los datos de registro consecuentes

En noviembre de 1996,RFC 2050situó el registro dentro de una política de asignación más amplia. Describía un registro público que documentaba las asignaciones y cesiones de espacio de direcciones para garantizar la unicidad y la resolución de problemas. Se exigía a los proveedores que presentaran la información de reasignación con prontitud.

El documento daba tres razones para esas presentaciones:

los operadores necesitaban saber quién estaba utilizando un número de red y con quién contactar en caso de problemas operativos o de seguridad;
la información de reasignación ayudaba a demostrar el uso de una asignación existente antes de justificar espacio de direcciones adicional;
los datos respaldaban los estudios de asignación.

RFC 2050 establecía que no se asignarían bloques CIDR adicionales por parte de un registro regional o proveedor ascendente hasta que se hubiera presentado aproximadamente el 80 por ciento de la información de reasignación. También decía que los proveedores debían conservar la justificación documentada de las cesiones y que la documentación no disponible podía afectar a las asignaciones futuras.

Este fue un cambio significativo en las consecuencias. El registro ya no era solo una entrada de directorio creada después de una asignación. El mantenimiento de los datos de reasignación formaba parte de las obligaciones administrativas continuas del proveedor.

No obstante, RFC 2050 no reducía la asignación a una fila WHOIS. Un registro podía exigir planes de ingeniería, examinar cesiones anteriores, verificar la utilización, solicitar documentación organizativa y auditar una solicitud. Distinguía las asignaciones a proveedores de las cesiones a empresas finales. Recomendaba tratar las direcciones basadas en proveedores como préstamos vinculados a la conectividad y advertía que la asignación no garantizaba la enrutabilidad. Las transferencias requerían la aprobación del registro regional según los criterios aplicables.

La importancia del registro en el escalón superior es, por tanto, normativa y no específica de un caso:

Política fechada:RFC 2050, noviembre de 1996.
Actores nombrados por la política:registros regionales, registros locales, proveedores y organizaciones solicitantes.
Registro:datos de asignación, cesión y reasignación.
Decisión:contacto operativo y si el uso demostrado justificaba espacio de direcciones adicional.
Fuentes de verdad competidoras:cesiones de clientes, evidencia de utilización, planes de ingeniería, tablas de enrutamiento, contratos de proveedores, documentos organizativos y correspondencia del registro.
Consecuencia especificada:la insuficiencia de información de reasignación o justificación podía afectar a las asignaciones futuras.
Límite:la fuente no documenta un archivo de asignación particular anterior a 1997 en el que un registro nombrado tomara y completara esa decisión.

RFC 2050 prueba la relación de política entre el registro y la asignación. Sin un expediente de caso, no prueba la consistencia con la que se aplicaba la regla ni que una salida WHOIS pública decidiera por sí sola una solicitud específica.

Revisión y confidencialidad fuera del protocolo de consulta

RFC 2050 proporciona dos límites importantes que una visión centrada en WHOIS puede pasar por alto.

En primer lugar, la sección 6 otorgaba a una organización el derecho a apelar una decisión del registro ante el registro superior. El registro cedente debía poner a disposición la documentación pertinente. Las apelaciones posteriores podían continuar hacia arriba en la jerarquía y, una vez agotadas otras vías, llegar a IANA para una decisión final. Se esperaba que cada registro documentara su procedimiento de apelación.

En segundo lugar, la sección 4.6 exigía que un registro cedente tratara como confidencial la información marcada específicamente como sensible por una organización solicitante. Cuando la privacidad no pudiera garantizarse, el registro superior podía intervenir en la cesión.

Ninguno de estos controles era una característica del protocolo de consulta del puerto 43. El registro público y el archivo de solicitud confidencial no eran conjuntos de datos idénticos. El registro de apelación y el registro de contacto público también eran diferentes. Un usuario que inspeccionara WHOIS no vería necesariamente las pruebas de ingeniería sensibles, el razonamiento del registro ni los documentos transmitidos en apelación.

Para los registros de recursos numéricos, la auditoría es, por tanto:

Procedencia:los proveedores, los registros locales o las organizaciones solicitantes suministraban cesiones y materiales de apoyo.
Autoridad de actualización:RFC 2050 imponía deberes de presentación rápida, pero no especificaba un método técnico único de autenticación para cada actualización.
Autenticación y verificación:los registros podían auditar y exigir documentación corroborante; el registro público no exponía todas esas pruebas.
Corrección y reemplazo:el proceso de registro circundante podía revisar los registros, pero RFC 2050 no definía un historial de versiones público universal.
Tiempo:se exigía una presentación rápida; una fila pública actual no revelaba necesariamente el historial efectivo completo.
Revisión:las apelaciones seguían la jerarquía del registro y podían llegar en última instancia a IANA.
Privacidad:el registro tenía un componente operativo público, mientras que la información sensible designada por el solicitante debía permanecer confidencial.
Titularidad:el registro podía afectar a la administración de la asignación, pero no garantizaba la enrutabilidad ni servía como instrumento de titularidad completo.

Comparación de las cuatro familias de registros

La interfaz WHOIS compartida ocultaba diferentes límites probatorios.

Familia de registros	Sujeto principal	Uso más sólido probado antes de 1997	Evidencia de actualización y corrección	Límites históricos y de revisión
WHOIS de directorio personal	Un individuo y canales de contacto	Conveniencia de directorio	Información de registro enviada al NIC; sin regla pública completa de autenticación de actualización en RFC 812 o RFC 954	Sin historial de versiones público especificado por registro ni revisión de identidad impugnada
Contactos de host y red DDN	Hosts, redes y roles operativos responsables	Dependencia operativa y atribución limitada de responsabilidad	Directivas de red, solicitudes mensuales de corrección, actualizaciones voluntarias y derivados generados semanalmente documentados en el informe de abril de 1991	Las versiones a nivel de archivo no necesariamente exponían todos los campos reemplazados o decisiones de conflicto
Registro de dominio y WHOIS	Organización, dominio, contactos y servidores de nombres	Verificación prescrita; legitimación administrativa consumada en un procedimiento de registro subyacente del registrador en 1996; consecuencias prácticas de una mutación de base de datos autoritativa en 1995	Solicitudes de dominio y correcciones; verificación del analizador de 1993 por el solicitante original; política y correspondencia del registrador	Sin prueba de que el WHOIS público por sí solo autorizara cambios, creara legitimación o decidiera la titularidad; las disputas dependían de acuerdos, evidencia de marcas, DNS, correspondencia y tribunales
Registro de recursos numéricos	Números de red, ASN, asignaciones, cesiones y contactos	Contacto operativo e influencia basada en políticas en la asignación adicional	Solicitudes de registro, correcciones de coordinadores, deberes de reasignación rápida, auditorías y documentos de apoyo	No se identificó ningún caso anterior a 1997 que mostrara una fila pública decidiendo una asignación; las pruebas confidenciales, el razonamiento, las versiones anteriores y los materiales de apelación podían permanecer fuera de la consulta

Esta comparación previene dos historias falsas.

La primera comenzaría con el directorio personal de 1982 y trataría cada objeto de registro posterior como una versión ampliada de la misma fila de páginas blancas. Eso ignora los distintos deberes que tenían los administradores de host, los administradores de dominio, los registrantes, los proveedores y los contactos de recursos.

La segunda comenzaría con una mutación trascendental de registro de dominio y leería su poder hacia atrás en cada respuesta WHOIS anterior. Eso ignora la diferencia entre una visualización pública y el sistema autoritativo capaz de cambiar un registro o una delegación.

La escalera, con sus límites expuestos

La escalera probatoria ahora puede contrastarse con conductas fechadas en lugar de solo con nombres de campo.

Escalón	Actor y registro fechados	Decisión	Fuente de verdad competidora	Resultado y límite
Conveniencia de directorio	Usuarios de ARPANET y DDN descritos en RFC 812 (1982) y RFC 954 (1985), consultando entradas personales y organizativas	A quién contactar o qué registro coincidía con un nombre	Directorios de empleadores, cuentas de host, listas de sitios, confirmación directa	El servicio proporcionaba un punto de partida legible por humanos; no se muestra ninguna consecuencia de titularidad
Dependencia operativa	Sitios afectados y CERT/CC en el incidente italiano de diciembre de 1990, utilizando un registro de red del NIC de DDN	Con qué institución contactar sobre el tráfico observado	Registros, información de enrutamiento, administración local, investigación directa	La consulta orientó la respuesta hacia una institución
Atribución de responsabilidad	Los mismos respondedores, utilizando la asociación red-organización	Qué organización debía investigar y actuar	Control de la máquina real y autoridad institucional	La responsabilidad se atribuyó a nivel de red o institucional, no de forma concluyente a un administrador de máquina o usuario
Legitimación administrativa	Network Solutions el 1 de febrero de 1996, utilizando el registro de CLUE.COM y el expediente de disputa para notificar a Clue Computing	Qué registrante registrado debía responder a la reclamación de marca y podía impugnar una suspensión o cambio amenazados	Evidencia de marca, relación de registro, uso real, deberes contractuales, órdenes judiciales	El registrante registrado recibió notificación, litigó y obtuvo una medida cautelar; no se muestra que el WHOIS público por sí solo creara esa legitimación
Inferencia cuasi-titular	Network Solutions en octubre de 1995, modificando su base de datos de registro de dominio autoritativa tras una supuesta autorización	Si poner fin a un registro, crear otro y, posteriormente, restaurar el estado original	Autoridad genuina, correspondencia original, carta en disputa, testimonio, conclusiones judiciales	La mutación de la base de datos produjo consecuencias de uso práctico; el caso no muestra que una consulta WHOIS pública causara el cambio

La administración de recursos numéricos alcanzó un escalón superior relacionado pero menos documentado en RFC 2050. Los datos de registro y reasignación eran insumos prescritos para futuras decisiones de asignación. Sin un expediente de caso completo, eso sigue siendo evidencia de política de una consecuencia administrativa esperada y no prueba de que una fila pública decidiera una solicitud concreta.

El resultado es asimétrico. La conveniencia de directorio, la dependencia operativa y la atribución de responsabilidad están bien respaldadas por especificaciones y un incidente fechado. La legitimación administrativa se demuestra en un procedimiento de registrador específico que involucra un registro de dominio autoritativo. La consecuencia cuasi-titular se demuestra por la mutación de ese sistema autoritativo. La evidencia disponible no muestra que el WHOIS público se convirtiera en una fuente universal de legitimación o titularidad antes de 1997.

De dónde procedía la autoridad

WHOIS no adquirió fuerza solo a través del protocolo técnico.

RFC 812 declaraba que el NIC de SRI mantenía el servicio en nombre de la Defense Communications Agency. El informe de Stahl de abril de 1991 identifica un contrato gubernamental, un contratista responsable, un entregable, una base de datos de origen y archivos derivados. RFC 1400 documenta la transición de los servicios no DDN a InterNIC.

Elhistorial legal de la Oficina de Responsabilidad Gubernamentalregistra que la National Science Foundation celebró un acuerdo cooperativo con Network Solutions en 1993 para proporcionar servicios de información ampliados y coordinados para la Internet no militar. Esos servicios incluían el registro de dominios de segundo nivel, mientras que Network Solutions también cooperaba con la USC en la gestión de la zona raíz.

La autoridad práctica de la base de datos provenía de esas asignaciones institucionales, de los servicios de registro realizados en virtud de ellas y de la disposición de otros actores a tratar el registro mantenido como actual. La autoridad residía en la función reconocida de una organización y en su capacidad para actuar sobre su base de datos, no en la sintaxis de una respuesta del puerto 43.

El historial de la GAO también conlleva una advertencia probatoria. Describe sus conclusiones como limitadas por un registro incompleto y señala que no se pudieron obtener documentos contractuales clave de los años setenta a los noventa. Los acuerdos e informes supervivientes sitúan los servicios bajo el patrocinio federal y la ejecución de contratistas. No respaldan una afirmación radical de que un contrato convirtiera cada campo de contacto en un título legal.

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, IANA y los registros regionales eran instituciones relacionadas, pero no intercambiables. Sus circunscripciones, funciones asignadas, materiales de origen y registros cambiaron. La continuidad de los datos no garantizaba que cada entrada heredada hubiera sido reautenticada bajo los procedimientos de un sucesor.

Costes de privacidad y corrección históricamente delimitados

La privacidad entra en esta historia porque los campos originales se eligieron para la localización.

El servicio de directorio personal exponía deliberadamente suficiente información para encontrar y contactar a las personas. Los archivos operativos DDN podían exponer a los titulares de roles y amplios canales de contacto porque los administradores remotos necesitaban llegar a alguien capaz de actuar. Los registros de dominio conectaban contactos identificables con funciones administrativas y técnicas. Los registros de recursos numéricos conectaban identificadores de red con contactos operativos.

El cambio histórico no fue simplemente de información privada a pública. Fue de un directorio personal que servía a una comunidad relativamente limitada a registros de infraestructura consultados durante incidentes, cambios de registro, disputas y decisiones de asignación.

Ese cambio aumentó las consecuencias de un rol obsoleto. Un antiguo contacto podía seguir visible después de un cambio organizativo. Un operador técnico actual podía carecer de autoridad política. Un representante administrativo podía estar autorizado pero ser incapaz de reparar una máquina. La solicitud de corrección mensual y la publicación semanal reducían el retraso en partes del sistema DDN, pero no garantizaban que la realidad externa y cada derivado cambiaran simultáneamente.

El registro también muestra una reducción de la población. RFC 1400 decía que los registros individuales de InterNIC cubrirían principalmente puntos de contacto asociados a nodos activos, mientras que los proyectos generales de directorio personal podían distribuirse en otros lugares. En 1996, RFC 2050 distinguía la información de registro pública del material de solicitud sensible que los registros estaban obligados a mantener confidencial cuando el solicitante lo marcaba como tal.

Esos eran límites específicos de la época. No deben reescribirse como si una arquitectura de datos de registro posterior ya gobernara 1982. La pregunta histórica es más limitada: si la cantidad y la forma de la información de contacto seguían siendo proporcionadas después de que los campos comenzaran a influir en decisiones que iban más allá del descubrimiento.

Reducir la información pública también podía imponer costes operativos. El incidente de diciembre de 1990 muestra por qué era importante una consulta central: daba a los respondedores remotos un punto de partida institucional. La debilidad del registro no era simplemente que expusiera un contacto. Era que una asociación a nivel de organización podía ser menos precisa de lo que exigía un incidente.

El problema político no era, por tanto, una simple oposición entre apertura y privacidad. Era cómo preservar la localización específica del rol sin tratar a la persona nombrada como el actor, el controlador, la parte contractual o el titular legal en todos los contextos.

Contrafactual A: registros autenticados, versionados y expresamente no constitutivos

Supongamos que las mismas entradas de directorio hubieran ido acompañadas de una autenticación procedimental más sólida, la conservación de versiones anteriores, marcas de tiempo de vigencia, motivos registrados para el cambio y una declaración explícita de que los campos describían contactos en lugar de crear derechos.

Se trata de una comparación de diseño delimitada. Los formularios en papel controlados, la correspondencia conservada, los procedimientos de devolución de llamada, los registros fechados y las refrendos institucionales estaban conceptualmente disponibles durante el período. Un sistema universal de identidad criptográfica que vinculara cada contacto de red con una organización no era un requisito establecido de RFC 812. Las suposiciones posteriores sobre identidad federada, certificados automatizados o servicios estructurados de datos de registro no deben proyectarse hacia atrás como deberes que los diseñadores de 1982 ignoraron.

Dentro de ese límite, controles más sólidos habrían mejorado varias decisiones.

Un usuario podría distinguir cuándo un contacto se volvía actual y si la entrada era anterior a una fusión, renuncia, cambio de proveedor o disputa de delegación. El personal podría identificar a la persona que solicitó una mutación, la autoridad alegada y el registro anterior desplazado. Una parte impugnada podría cuestionar la transacción precisa en lugar de limitarse a enfrentarse a la última respuesta pública.

La colisión de registro de octubre de 1995 ilustra el valor. Si el registrador hubiera exigido confirmación a través de un canal establecido de forma independiente, documentado la autoridad alegada por el remitente, conservado el registro sustituido como un estado histórico visible y separado el cambio de registro solicitado de la acción DNS resultante, la instrucción defectuosa podría haberse detectado antes o revertido de manera más eficiente.

La salvaguarda no habría convertido el directorio en un sistema de titularidad. La autenticación prueba que una parte identificada hizo una declaración. No prueba necesariamente que la parte poseyera autoridad corporativa, que un acuerdo siguiera siendo válido, que una relación con un proveedor continuara o que un tribunal reconociera la titularidad alegada.

El versionado tiene un límite similar. Puede mostrar que un campo cambió y preservar lo que lo precedió. No puede decidir qué estado era legalmente correcto. Un código de motivo puede explicar por qué actuó el personal, pero el motivo puede seguir dependiendo de un documento falsificado o de una interpretación discutida.

Una declaración explícita de no derechos habría aclarado la intención institucional. RFC 1032 y RFC 1591 ya proporcionaban límites sustantivos relacionados al negarse a arbitrar derechos locales o al separar el registro del estatus de marca. Repetir dichos límites en la respuesta pública podría haber reducido las inferencias descuidadas.

Probablemente, la deriva de la autoridad se habría producido de todos modos. Las instituciones favorecen los registros que están disponibles, son legibles y son mantenidos por el organismo responsable del servicio. Un directorio bien autenticado podría atraer aún más dependencia. La diferencia es que los usuarios posteriores podrían distinguir mejor una afirmación de contacto de una asignación, un registro de un contrato y una visualización actual de la evidencia que respalda un cambio.

Contrafactual B: sin directorio, mientras que las relaciones subyacentes sobreviven

Ahora eliminemos el directorio público, dejando intactos los contratos, la correspondencia de asignación, las solicitudes de registro, las operaciones de enrutamiento, las delegaciones de DNS, los registros organizativos, los registros y las redes telefónicas.

Muchas decisiones siguen siendo posibles.

Un registro puede determinar quién recibió una asignación a partir de su correspondencia y archivo de decisión. Un proveedor puede identificar a su cliente a partir de un acuerdo de servicio. Un registrador puede inspeccionar una solicitud y las instrucciones posteriores. Un administrador de dominio puede examinar la delegación activa y los servidores de nombres autoritativos. Un operador puede inspeccionar la información de enrutamiento y escalar a través de las redes adyacentes. Un tribunal puede evaluar el consentimiento, la autoridad organizativa, los acuerdos, los registros de marcas y los testimonios.

La función que falta es el descubrimiento rápido a través de las fronteras institucionales.

En el incidente de diciembre de 1990, los sitios afectados seguirían teniendo registros, pero el camino desde un número de red hasta una institución relevante sería más lento. Los respondedores podrían tener que trabajar a través de las relaciones de enrutamiento, los proveedores o las consultas manuales. El directorio no creó los registros ni la responsabilidad de la institución. Redujo el coste de encontrar la institución que podría actuar.

En la administración de dominios, el DNS podría mostrar los servidores de nombres en funcionamiento, y la correspondencia de registro podría mostrar la solicitud original. Sin un directorio común, encontrar al representante administrativo sería más difícil. El funcionamiento del DNS no probaría, aun así, el consentimiento organizativo.

En la disputa de CLUE.COM, Network Solutions podría identificar a su registrante a partir del archivo de registro autoritativo y la correspondencia, incluso si no existiera un servicio WHOIS público. El registrador podría enviar igualmente la notificación, y el registrante podría invocar igualmente los recursos contractuales o judiciales. Esto demuestra que la legitimación administrativa en ese caso no dependía únicamente de la comodidad de la consulta pública.

En la administración de recursos numéricos, un registro podría evaluar una asignación adicional a través del archivo de solicitud y la evidencia de utilización. Sin registros estandarizados de registro y reasignación, la reconstrucción de las cesiones anteriores y la localización de los contactos descendentes serían más lentas y menos coherentes.

Este contrafactual identifica el valor distintivo de WHOIS: hacía que las relaciones heterogéneas fueran buscables a partir de un identificador. Pone a la vista a la primera persona u organización relevante.

También demuestra por qué la conveniencia no debe confundirse con la autoridad constitutiva. La relación subyacente podría sobrevivir a la ausencia del directorio. El directorio hacía que esa relación fuera legible y procesable; dependiendo del sistema, la transacción de registro autoritativa, la decisión de asignación, el contrato o el estado operativo permanecían en otro lugar.

El umbral de 1997

Lahistoria institucional de ARINafirma que se estableció en diciembre de 1997 como una organización sin ánimo de lucro independiente que proporcionaba servicios de registro de IP en su región. Suinforme anual de 1999fecha la apertura de las operaciones el 22 de diciembre de 1997.

Antes de esa fecha, varias proposiciones estaban bien respaldadas:

una consulta central podía asociar a personas y organizaciones con identificadores de Internet;
se esperaba que los contactos de roles específicos fueran localizables y capaces de actuar;
los Hostmasters utilizaban solicitudes, directivas, administradores reconocidos y envíos de corrección para mantener los registros;
algunos derivados DDN se regeneraban semanalmente y se apoyaban en solicitudes mensuales de corrección;
los operadores utilizaban registros de contacto de red para decidir a dónde dirigir los informes de incidentes;
se instruía a los administradores de dominio para que compararan los datos WHOIS con la información de registro y servidor prevista;
un registrante de dominio registrado podía recibir una notificación y ocupar una posición procedimental trascendental en una disputa de registrador consumada;
la mutación de un registro de dominio autoritativo podía producir consecuencias de uso prácticas;
los datos de reasignación de recursos numéricos eran insumos prescritos para el contacto operativo y la administración de asignaciones posteriores;
las decisiones de asignación podían ser auditadas, apeladas y respaldadas por material confidencial fuera del registro público.

Varias proposiciones más contundentes siguen sin probarse según la evidencia aquí examinada:

que cada actualización personal, de host, de dominio o de recurso numérico utilizara un método uniforme de verificación de identidad;
que cada registro público expusiera un historial completo de valores anteriores y motivos de cambio;
que un contacto público existente poseyera automáticamente autoridad para confirmar o reemplazar un registro;
que el solicitante original de RFC 1400 fuera reconocido debido a una lista de contacto público anterior;
que el WHOIS público por sí solo creara la legitimación administrativa de Clue Computing en la disputa de 1996;
que el cambio de registro de Kremen fuera causado por la dependencia de una consulta WHOIS pública en lugar de por el procedimiento de cambio del registrador y la mutación de la base de datos;
que una fila pública de recursos numéricos por sí sola decidiera una solicitud de asignación documentada anterior a 1997;
que un contacto listado estableciera de manera concluyente el control técnico actual, la propiedad legal o la titularidad contractual;
que la delegación de DNS estableciera un derecho a un bloque de direcciones IP;
que un registro regional posterior mantuviera o fuera autor de registros antes de comenzar a operar.

Por lo tanto, la transición de la conveniencia a la autoridad no tuvo una fecha única. Sus etapas más sólidas ocurrieron en diferentes familias de registros.

El WHOIS de directorio personal estableció un descubrimiento conveniente. Los contactos de host y red DDN pasaron a la dependencia operativa y la atribución de responsabilidad. Una disputa de dominio consumada de 1996 muestra la legitimación administrativa vinculada a la relación de registro autoritativa del registrador, mientras que la secuencia de Kremen de 1995 muestra consecuencias prácticas de la mutación de ese sistema autoritativo. La política de recursos numéricos hizo que los datos de registro fueran relevantes para las futuras decisiones de asignación, al tiempo que se conservaban documentos de apoyo, confidencialidad y apelación fuera de la consulta pública.

Los escalones superiores de la escalera son reales pero están ubicados de manera restringida. Antes de 1997, el registro disponible no muestra que el WHOIS público se convirtiera en un instrumento de titularidad universal. Muestra algo más frágil e institucionalmente revelador: una capa de contacto conveniente que se convierte en la primera evidencia consultada, el primer marco colocado alrededor de un problema y el reflejo visible de decisiones trascendentales cuya autoridad aún provenía de bases de datos, procedimientos, contratos, sistemas operativos y revisiones más allá de la consulta.