Resumen

  • La RFC 3663 calculó que una representación LDAP no normalizada podría convertir un conjunto relacional de unos 20 millones de objetos en más de 115 millones de objetos de directorio.
  • Las referencias prometían conservar relaciones y límites operativos. Las diferencias entre clientes y los bucles de referencias llevaron al piloto a un backend normalizado con una vista adaptada; aun así, los clientes debían conocer la estructura del directorio.

El árbol de datos se diseñó dos veces

Un dominio no vive aislado. Puede tener varios contactos y servidores de nombres, y un mismo servidor puede dar servicio a muchos dominios. Además, el registro y el registrador no mantienen exactamente las mismas responsabilidades administrativas. Si cada relación se copia dentro de un árbol, las entidades compartidas pueden repetirse una y otra vez.

Publicada en diciembre de 2003 como documento experimental, la RFC 3663 describe el servicio Referral LDAP de VeriSign, un piloto para explorar LDAP como vía de consulta de información administrativa de dominios. La estimación de diseño fue contundente: una base relacional de unos 20 millones de objetos podía crecer a más de 115 millones en un DIT no normalizado. La RFC no presenta esa cifra como resultado de un despliegue de ese tamaño; era una estimación que obligaba a pensar en la escala antes de elegir el modelo de directorio. RFC 3663

El proyecto se insertaba en una historia previa. El contrato original de InterNIC había previsto un directorio X.500 para los datos administrativos de dominios. Las dificultades con las implementaciones de servidores disponibles dieron paso a un servicio temporal NICNAME/WHOIS. RWhois intentó ampliar ese enfoque, aunque la RFC dice que no obtuvo una aceptación amplia para esos datos. Referral LDAP perseguía algo más acotado: consultas y resultados estructurados, mejor lectura automática y una ruta desde la información del registro hasta el servicio del registrador apropiado, en un momento en que se separaban esas funciones. RFC 954 RFC 2167 RFC 3663

Las referencias trasladaron la complejidad

El primer diseño de DIT utilizaba referencias internas entre el árbol de dominios de nivel superior y los árboles de servidores de nombres y contactos. Así se evitaba duplicar cada relación y se abría la posibilidad de distribuir los datos entre servidores. Pero una referencia LDAP no es otra fila: el cliente debe decidir si la sigue, cómo conserva el sentido de la búsqueda y qué hace con la respuesta recibida después.

Las pruebas con ldapsearch mostraron interpretaciones y tratamientos inconsistentes. Algunos clientes podían entrar en bucles. La solución final fue un backend personalizado que conservaba los datos normalizados y ofrecía a los clientes una vista desnormalizada, sin referencias internas entre servidores. La RFC considera probable que un conjunto grande necesitara ese backend a medida; uno pequeño podía funcionar con software estándar. Los vínculos entre registros no desaparecieron: cambió el componente que debía reunirlos. RFC 3663

Las referencias entre servidores cumplían otra función: representaban que el registro y el registrador podían operar en organizaciones, equipos o redes diferentes. Sin embargo, una búsqueda podía devolver referencias ajenas al filtro especificado hasta llenar el límite habitual de 50 resultados. El usuario podía recibir una lista de destinos en lugar de los datos esperados. El memorando describe esto como una dificultad para distribuir las consultas, no como prueba de que LDAP fuera defectuoso. RFC 3663 RFC 2251

Un protocolo genérico no daba un cliente universal

LDAP aportaba un protocolo común, pero las aplicaciones gráficas dependían de conocer el DIT y el esquema concretos del servicio. No podían conectarse sin cambios a otro directorio LDAP y aprovecharlo por completo. Un cliente universal que ocultara cada diferencia estructural tendría que renunciar a parte de la información o volverse demasiado complejo para el usuario corriente. RFC 3663

La dificultad también era de presentación. La RFC observó que algunos usuarios creían que el cliente web era la única puerta de acceso; el protocolo LDAP y el modelo registro–registrador–titular resultaban difíciles de explicar en los resultados. Las bibliotecas C y Java permitían consultas anidadas y seguimiento avanzado de referencias, pero muchos tropiezos de los clientes eran de usabilidad. El documento admite que no podía medir con precisión la popularidad de cada interfaz. Son observaciones del piloto, no una encuesta representativa. RFC 3663

También había que limitar el coste y la extracción de datos. El servicio permitía solo ciertos tipos de búsqueda porque cualquier consulta LDAP expresable podía ser demasiado costosa en una plataforma pública. Aun así, los usuarios preguntaban por consultas recursivas de diccionario para eludir las restricciones; muchos operadores de WHOIS consideraban esa práctica minería de datos. La sección de seguridad advierte expresamente que la autenticación demostrada mediante nombre distinguido y contraseña no debía servir como modelo de producción. RFC 3663 RFC 2026

La lección fue dónde colocar el trabajo

La importancia histórica de RFC 3663 está en lo que admite sobre los compromisos. Un protocolo de directorio común no garantizaba una experiencia portable. La normalización reducía la multiplicación de objetos, pero un backend a medida tenía que construir la vista que necesitaban los clientes. Las referencias preservaban la separación entre operadores, aunque su utilidad dependía del comportamiento del cliente, los límites de consulta y las responsabilidades de cada nivel.

El documento señalaba que toda búsqueda empezaba en el registro incluso si la consulta podía dirigirse a un registrador o titular. El piloto no implementó la localización mediante DNS SRV o NAPTR. Su sondeo de servidores LDAP estaba delimitado: cuatro archivos de zona, pruebas del puerto 389 en los nombres de dominio y en hosts ldap o dir, sin búsqueda SRV. El cálculo de que cerca del 0,5 % de los dominios activos del conjunto tenía un servidor LDAP no constituye un censo de Internet ni describe el presente. RFC 3663

La decisión no era simplemente entre un árbol y una base relacional. Había que decidir quién traduciría entre el registro relacional, la vista del directorio, el destino de una referencia y la pregunta del usuario. El piloto concentró parte de esa carga en un servidor especializado y clientes conscientes de la estructura, en lugar de repetir millones de objetos o depender de cadenas frágiles de referencias. LDAP hacía reconocibles las piezas; no aportaba por sí solo el mapa.

Fuentes