Resumen

  • RFC 10029 mantiene una pregunta DNS principal y transporta QTYPE adicionales en EDNS. La opción de respuesta enumera únicamente los tipos extra procesados de forma completa con el mismo RCODE y las mismas banderas que la respuesta principal.
  • Un paquete no es una fotografía atómica. Los tipos omitidos requieren consultas independientes, y los RRsets incluidos pueden proceder de zonas, firmantes, TTL y momentos de caché diferentes antes de que la aplicación elija qué usar.

La optimización parece trivial: si el cliente necesitará A, AAAA y HTTPS, ¿por qué no pedir los tres de una vez? El problema aparece cuando la respuesta cabe sólo en parte o cuando uno de los tipos no puede compartir el mismo estado de cabecera. El paquete llega sin truncamiento y la métrica de red marca éxito. La aplicación, sin embargo, todavía no sabe todo lo que declaró necesitar.

RFC 10029, norma publicada en julio de 2026, define una respuesta explícita a ese problema. No introduce varias preguntas ordinarias. RFC 9619 establece que una consulta con opcode QUERY no puede tener QDCOUNT mayor que uno; si lo tiene, es un mensaje mal formado. El nuevo mecanismo conserva el QNAME, QCLASS y QTYPE principal y añade una lista de tipos de datos mediante EDNS.

La arquitectura mantiene visible cuál es la pregunta que gobierna la cabecera. Los demás tipos son combinaciones adicionales que pueden o no completar su propio resultado.

La lista solicitada no es la lista entregada

El cliente expresa los tipos extra en MQTYPE-Query, código 20. El servidor responde con MQTYPE-Response, código 21. El registro de parámetros DNS de IANA identifica ambas opciones como facultativas y remite a RFC 10029.

La diferencia entre los dos códigos evita una ambigüedad peligrosa. Un intermediario que repite ciegamente una opción de entrada no puede fabricar la apariencia de una lista de salida. La pregunta principal y los valores presentes en la opción de respuesta forman el recibo de lo completamente contestado.

Una opción de respuesta vacía sigue siendo información válida: el servidor entendió el mecanismo, pero no terminó ningún tipo adicional. Si la opción no aparece, si vuelve por error la opción de consulta o si hay valores duplicados, el cliente debe tratar la extensión como no soportada o inválida y volver a consultas normales.

Tampoco puede sustituirse por ANY. RFC 8482 permite respuestas mínimas a ese QTYPE, incluso un solo RRset elegido por el servidor. RFC 10029 no promete “todo”; promete identificar con precisión qué tipos se completaron.

La cabecera no puede contar dos historias incompatibles

El servidor construye primero la respuesta del QTYPE principal. Ahí decide RCODE, AA, AD, TC y las demás condiciones compartidas. Si la respuesta principal ya queda truncada, no procesa las combinaciones extra para incluirlas en el paquete.

Después evalúa cada QTYPE añadido. Sólo puede combinarlo si su resultado individual tiene el mismo RCODE y banderas compatibles. Un tipo que produce SERVFAIL no entra bajo el NOERROR del principal. Un NS no autoritativo en el lado padre de un corte de zona no entra bajo el AA de una respuesta DS autoritativa.

Esta restricción no desperdicia una oportunidad: evita que el formato mienta. RFC 2181 ayuda a interpretar el rango de las respuestas autoritativas, pero no convierte procedencias distintas en una sola decisión administrativa.

Caber es parte de completar

Los registros de cada tipo adicional se colocan en las mismas secciones que habrían ocupado en una consulta independiente. Si aparecen duplicados dentro de una sección, se conserva una sola copia. Pero el servidor sólo anuncia el QTYPE como terminado cuando puede incluir todo el material exigido para esa combinación.

Si el límite de tamaño o de recursos no lo permite, omite el tipo de MQTYPE-Response. No debe activar truncamiento únicamente por la parte adicional. Por eso TC=0 no demuestra que se satisfizo el conjunto original del cliente. Sólo describe el paquete que finalmente se construyó.

RFC 6891 añade la realidad del trayecto. OPT no se almacena en caché; el tamaño UDP anunciado corresponde a una transacción y puede superar lo que un firewall o la ruta puede entregar sin fragmentación. Aunque los intermediarios conformes no deben borrar las opciones, la compatibilidad debe observarse en ejecución. Una etiqueta estática de “servidor compatible” no basta para otro trayecto.

Lo omitido no tiene un significado único

RFC 10029 deja abierta la causa de una omisión. El recursor puede no tener el tipo en caché. La consulta individual puede diferir en RCODE o banderas. Puede haberse alcanzado un límite de trabajo. Puede faltar espacio. Ninguna de esas explicaciones se deduce sólo de la ausencia.

Por tanto, HTTPS omitido no equivale a HTTPS inexistente. No es una prueba negativa conforme a RFC 2308, ni una negación autenticada según RFC 4035. Tampoco prueba censura, avería o irrelevancia. Significa únicamente que ese QTYPE no figura entre los tipos adicionales completamente contestados.

Si la aplicación aún lo necesita, el cliente debe lanzar una consulta independiente. Esa obligación es la frontera que mantiene la optimización fuera de la semántica de negocio.

La simultaneidad de entrega no sincroniza el origen

Varios RRsets pueden entrar en el mismo paquete desde zonas diferentes. Las pruebas de inexistencia pueden llevar firmas diferentes. Sus TTL pueden ser distintos y la caché puede haberlos aprendido en momentos separados. La respuesta los entrega juntos, pero no crea un instante común de publicación.

RFC 9499 ofrece las palabras necesarias para no borrar esa diversidad: RRset, servidor autoritativo, recursor y caché designan funciones distintas. El sistema de evidencia debe conservarlas por tipo y por conjunto, no reducirlas a una marca única de “DNS válido”.

El uso viene después. Si la respuesta incluye HTTPS, RFC 9460 todavía obliga al cliente a evaluar prioridades, parámetros obligatorios, direcciones y alternativas. La recepción no prueba que el registro fuera utilizable, seleccionado ni que la conexión tuviera éxito.

Un libro de control para la completitud

Cada intento debe registrar el nombre, clase y QTYPE principal; la lista ordenada de tipos adicionales; el recursor y el trayecto; el tamaño EDNS; la presencia y contenido exactos de la opción de respuesta; RCODE, AA, AD y TC; y la diferencia entre tipos solicitados y tipos completados.

Por RRset deben conservarse zona, autoridad, firmante, validación DNSSEC, TTL, procedencia de caché y hora de observación. Las consultas de respaldo deben heredar el identificador de la solicitud de la aplicación. Al final se registra qué dirección o servicio eligió la aplicación y cuál fue el resultado real.

Así se evitan cuatro equivalencias falsas: recibir el paquete no es completar el tipo; completar el tipo no es validar cada RRset; validar no es tener datos suficientemente actuales; y tenerlos no es usarlos.

La primacía del código en ejecución de Heng Lu impide que la publicación o el registro de IANA se usen como prueba de despliegue. Su propuesta de especificación inicial mínima, decisión localizada y adopción voluntaria encaja con una opción acotada, límites locales y una salida compatible mediante consultas ordinarias. Su defensa de la realidad frente a la promoción fija el método editorial: describir lo que la norma permite y medir por separado lo que una ruta y una aplicación hacen.

Un paquete compartido ahorra trayectos. No comparte automáticamente la autoridad.