Resumen

  • Un borrador individual de agosto de 2026 recomienda responder normalmente a QTYPE ANY con NOTIMP, salvo que exista una razón local concreta para mantener el comportamiento anterior o una respuesta mínima. No es un RFC ni un acuerdo del IETF.
  • El plan operativo debe clasificar las finalidades de los clientes, sustituirlas por consultas de RRtype explícitas o diagnósticos locales controlados y hacer caducar las excepciones. Un error DNS extendido puede explicar el rechazo, pero no demostrar que una aplicación ya ha migrado.

Una consulta de DNS puede ser pequeña y su obligación institucional enorme. El cliente envía un nombre y QTYPE 255. El servidor tiene que decidir qué significa atender “ANY”, qué datos conoce, qué parte de ellos devolver y qué coste asumir. Si además una aplicación interpreta la respuesta como inventario completo, la simplicidad del paquete ha ocultado un contrato que el protocolo no garantiza.

El borrador draft-jabley-dnsop-no-longer-support-any-00, publicado el 6 de agosto de 2026, vuelve sobre esa asimetría. Propone que el comportamiento habitual de los servidores sea devolver RCODE 4, NOTIMP, para ANY. Permite mantener una interpretación conforme a los RFC 1034 y 1035, o las respuestas mínimas del RFC 8482, cuando haya una razón local específica. También plantea un código de error DNS extendido que explique que el servidor no admite esas consultas.

Conviene separar el contenido técnico de su autoridad. Datatracker presenta un Internet-Draft individual activo, sin vía RFC asignada y con estado de existencia del borrador. La cabecera declara una intención de avanzar hacia Standards Track, pero una intención de los autores no equivale a adopción por DNSOP ni a consenso del IETF. Los operadores pueden considerar la recomendación como una propuesta razonada; no deben venderla internamente como mandato ya establecido.

“Todo” nunca fue una respuesta uniforme

Un servidor autoritativo dispone de una visión de su zona. Un resolutor recursivo puede disponer de registros que ha obtenido en momentos distintos. Un intermediario introduce otra frontera. En un corte de zona, una delegación complica qué información pertenece a qué autoridad. El resultado de ANY cambia según el punto al que llegue la pregunta, la implementación y los datos disponibles. Por tanto, la ausencia de un RRset en esa respuesta no demuestra necesariamente su ausencia en el DNS.

El RFC 8482 ya permitió respuestas de tamaño mínimo a ANY. Esa posibilidad institucionalizó un hecho que los clientes prudentes debían reconocer: no se puede depender de una interpretación única en servidores arbitrarios. El nuevo borrador avanza hacia un rechazo explícito como opción habitual, en vez de perpetuar la expectativa de una colección amplia.

Hay razones de seguridad y capacidad. Las respuestas grandes son útiles para determinados ataques de reflexión y amplificación. El RFC 5358 trató el abuso de servidores recursivos expuestos; el RFC 8482 examina las respuestas ANY y sus costes. Ensamblar datos ocupa recursos; una respuesta que crece puede fragmentarse en UDP o provocar trabajo adicional sobre TCP. Ninguna de esas consecuencias es gratuita.

Sin embargo, retirar ANY no elimina toda amplificación DNS. Otras consultas pueden generar respuestas grandes. La exposición de recursión, los controles de capacidad y el resto de la política de servicio siguen siendo asuntos independientes. Tampoco desaparecen, por cambiar el código de respuesta, los motivos legítimos por los que una herramienta antigua hacía la consulta.

La unidad de migración es una decisión del cliente

Un diagnóstico de correo necesita comprobar registros de correo, no pedir una colección indeterminada. Una herramienta de delegación necesita entender NS, referencias y resoluciones de direcciones pertinentes. Un protocolo de descubrimiento debe consultar los tipos que define su diseño. Una inspección de caché requiere una superficie diagnóstica autorizada, con alcance y antigüedad conocidos; ANY desde fuera nunca fue una ventana exhaustiva a un resolutor.

Estas finalidades exigen alternativas distintas. Sustituir una consulta por todas las clases de registros que un programador recuerde puede aumentar el tráfico sin mejorar la corrección. El objetivo no es reproducir una respuesta voluminosa. Es obtener la información mínima que permite tomar la decisión prevista.

También existen consumidores difíciles. Un binario sin mantenimiento puede interpretar NOTIMP como fallo total. Un procedimiento de soporte puede tener una captura ANY como paso obligatorio aunque nadie sepa qué demuestra. Un cliente puede seguir funcionando durante semanas con datos almacenados y fallar solo tras un cambio de delegación. Cada caso requiere propietario, análisis y un destino; no justifica por sí mismo una excepción abierta al público.

Antes del cambio, el operador debería observar una ventana acotada de tráfico y formar un registro de finalidades. Conservar todos los nombres de forma indefinida no es necesario ni proporcionado. Pueden bastar el servicio receptor, la categoría de origen, una identidad interna cuando exista, periodicidad, transporte y tamaño de respuesta, con minimización y acceso restringido. La observación debe servir para atribuir dependencias, no para convertir una retirada técnica en vigilancia general.

