Resumen

  • RFC 1279 llevó la jerarquía de dominios a X.500, pero mantuvo separado un dominio de una organización y un buzón de una persona. Un alias habría prometido que eran el mismo objeto, por lo que fue descartado.
  • AssociatedDomain y AssociatedName registraban asociaciones orientadas. La ficha del dominio debía ser ligera y remitir a la información organizativa en vez de copiarla; además, la relación podía ser de muchos a muchos.
  • La transferencia de zona podía escribir registros DNS en un DSA, pero no tocar los atributos no DNS. Fuente, traslado, recepción, escritura, conservación, vínculo, consulta y acción eran pruebas diferentes.

El árbol compartido no borraba las clases de objeto

RFC 1279, X.500 and Domains, apareció en noviembre de 1991 como propuesta Experimental. Quería representar el espacio DNS dentro del Directory Information Tree de X.500, hacer navegables los dominios y estudiar si la administración remota del directorio podía ayudar a gestionar información DNS.

El texto no presentó esa posibilidad como una migración terminada. Al principio era más probable que los datos siguieran bajo control de las bases de dominios y se cargaran después en X.500. El apéndice proponía construir y probar herramientas antes de plantear que alguna rama DNS tuviera su fuente principal en el DIT.

La secuencia separaba intención y resultado. Diseñar una herramienta no demuestra que se construyó; iniciar una copia no demuestra que terminó; describir una última fase no prueba que DNS ya hubiera cambiado de autoridad.

Cada etiqueta de dominio podía convertirse en un DomainComponent. La parte local de un buzón RFC 822 prolongaba esa jerarquía como un componente especial. En otra zona del directorio estaban las organizaciones, unidades, personas y funciones.

Los nombres podían parecer relacionados, pero los objetos no eran sustituibles. Un dominio indicaba una posición técnica; una organización tenía existencia y atributos propios. Un buzón servía para dirigir correo, pero no era la persona que podía utilizarlo.

Por eso RFC 1279 consideró inadecuado el aliasing entre ambos árboles. Un alias dice que dos nombres resuelven al mismo objeto. Aquí hacía falta una relación que conservara la diferencia entre los extremos.

La dirección del vínculo también era información

AssociatedDomain partía de la ficha organizativa y nombraba el dominio relacionado. AssociatedName partía del dominio y señalaba una entrada de la rama organizativa.

Guardar ambas direcciones por separado permitía saber qué actor había afirmado cada una y cuándo. La ausencia de vínculo inverso quedaba visible; el sistema no necesitaba fabricar simetría sólo para que la interfaz pareciera completa.

La asociación tampoco garantizaba cardinalidad uno a uno. RFC 1279 explicó que un dominio podía relacionarse con varias organizaciones y una organización con varios dominios. Un campo único de propietario habría borrado ese dato.

La consecuencia probatoria es importante. El vínculo no certificaba propiedad legal, autenticación ni autorización. Que una entrada de dominio apuntara a una organización no demostraba quién operaba cada servicio. Que un buzón apuntara a una persona no verificaba quién había enviado un mensaje.

Una relación fiable conserva predicado, dirección, fuente y vigencia. Si esos elementos se eliminan, la proximidad termina presentada como identidad y la identidad aparente como poder.

Duplicar datos multiplicaba los puntos de fallo

La entrada de dominio podía guardar información que realmente perteneciera al dominio, incluidos sus records DNS. Pero cuando los datos ya residían en la rama organizativa, RFC 1279 recomendaba una ficha relativamente ligera con un puntero. No debía repetirse la información.

Dos copias de un contacto no son dos pruebas. Son dos obligaciones de mantenimiento. Si cambia el responsable y sólo se corrige la ficha de la organización, la copia del dominio conserva aspecto legítimo. Un buscador puede incluso favorecerla porque está más cerca de la consulta.

La repetición añade una ilusión adicional. El mismo dato antiguo repartido entre varios dominios parece corroborado por varias fuentes, aunque todos provengan de una sola copia inicial.

