Resumen

  • IQUERY invertía el mensaje DNS ordinario: entregaba un resource record en Answer y esperaba que el servidor devolviera sus owner names en Question.
  • Como la autoridad de DNS seguía el árbol de nombres, no los valores arbitrarios de RDATA, la respuesta quedaba limitada a las coincidencias conocidas por un servidor y no podía acreditar exhaustividad global.
  • Los recorridos completos, índices auxiliares, problemas de caché, respuestas enormes y exposición de datos encarecieron una promesa ya débil; PTR bajo IN-ADDR.ARPA convirtió la inversión de direcciones en una consulta normal con delegación.

El mensaje llevaba la respuesta antes de formular la pregunta

Una query habitual coloca QNAME, QTYPE y QCLASS en Question. La respuesta añade los RR solicitados. IQUERY partía de una estructura extraña: Question estaba vacío y Answer contenía algo como A IN 10.1.0.52. El cliente pedía todos los nombres para los cuales ese dato sería una respuesta.

RFC 1035 asignó a esta operación el opcode 1. El owner name y el TTL del RR aportado no eran significativos; podía usarse la raíz como marcador mínimo. Al responder, el servidor incorporaba cero, uno o varios conjuntos QNAME, QTYPE y QCLASS en Question y ajustaba el registro inicial a la primera coincidencia.

La forma hacía visible una reciprocidad matemática. Una operación vinculaba un nombre con un recurso; la otra buscaba nombres a partir del recurso. El formato de DNS podía alojar las dos direcciones.

La arquitectura distribuida no tenía la misma reciprocidad. Un nombre permite seguir referrals desde la raíz y localizar la zona responsable. Una dirección, un destino MX o una cadena guardada en otro RR no contiene una ruta equivalente hacia todas las zonas donde podría aparecer. La query inversa exigía elegir primero un servidor sin poder descubrir si era el adecuado.

La primera especificación ya reconocía el límite

RFC 882 explicó en 1983 que el domain system no podía garantizar ni completitud ni unicidad en las inverse queries. El sistema estaba organizado por domain name, no por host address ni por otros tipos de recursos. Quien necesitara una garantía debía usar un servidor conocido por poseer los datos pertinentes o consultar todos los servidores del dominio de interés.

No era solo una concesión a equipos lentos. Era la ausencia de una regla para encaminar autoridad. Las delegaciones forman parte del espacio de nombres y permiten acercarse paso a paso a quien responde por un QNAME. Para un valor arbitrario no existía un padre que indicara el siguiente servidor ni un límite natural para un resultado negativo.

RFC 883 trató por ello la operación como dependiente del entorno. Un administrador podía indicar a su resolver qué servidores disponían de copias amplias de sus propias zonas. El instrumento resultaba útil para administración o diagnóstico, pero no adquiría jurisdicción sobre el namespace completo.

La diferencia importante no separa verdad y mentira, sino exactitud local y exhaustividad. Un servidor puede devolver tres relaciones verdaderas. Una cuarta puede vivir en una zona desconocida. La honestidad acerca de la copia visible no concede autoridad para negar lo que queda fuera.

El alcance real era lo que supiera el servidor elegido

RFC 1035 define la respuesta con una cautela decisiva: contiene los nombres que poseen el RR y que el name server conoce. Ninguna máquina conoce todo el domain space, por lo que el resultado nunca debe presumirse completo. El documento limita IQUERY a gestión y depuración y rechaza expresamente su uso general para pasar de una host address a un host name.

Cero coincidencias significaban que el servidor consultado no halló ninguna en su corpus. No significaban inexistencia global. Una coincidencia demostraba una asociación visible, no su unicidad. Miles de coincidencias podían seguir reflejando únicamente las zonas autoritativas locales, datos incidentales de caché o los RR types para los que existía un índice.

Una respuesta negativa normal tiene un contorno diferente. El nombre consultado identifica una zona autoritativa y permite negar su existencia dentro de ese espacio. IQUERY no definía el conjunto universal de lugares en los que un valor podía aparecer. Para probar ausencia habría que excluir cada zona posible.

