Resumen

  • La RFC 1101 propuso una relación entre nombres de red, números y niveles anidados de subred mediante PTR en entradas de host cero de IN-ADDR.ARPA; un registro A podía transportar la máscara para continuar la búsqueda.
  • El diseño distinguía el nombre elegido por una organización del registro de números asignados por el NIC. Una respuesta DNS documentaba una relación acotada; no asignaba el número, no seguía por sí sola un cambio de nombre y no probaba el control presente.

La función que el DNS aún no había heredado

El punto de partida de la RFC 1101 es muy concreto. P. Mockapetris observó que el DNS era extensible y ya podía albergar muchos tipos de datos, pero la conversión entre nombres de red y números seguía siendo la capacidad de HOSTS.TXT que faltaba. El texto de abril de 1989 ofrece una solución concreta para redes y, aparte, ideas experimentales para índices de identificadores y números. La primera era un estándar propuesto; las “Páginas Amarillas” no. No se declaraba que cada número trajera un significado humano universal. Se diseñaba un modo de hacer consultable una asociación mantenida en un ámbito definido.

Un depurador podía cambiar una cifra opaca por un rótulo inteligible. Esa mejora no transforma la etiqueta en concesión del número ni en prueba de quién opera la red, por dónde se encamina el tráfico o qué servicio responderá. El mapa ayuda porque no pretende resolver esas otras preguntas.

Nombrar bajo control local

El problema tenía forma de gobierno. La sintaxis anterior de los nombres de red era un espacio plano y favorecía que el NIC los regulara como regulaba los números. La RFC recoge una opinión mayoritaria distinta: control local de los nombres de red. Por ello adopta la sintaxis ampliada de nombres de host y deja a un administrador crear nombres dentro de los dominios que controla. El coste es explícito: los nombres de red se volverían tan complejos como los de host. El beneficio es que un rótulo puede vivir donde también viven el contexto y la responsabilidad de conservarlo. ARPANET.ARPA. es un ejemplo histórico de esa elección, no una definición permanente ni una declaración actual.

Desde una dirección hacía falta mirar en sentido inverso. Una etiqueta local no permite adivinar qué dominio debe consultarse al partir de una IP. La RFC aprovecha el árbol existente IN-ADDR.ARPA, donde la delegación organizada por direcciones podía albergar también el registro inverso. No hacía falta crear otra jerarquía global para publicar un hecho tan delimitado.

El host cero fue una ficha de archivo

La forma central era <número-host-cero-invertido>.IN-ADDR.ARPA. PTR <nombre-de-red>. El nombre de red guardaba el PTR recíproco. Cuando la red tenía otra subdivisión, en la misma entrada de host cero aparecía un A cuyo dato era la máscara de subred. La RFC muestra 0.0.0.10.IN-ADDR.ARPA. y 0.0.2.128.IN-ADDR.ARPA. como formas pedagógicas de la construcción.

El host cero no pasa a ser un host. Es una casilla reconocible del árbol DNS en la que se puede publicar información descriptiva y comprobar que existe. El PTR enlaza una entrada orientada al número con un nombre administrado localmente. No programa un encaminador, no concede autoridad ni convierte la etiqueta en dueño de la red.

El A tampoco debe leerse fuera de su papel. En esta propuesta llevaba una máscara cuando había otra capa de subred. Con la lógica classful de entonces, el procedimiento enmascara la IP, invierte octetos y consulta el PTR. Si llega el A-máscara, aplica esa máscara a la IP original y repite; cuando no llega, termina. Es una receta de lectura histórica, no una medición de topología actual ni una garantía de ruta.

Tres flechas no fabrican una realidad única

La RFC permitía además que el nombre de una organización tuviera PTR hacia una o varias entradas de host cero. Así aparecían tres direcciones: nombre de red a número, número a nombre y organización a entradas de red. Cada flecha responde a una pregunta delimitada. Un administrador que publica una asociación declara algo sobre su zona. Un nombre declara una elección de denominación. Una respuesta declara qué devolvió una consulta con cierta forma y en cierto momento.

Ninguna de ellas, sola o sumada sin otra prueba, establece propiedad presente, relación corporativa, custodia física, autorización, ruta BGP, recepción ni resultado de aplicación. El propio documento observa la tensión: las tablas centrales podían ser más consistentes, mientras la distribución podía ser más mantenible y oportuna. Un formato de registro no elimina el trabajo de mantener hechos correctos; permite ver quién publicó qué y hasta dónde llega esa afirmación.

Un número asignado no imponía el nombre posterior

La parte YP dice la frontera con especial claridad. La RFC imagina árboles DNS para pares de identificador y número: puertos, sistemas autónomos, protocolos o redes asignadas. La clave tenía que declarar de qué tipo partía y a qué tipo llegaba. Un número sin contexto no es todavía explicación.

Para las redes asignadas, el NIC podía mantener dominios YP que registraran sus propias decisiones de asignación. Pero la RFC traza una línea: esos dominios representarían nombres y números asignados, no los nombres que las organizaciones eligieran después. Tampoco seguirían automáticamente el renombramiento realizado por nuevos propietarios. Historia de asignación y nombre local eran datos diferentes por diseño.

Una lista central puede ser prueba excelente de su decisión central. Una zona local puede ser prueba excelente de una etiqueta local. No son licencia para deducir operador presente, servicio disponible, política de ruta o efecto de una transacción. El registro describe un hecho situado; no crea los hechos restantes que el lector quisiera inferir.

Leer el documento a su escala

La RFC 1101 informa sobre una propuesta de 1989. Sus clases de dirección, ejemplos y dominios YP no describen por sí mismos el DNS contemporáneo. Su disciplina sigue siendo útil: una correspondencia debe conservar procedencia, dirección y alcance; no se le deben cargar decisiones que el dato no contiene. Un nombre publicado, un número asignado, una ruta observada y un resultado probado son proposiciones distintas.

Fuentes y límite de evidencia

Este análisis histórico utiliza RFC 1101, RFC 1034 y RFC 1035. Respaldan la propuesta de 1989 y sus formas de registro; no prueban datos DNS actuales, control, identidad, titularidad, ruta, alcance ni rendimiento de un servicio.