Resumen

  • RFC 3467 sostuvo que el DNS se diseñó para resolver identificadores exactos y únicos de recursos de red, no para deducir personas, productos o documentos desde una consulta imprecisa.
  • Su «capa de búsqueda» era una separación arquitectónica: producir candidatos primero y resolver después el nombre elegido, no un protocolo terminado ni una implantación demostrada.

Una descripción no es una clave

«La librería que está junto a la plaza» puede ser suficiente para preguntar a un vecino. El vecino compara contexto, corrige una palabra y quizá ofrece tres lugares. Para un resolvedor DNS, esa frase no es una clave. Necesita un nombre construido y un tipo de registro; después recorre una jerarquía distribuida. Su función comienza donde la ambigüedad ya debería haber terminado.

Ese límite es el centro de RFC 3467, el documento informativo de John Klensin sobre la función del DNS. El texto de 2003 no presentó una solución lista para usar. Declaró que su marco era una invitación a pensar con mayor amplitud. Incluso su relato histórico llevaba una reserva: muchas decisiones tempranas quedaron poco documentadas, por lo que aquella reconstrucción era una interpretación entre varias posibles.

Tampoco anunciaba una avería de rendimiento. El documento decía que la fiabilidad seguía dentro de márgenes aceptables y que había pocas señales de degradación grave. El problema era otro: se estaban acumulando funciones ajenas al diseño original. Utilizar el DNS porque ya existía podía resolver la distribución de una nueva base de datos, pero no garantizaba que su estructura, reglas de comparación o modelo de autoridad fueran adecuados.

Del fichero de hosts a un sistema distribuido

Antes del DNS, una tabla de hosts se copiaba y actualizaba con frecuencia. Los nombres evitaban memorizar direcciones numéricas, podían mantenerse mientras cambiaba la topología y admitían que un host tuviera varias direcciones. Cuando aquel fichero dejó de escalar, el DNS conservó nombres únicos y no ambiguos, distribuyó la administración y la consulta y permitió incorporar nuevos tipos de registros.

La flexibilidad no convirtió la herramienta en un directorio de todo. Según RFC 3467, su objetivo principal eran los recursos de red, no las personas, las marcas, los productos o los objetos documentales. El formato podía transportar datos binarios, pero las aplicaciones imponían convenciones mucho más estrechas. La capacidad de almacenar un valor no implica capacidad para descubrirlo desde una descripción humana.

De ahí la expresión «base de datos de conveniencia». La ubicuidad del DNS reducía el coste inicial de cada uso nuevo. A cambio, las aplicaciones heredaban una jerarquía rígida, una comparación exacta, cachés y una superficie de autoridad pública que podían no coincidir con el problema.

Buscar exige admitir más de una posibilidad

Una consulta DNS termina en coincidencia o no coincidencia según reglas delimitadas. Una búsqueda puede necesitar errores ortográficos, variantes culturales, grafías distintas, atributos, proximidad y una lista ordenada de resultados. También puede preguntar por el valor de un registro, no por su nombre. RFC 3467 reunió ejemplos de esa presión: nombres de compañías y productos, muchos nombres para un solo host, respuestas ajustadas al usuario, información personal con permisos e internacionalización.

La preparación de cadenas internacionalizadas no anulaba la diferencia. Puede normalizar ciertos caracteres antes de comparar dos identificadores; no puede saber qué objeto tenía en mente una persona. La normalización produce una forma determinista. La búsqueda aproximada conserva alternativas y necesita contexto y elección. Pedir a la resolución que haga ambas cosas oculta una decisión humana dentro de un resultado técnico.

El antiguo IQUERY mostró otra limitación. Se ideó para localizar nombres asociados a un valor de registro y acabó obsoleto tras escasa implantación y problemas operativos. Ello no eliminó consultas específicas como la resolución inversa de direcciones. Confirmó que el DNS no era una interfaz general para recorrer cualquier relación almacenada.

Primero descubrir, después resolver

El marco de RFC 3467 colocaba una capa de búsqueda o directorio antes del DNS. Esa capa podía aceptar una expresión ambigua, utilizar idioma, país y otros atributos y devolver varios nombres candidatos. Solo tras escoger uno se realizaría la consulta DNS exacta.

La separación obligaba a mantener pruebas diferentes. Un resultado de búsqueda acredita una coincidencia bajo un índice, unas reglas y una fecha. Una respuesta DNS acredita registros obtenidos para un nombre en un contexto de resolución. El candidato mejor clasificado puede corresponder a otra entidad; un registro válido puede conducir a un servicio caído; una conexión puede completarse sin demostrar que la elección inicial fue la prevista.

El directorio tampoco era neutral. Su índice podía quedar anticuado, su ordenación favorecer a quien pagara y sus reglas locales variar entre usuarios. El documento advertía que debía protegerse contra cambios no autorizados y que cada sistema adicional creaba nuevos riesgos. Separar funciones hacía visible la autoridad, pero no la eliminaba.

El resultado histórico fue una frontera

RFC 3467 no definió el protocolo del directorio, no documentó su despliegue y no demostró una transición. Su aportación fue distinguir dos preguntas. El espacio común de Internet necesita identificadores exactos y estables. Las personas necesitan herramientas tolerantes para encontrarlos.

Por eso el registro operativo debe conservar la consulta y su contexto, los candidatos, la selección, el nombre DNS exacto, el contexto del resolvedor, la respuesta, el destino y el resultado de la aplicación. Una respuesta exacta demuestra que una clave se resolvió. No demuestra que aquella clave representaba la intención del usuario.

Fuentes