Por eso, una lista de resultados necesita algo más que filas correctas. Debe conservar qué universo se examinó, quién lo controla, cuándo se observó y cómo se localizan las particiones omitidas. Sin ese contexto, una lista bien ordenada parece una afirmación más amplia de la que sus datos sostienen.

El índice inverso era otra base de datos

Los name servers almacenan naturalmente los RR bajo owner names porque la query común comienza por QNAME. Resolver rápidamente una búsqueda por RDATA requiere otro camino de acceso.

RFC 883 describía tablas de inversión separadas por zona y clave. Cada actualización podía obligar a reconstruirlas. RFC 1035 planteaba dos alternativas: una búsqueda exhaustiva de la base o una base auxiliar indexada por los valores de la principal. La primera consumía recursos por solicitud; la segunda exigía memoria, coherencia y mantenimiento continuo.

Tampoco existía una única comparación. RDATA puede contener direcciones, domain names, character strings o estructuras específicas del tipo. RFC 1035 pedía comparaciones sin distinguir mayúsculas cuando fuera posible, pero admitía que un servidor podía conservar octetos sin saber que representaban texto. La búsqueda por valor incorporaba semántica de cada RR.

El reparto de incentivos era incómodo. El solicitante enviaba un valor breve; el operador pagaba el índice, el scan, el ensamblaje y la transferencia. El mensaje no probaba que el trabajo beneficiara al administrador de la zona y no imponía por delegación un límite al tamaño del resultado.

Publicar records individuales para resolución interoperable no equivale a ofrecer análisis arbitrario de todo su contenido. IQUERY añadía ese servicio a la misma infraestructura que ya custodiaba datos operativos.

Repetir una vista en caché no ampliaba su autoridad

DNS escala porque los resolvers reutilizan RRsets hasta el TTL. Los resultados de IQUERY no encajaban bien en esta lógica. RFC 1035 advertía que no podían guardarse mediante el mismo mecanismo que las respuestas estándar.

Un host multihomed puede tener varios RR de dirección del mismo tipo. Encontrar su nombre mediante una sola dirección no revela necesariamente el conjunto entero. Si la caché guarda la relación extraída como si fuera el RRset completo asociado al QNAME reconstruido, convierte una selección por valor en una afirmación por nombre.

También desaparece el corpus original. La respuesta pudo venir de unas zonas y de un cache parcial de una máquina concreta. Tras varias réplicas, el consumidor ve el dato, pero no las partes del namespace que nunca se consultaron. La difusión abarata la repetición sin crear completitud.

En una query normal se alinean lookup key, delegación, autoridad, cache key y TTL alrededor del nombre. IQUERY reutilizaba el sobre, pero rompía esa alineación. Cada optimización debía transportar una advertencia que los sistemas tienden a perder: esto es solo lo que ese servidor sabía en ese momento.

PTR convirtió la relación inversa en un nombre delegable

La alternativa extendida para direcciones no fue un buscador global mejor. RFC 1034 describe IN-ADDR.ARPA, donde los octetos de una IPv4 aparecen en orden inverso bajo un dominio especial. El owner name resultante puede contener un PTR que apunta a otro domain name.

Para 10.1.0.52, el resolver construye un nombre predecible en el árbol inverso y ejecuta una consulta estándar. Las ramas pueden delegarse, los servidores autoritativos pueden localizarse, el RRset conserva un TTL normal y una negativa tiene significado dentro de una zona identificada.

La indirection es la solución, no un rodeo accidental. PTR no promete que toda dirección tenga registro, que exista un solo nombre o que el nombre autentique una máquina. Hace algo más limitado: ubica la declaración inversa bajo un owner name para el cual DNS ya posee reglas de autoridad.

IQUERY pedía descubrir un índice desconocido a partir del valor. PTR exige que quien administra reverse space publique una relación explícita en una posición conocida. La búsqueda abierta se transforma en recuperación delegada.

La operación era débil para quien necesitaba certeza y valiosa para quien buscaba coste