Para cada grupo recurrente, el registro debe explicar qué decisión consume la respuesta, qué versión del cliente la produce, quién puede modificarlo y qué ocurre hoy ante una respuesta incompleta. Esta última prueba suele ser reveladora: el cliente quizá ya depende de una coincidencia entre servidor, caché y momento. La migración no destruye entonces una garantía; obliga a reconocer que nunca la hubo.

Cinco destinos, no una casilla de compatibilidad

El primer destino es reemplazar. Se documenta el RRtype o la interfaz específica, se despliega la versión del cliente y se prueba la decisión completa. El segundo es retirar un uso que nadie necesita, eliminando la llamada y observando los ciclos en los que podría reaparecer. El tercero es restringir un diagnóstico legítimo a una vía local autenticada o a un ámbito de red controlado.

El cuarto es una excepción temporal. Debe tener responsable, población, nombres o ámbito pertinentes, motivo, control compensatorio y vencimiento. Si el software no puede modificarse, se necesita un programa de sustitución del activo. Una fecha que se renueva automáticamente no es una retirada; es una política permanente sin admitirlo.

El quinto destino es “desconocido”. No debe desaparecer del informe. Puede tratarse de un escáner, un socio no inventariado o un sistema olvidado. El operador no tiene que conservar una semántica pública ambigua para cualquier fuente desconocida, pero la autoridad que acepta el riesgo debe saber qué queda sin atribuir. Silencio no significa inocuidad y falta de dueño no equivale a ausencia de dependencia.

Con esa clasificación, el despliegue se divide por poblaciones. Los clientes gestionados y corregidos reciben el nuevo comportamiento; un grupo limitado puede conservar provisionalmente el anterior. La política autoritativa pública y el diagnóstico interno no necesitan una excepción idéntica por usar el mismo programa. La razón de la diferencia debe ser específica y comprobable.

El rechazo informa de una frontera, no del progreso

Un NOTIMP observado demuestra que el servidor rechazó la consulta en ese contexto. No identifica lo que el cliente pretendía hacer. Un resolutor, un reenviador o un cambio de destino puede influir en la respuesta final. El cliente puede repetir la consulta o esconder el motivo detrás de un error genérico. La contabilidad de rechazos es útil para localizar concentraciones, pero no permite certificar por sí sola una migración.

El RFC 8914 define EDE para añadir explicación sin cambiar el procesamiento del RCODE. Puede haber varios errores extendidos. El tratamiento por intermediarios depende de las implementaciones. El texto adicional es opcional, destinado a personas y susceptible de eliminarse cuando hay presión de tamaño. No es un campo de control estable que un cliente deba interpretar como instrucción.

La explicación propuesta para ANY podría ahorrar tiempo a soporte: un rechazo deliberado dejaría de parecer una avería inexplicable. Pero el plan no debe depender de que una frase concreta llegue intacta. No corresponde seleccionar RRtypes analizando una oración en inglés. Tampoco corresponde marcar un sistema como corregido porque ya muestra esa oración en su pantalla.

La prueba real combina despliegue y resultado. ¿Se ejecuta la versión prevista? ¿Hace las consultas explícitas? ¿Sigue tomando correctamente la decisión autorizada? ¿Ha dejado de solicitar ANY incluso al vencer el caché o cambiar la topología? EDE ilumina el borde del servicio; estas pruebas demuestran que el consumidor puede vivir al otro lado.

La transición necesita casos incómodos

Enviar ANY y comprobar RCODE 4 es una prueba de servidor, no una prueba de negocio. El nuevo diagnóstico de correo debe manejar la ausencia de MX que corresponda a su lógica. La comprobación de delegación debe distinguir referencias de respuestas autoritativas y resolver direcciones de forma deliberada. El cliente de descubrimiento debe obtener todos los RRsets requeridos por su protocolo, y no una combinación oportunista de lo que haya en caché.

Añádanse truncamiento, demora de TCP, fallos de validación DNSSEC, respuestas parciales y caminos con reenviadores. Los servidores autoritativos y recursivos no son intercambiables. Si conviven clientes antiguos y nuevos, deben medirse por separado; la mayoría corregida puede ocultar una minoría que sostiene un proceso crítico.

Finalmente, obsérvense los ciclos lentos: conmutación, recuperación de contingencia, cambios de zona y reactivación de equipos poco usados. Una aplicación que no ha consultado todavía no ha demostrado adaptación. La ventana de cierre pertenece al propósito, no al calendario del equipo que desplegó el rechazo.

Fuentes

  1. Registro actual del borrador
  2. Historial del borrador
  3. Revisión 00 en HTML
  4. Revisión 00 en texto
  5. XML de la revisión 00
  6. Mandato de DNSOP
  7. Documentos de DNSOP
  8. RFC 1034: conceptos del DNS
  9. RFC 1035: especificación del DNS
  10. RFC 6895: parámetros DNS e IANA
  11. RFC 8482: respuestas mínimas a ANY
  12. RFC 8914: errores DNS extendidos
  13. RFC 5358: servidores recursivos y ataques de reflexión
  14. RFC 9364: seguridad y operación del DNS
  15. RFC 9499: terminología DNS
  16. RFC 7766: DNS sobre TCP
  17. Parámetros DNS de IANA
  18. Códigos EDE de IANA
  19. Lu Heng: especificación inicial mínima y decisión local
  20. Lu Heng: el espejo de la política