Resumen

  • RFC 1480 contempló tres situaciones bajo .US: delegar una rama, registrar directamente una máquina IP con A o registrar directamente una máquina no-IP mediante MX. El nombre visible no indicaba cuál de ellas lo sostenía.
  • La delegación trasladaba control y obligaciones continuas a un gestor designado: servicio imparcial, competencia técnica, datos correctos, servidores redundantes, responsabilidad comunitaria y transferencia acordada. Insertar un registro en la base superior no otorgaba ese poder.

El formulario separaba lo que la dirección unificaba

En RFC 1480, de junio de 1993, la jerarquía de .US bajaba por estados, localidades y ramas funcionales. La dirección resultante hacía que una escuela, una biblioteca o una pequeña empresa parecieran parte de un sistema único. Lo eran como nombres consultables, pero no necesariamente como unidades administradas del mismo modo.

La sección de registro hablaba de delegación y registro directo. Luego dividía este último en máquinas IP y máquinas no-IP. No era una clasificación decorativa: cada casilla cambiaba quién conservaba la base, qué registro se publicaba y qué infraestructura debía existir detrás.

Una entidad podía tener un nombre sin controlar una zona. Podía recibir correo con sintaxis Internet sin ejecutar IP. Podía administrar una rama y, con ello, asumir deberes que no recaían sobre el titular de un registro directo.

Escribir A no equivalía a entregar la rama

Para una máquina IP, el administrador incorporaba directamente un registro A en la base de .US. RFC 1035 limita el testimonio de A a una dirección Internet de 32 bits. No dice quién puede crear otros nombres por debajo.

Esa segunda facultad nacía en otra operación. RFC 1034 exige identificar la zona superior apropiada y obtener su acuerdo para delegar el control. Los NS señalan servidores que deberían ser autoritativos para la zona que empieza en su nombre propietario. A y NS pueden convivir, pero no son sinónimos.

La diferencia aparece al corregir un error. Si el registro es directo, la modificación pertenece al administrador de la base superior o al delegado que ya tenga esa zona. Si existe una delegación, el gestor local puede editar su propia zona. El resolver entrega datos; no entrega por sí solo la cadena administrativa que los autorizó.

MX hacía uniforme el correo, no la conexión

RFC 1480 dedicó varias páginas a las máquinas UUCP. Algunas llamaban directamente a un host Internet; otras pasaban por una máquina intermedia antes de llegar al reenviador. Aun así podían usar un nombre DNS y una dirección de correo con forma Internet.

El mecanismo consistía en publicar un MX cuyo intercambio era una máquina IP dispuesta a aceptar el correo. RFC 974 explicaba el encaminamiento entre intercambiadores; RFC 1035 daba la semántica del registro. Ninguno convertía la máquina nombrada en un extremo IP.

Detrás de la respuesta DNS quedaban actos privados y temporales. El reenviador tenía que aceptar la tarea. Debía existir un procedimiento técnico para llegar a la máquina no-IP. Su tabla local necesitaba una regla; cada salto UUCP intermedio necesitaba otra. El administrador de .US podía insertar el MX, pero no negociar esos acuerdos por el solicitante.

Por eso una consulta positiva probaba un anuncio de encaminamiento de correo, no el consentimiento actual, la llamada telefónica, el vaciado de la cola ni la entrega final. La abstracción protegía al remitente de la complejidad. No autorizaba al auditor a ignorarla.

Delegar significaba escoger a quién exigir cuentas

La expansión del dominio hacía imposible que una sola oficina asignara todos los nombres. RFC 1480 proponía delegar ramas como K12.TX.US, una localidad o las bibliotecas de un estado. La delegación repartía tanto trabajo como capacidad de decisión.

El gestor designado debía atender de forma equitativa a los grupos de la rama, sin favorecer a clientes de un proveedor relacionado ni exigir un producto, protocolo o sistema de correo. Las partes con interés significativo debían reconocer que la persona u organización era adecuada. El administrador superior intentaría que los rivales acordaran una solución y reservaría su intervención para un abandono sustancial de las responsabilidades.

La legitimidad no sustituía la operación. El gestor también debía responder a tiempo, mantener la base exacta y robusta, y operar un primario y un secundario conectados por IP. El texto recomendó ubicaciones físicas claramente separadas para resistir un fallo local.

Contar dos nombres NS no demuestra dos dominios de fallo. Ver una respuesta autoritativa no demuestra trato imparcial. La autoridad delegada tenía testigos técnicos y comunitarios distintos.

La custodia podía cambiar sin que el nombre cambiara

Para transferir el trusteeship, RFC 1480 pedía comunicaciones tanto de la organización saliente como de la entrante. El administrador superior debía recibir evidencia de acuerdo mutuo y de que el sucesor entendía sus deberes. También resultaba útil escuchar a las partes afectadas.

La zona podía conservar el mismo nombre mientras cambiaban su custodio, sus servidores y su contrato social. Una instantánea DNS posterior no reconstruye esos pasos. Hay que conservar la aprobación del nivel superior, la aceptación de las dos organizaciones, el estado técnico antes y después y la fecha efectiva de cada cambio.

RFC 1591 formuló después la regla general: gestionar un dominio nacional era un servicio público y el designado era trustee de la comunidad nacional y de Internet global. Sirve para leer el modelo institucional, no para certificar que una delegación concreta lo cumplió.

La jerarquía describía una política de 1993

El diseño privilegiaba la administración manejable frente al deseo de que cada organización obtuviera el nombre corto “obvio”. La geografía y ramas como K12, LIB o GEN dividían la base en porciones donde podían mantenerse unicidad y responsabilidad.

RFC 1480 sustituyó a RFC 1386, publicada apenas seis meses antes. Ese relevo muestra documentación en movimiento. No demuestra que cada rama prevista se hubiera delegado ni que cada servidor recomendado existiera.

La ficha del RFC Editor mantiene el documento como Informational. Su sección de seguridad declara que no trata esos asuntos. La redundancia y la equidad eran disciplinas de operación y gobierno, no garantías criptográficas.

Un erratum verificado añadió muchos años después una barra ausente en la BNF del apéndice. Corrigió la gramática publicada; no cambió la autoridad histórica de ninguna zona.

La evidencia empieza antes de la respuesta DNS

Para saber qué significaba un nombre hay que preguntar quién publicó el registro y bajo qué modo. El expediente mínimo incluye nombre propietario, tipo A/MX/NS, zona autoritativa, corte de delegación, gestor, servidores y hora.

Si la afirmación es “recibía correo”, se añaden consentimiento del reenviador, reglas de cada salto, intento, cola y recibo. Si es “administraba la rama”, se añaden selección, acuerdo comunitario, competencia, independencia de servidores y transferencia. Si es “resolvía”, basta una observación DNS fechada, pero la conclusión debe quedarse ahí.

La historia de .US se vuelve más precisa cuando el punto final no borra al operador que lo puso allí.

Fuentes