El puntero distribuye mejor la responsabilidad. La organización controla sus atributos descriptivos; el dominio controla la afirmación de que existe una asociación. Una página puede combinar ambos resultados sin trasladar el origen de los datos.

También permite corregir sin daño colateral. Cambiar una relación no exige rehacer la organización. Actualizar un teléfono no obliga a buscar cada dominio que lo reprodujo. El camino de consulta sigue siendo auditable.

El campo TTL no trasladaba el reloj del resolver

RFC 1279 eligió una representación textual para los resource records DNS dentro del directorio. Los nombres tenían que estar completos y todos los records incluían TTL. Un solo atributo DNSRecord permitía aceptar nuevos tipos sin redefinir el conjunto entero.

La información debía ser equivalente a DNS para poder moverse en ambos sentidos. Sin embargo, el directorio OSI no intentaba imitar el caching ni el manejo de TTL de DNS. Las entradas principales se mantenían mediante zone transfer o un mecanismo equivalente.

RFC 1035 definía TTL como el intervalo durante el cual un record podía usarse desde cache antes de volver a consultar la fuente. Ese comportamiento depende del papel del dato, del refresh y del tiempo. Escribir el número en una cadena X.500 no pone en marcha la misma cuenta atrás.

Para conocer la actualidad del valor hacen falta la zona de origen, su versión, el traslado que lo llevó, la recepción completa, la escritura del DSA, los refresh posteriores y la consulta concreta. Un TTL aislado conserva sintaxis, no necesariamente autoridad vigente.

La herramienta tenía permiso sobre una familia limitada

El apéndice propuso una herramienta de transferencia entre servidor DNS y DSA. Al escribir en el DSA, debía dejar intactos los atributos que no fueran records DNS.

La regla impedía que el transportista se convirtiera en dueño de todo el contenedor. Poder actualizar DNS no concedía poder sobre teléfonos, responsables, descripciones organizativas o punteros vecinos.

Una sesión abierta no prueba una transferencia completa. La transferencia no prueba la aceptación de todos los valores. Una escritura DNS no prueba por sí sola que lo demás quedó igual. La consulta posterior no demuestra que alguien actuó.

Por eso deben conservarse estado de zona, solicitud, conjunto recibido, resultado de escritura, estado anterior y posterior de los atributos protegidos, enlaces, respuesta de búsqueda y acción posterior. Reducirlo a una marca de sincronización elimina las preguntas esenciales.

El apéndice describía trabajo futuro

RFC 1279 enumeró un cliente de consulta, una biblioteca, herramientas de zone transfer y de parcheo de vínculos, gestión DNS, descarga de buzones y un servidor DNS emulado. Primero se copiaría parte del espacio DNS a un DSA; después se distribuirían datos, se compararían prestaciones y, en una fase final, quizá se administraría alguna rama desde X.500.

No informó de que esa cadena estuviera terminada ni de que los datos permanecieran frescos, los vínculos fueran completos o los usuarios obtuvieran un servicio equivalente. El estado Experimental limitaba la afirmación pública.

RFC 1309 aporta el contexto general de entradas, atributos y administración local dentro de un directorio distribuido. No convierte el plan de RFC 1279 en despliegue. RFC 1279 tampoco resolvió directamente la seguridad; sólo indicó que X.500 podía ayudar a lograr una gestión más segura. Posibilidad no significa autenticación observada.

Fuentes y límites

RFC 1279 sustenta la representación, el rechazo del alias, los vínculos, la no duplicación, el límite de transferencia y el experimento. RFC 1274 confirma los atributos y clases relacionados. RFC 1035 aporta únicamente el contexto de TTL y zonas DNS. RFC 1309 explica el modelo general de X.500 y la administración local distribuida.

Ninguna fuente prueba un despliegue concreto, propiedad jurídica, identidad autenticada, transferencia terminada, dato actual, búsqueda exitosa, resultado de seguridad o acción de usuario.