En 2002, RFC 3425 declaró IQUERY completamente obsoleto. No se había implementado de forma general y los operadores solían deshabilitar el soporte antiguo. El texto menciona código poco ejercitado, fallos, carga del servidor y exposición de grandes bloques de nombres.

Algunos valores podían coincidir con conjuntos enormes. Una consulta para hallar todos los dominios delegados al nameserver de un gran proveedor podía devolver decenas de miles de triplets y ocupar megabytes. Una solicitud pequeña provocaba cálculo, memoria y tráfico desproporcionados, útiles para denegación de servicio.

Las inverse MX queries permitían agrupar muchos nombres que compartían infraestructura de correo. Que cada RR sea públicamente recuperable no significa que el operador haya ofrecido un catálogo masivo por cualquier dimensión. IQUERY reducía el coste de agregación y trasladaba ese coste al servidor.

La paradoja era clara. El cliente honesto quería una lista completa y no podía obtenerla. El abusador solo necesitaba gastar recursos o recoger una parte amplia del corpus local; la incompletitud no impedía ninguno de esos objetivos.

Retirar el número evitó una segunda ambigüedad

RFC 3425 no recicló el opcode 1. Sustituyó la sección de RFC 1035, marcó la operación como obsolete, indicó que los servidores deberían responder Not Implemented y pidió retirar permanentemente el valor.

Reasignarlo habría permitido que software antiguo interpretara tráfico nuevo con la semántica abandonada. La reserva perpetua conserva una historia inequívoca y elimina la expectativa de servicio sin crear una colisión futura.

El documento señalaba además que no se conocían clientes que dependieran de IQUERY para un servicio significativo y que PTR bajo IN-ADDR.ARPA llevaba años sirviendo al reverse mapping común. La retirada respetaba las dependencias reales: no suprimía un camino público vivo.

DNSSEC hacía visible otro límite. RFC 3425 advertía que asegurar respuestas IQUERY era extremadamente difícil sin firmarlas al vuelo. Una zona firmada autentica RRsets nombrados y negativas dentro de una estructura de nombres. Una búsqueda arbitraria tendría que demostrar también que no omitió coincidencias dentro de un universo que IQUERY nunca delimitó.

Un servidor era testigo, no todo el espacio de nombres

Un name server puede participar realmente, ser autoridad para zonas y conservar información exacta. Esas condiciones lo convierten en testigo de un perímetro definido. La capacidad de registrar coincidencias en su copia no lo convierte en principal de los nombres ausentes que compartan el mismo valor.

Las notas de Lu Heng separan participación de autorización y administración de registros de autoridad sobre aquello que describen. IQUERY muestra la misma frontera dentro del protocolo. Ver datos permite informar sobre lo visto; no concede permiso para hablar por las zonas que no estaban presentes.

La reparación no consistió en levantar un catálogo central más grande. DNS conservó una capa común reducida: nombres, delegaciones, RR types, TTL y relaciones inversas publicadas explícitamente. Cada participante declara dentro de una zona acotada y cada resolver puede seguir reglas compartidas sin coronar a un intermediario omnisciente.

Límites de la evidencia

Los cinco RFC prueban el formato, los límites conocidos, la alternativa PTR y la decisión de obsolescencia. No miden el tráfico opcode 1 actual, no catalogan todas las implementaciones históricas y no descartan usos diagnósticos privados.

NOTIMP es la respuesta normativa esperada, no prueba de que el paquete nunca fue analizado. Un timeout puede provenir de filtrado o pérdida. Una respuesta positiva acredita procesamiento local, no cobertura global.

PTR tampoco es una credencial de identidad. Los datos forward y reverse pueden faltar, discrepar o ser múltiples. La ventaja aquí es poder localizar responsabilidad por una declaración, no garantizar la corrección automática de toda declaración.

IQUERY ofreció una dirección para preguntar sin una dirección hacia la autoridad. Un bit podía invertir el mensaje, pero no las delegaciones de un sistema distribuido. DNS se hizo más sólido cuando retiró esa simetría y colocó las relaciones inversas otra vez bajo nombres.

Fuentes