Resumen

  • RFC 3425 retiró para siempre el opcode DNS 1, IQUERY, y señaló que el servidor debía contestar Not Implemented; esa respuesta hablaba de la operación, no de la existencia de un nombre.
  • El DNS inverso siguió mediante registros PTR explícitos y delegados. NOTIMP, NXDOMAIN, NODATA, una respuesta PTR y su validación DNSSEC son comprobantes distintos.

La operación terminó antes de buscar un nombre

RFC 3425, publicado en noviembre de 2002, declaró IQUERY totalmente obsoleto y sustituyó la sección 6.4 de RFC 1035. Ante un paquete con opcode 1, el servidor debía responder Not Implemented.

Ese resultado puede demostrar cumplimiento. No demuestra que el servidor recorrió sus zonas, que consultó un owner name, que obtuvo NXDOMAIN ni que faltaba un PTR. El mensaje resolvió primero una cuestión de capacidad normativa: esta operación ya no se ofrece.

Por eso la etiqueta genérica «no encontrado» es incorrecta. Borra el objeto exacto del rechazo.

IQUERY convertía el valor en índice local

El diseño de RFC 1035 colocaba un valor de Resource Record en la sección answer de la consulta. El servidor devolvía tuplas de tipo, nombre y clase que coincidieran en su base. No era una consulta a un nombre PTR en in-addr.arpa.

Para responder, una implementación debía buscar de forma exhaustiva o conservar un índice adicional por valores. RFC 1035 ya advertía el coste. RFC 3425 explicó su escala: un servidor con millones de nombres podía producir respuestas de megabytes.

Buscar todos los dominios delegados a un nameserver de un gran ISP podía devolver decenas de miles de tuplas. La amplificación no era una prueba de un ataque real, pero sí una superficie de diseño: una entrada pequeña provocaba trabajo y salida masivos, exponía bloques de nombres y activaba código poco usado.

El servidor contactado no era una autoridad universal

Una consulta DNS normal usa el nombre para recorrer delegaciones. IQUERY dependía de la base del servidor elegido. Si la información vivía en otra autoridad, la operación no sabía indicar al cliente dónde buscarla.

Dos servidores con datos diferentes podían producir listas diferentes. Un servidor podía rechazar IQUERY aunque conservara RRsets relacionados. Por tanto, el resultado no autorizaba la frase «estos son todos los nombres asociados al valor».

Invertir una base concreta y consultar un espacio de nombres delegado son operaciones con poderes distintos.

PTR formuló una pregunta encaminable

El enfoque operativo fue publicar el mapeo inverso como datos DNS normales. Para IPv4 se forma un owner name bajo in-addr.arpa y se solicita PTR. RFC 1033, RFC 1034 y RFC 1035 describen el modelo; RFC 2317 muestra que hasta los bloques menores que /24 necesitan una delegación explícita.

PTR no promete cobertura completa ni identidad real. Sí permite registrar nombre consultado, delegación, servidor autoritativo, TTL y estado DNSSEC. Si la entrada falta, los mecanismos negativos del DNS pueden expresarlo en su propio contexto.

La mejora fue la trazabilidad de la pregunta, no una garantía de que todas las direcciones tengan un nombre fiable.

No toda ausencia aparente es NXDOMAIN

NOTIMP significa que el respondedor no implementa la operación. NXDOMAIN se refiere a la inexistencia del owner name. NODATA separa un nombre existente del tipo pedido. Timeout solo dice que la ventana de observación terminó sin una respuesta aceptable.

RFC 8020 amplió el uso de NXDOMAIN autoritativo, sin convertir el rechazo de un opcode en inexistencia. RFC 8499 ayuda a mantener la terminología.

Después de NOTIMP para IQUERY, el cliente debe construir la pregunta PTR adecuada. Después de NXDOMAIN conserva autoridad y caché negativa. Después de un fallo de validación conserva ese fallo. Cada estado reclama una acción diferente.

El número retirado no quedó libre

RFC 3425 cambió la definición del opcode 1 a IQUERY obsoleto y pidió su retiro permanente. El registro IANA de parámetros DNS y RFC 6895 mantienen la reserva.

Reutilizar el número volvería ambiguos los paquetes históricos. La retirada protege el significado anterior y marca una capacidad negativa: ninguna extensión futura debe ocupar ese patrón. Pero el registro no certifica que no quede código antiguo activo; especificación, binario, configuración y tráfico observado son capas separadas.

DNSSEC necesitaba datos nombrados

RFC 3425 indicó que asegurar respuestas IQUERY con DNSSEC sería muy difícil sin firmar al vuelo. Una lista sintetizada al invertir valores no es un RRset preparado en un owner name.

RFC 4033, RFC 4034 y RFC 4035 organizan la validación alrededor de datos DNS explícitos y pruebas negativas. Un PTR validado respalda una afirmación de la zona; no prueba por sí solo asignación, control del host, coincidencia directa, alcance, autenticación o éxito de servicio.

El NOTIMP de IQUERY tampoco se convierte en negación autenticada por estar dentro de un mensaje DNS.

El error útil conserva su sujeto

RFC 3425 no eliminó el DNS inverso. Cerró una inversión local, costosa y difícil de atribuir, mientras mantenía el camino PTR delegado.

La lección histórica consiste en preguntar de qué habla cada recibo. El opcode rechazado habla de operación; NXDOMAIN habla de nombre; PTR habla de datos; DNSSEC habla de validación; una conexión posterior habla de servicio. El sistema que conserva esa cadena puede usar un rechazo correctamente. El que solo guarda un campo vacío fabrica una ausencia.

Fuentes y límites

El expediente primario incluye RFC Editor HTML, texto, información RFC Editor, documento Datatracker, historial, referencias y erratas. El contexto procede de RFC 1033, RFC 1034, RFC 1035, RFC 2317, RFC 6895, RFC 8499, RFC 4033, RFC 4034, RFC 4035, RFC 8020 y el registro IANA. El marco para separar símbolos y operación sigue a Heng Lu sobre capas de realidad y primacía del código en ejecución.

Las fuentes no prueban despliegue actual, servidor vulnerable identificado, ataque medido, cobertura PTR completa, identidad, alcance, autorización ni resultado de aplicación.