Resumen

  • Una respuesta ANY puede contener solo algunos conjuntos disponibles, sin señalar que ha omitido otros. No encontrar un tipo en esa selección no demuestra que no exista.
  • El mecanismo de RFC 8482 ofrecía una respuesta no vacía que los clientes podían conservar normalmente, evitando que un código desconocido provocara más intentos ante otros servidores.
  • La opción de sintetizar HINFO reutilizaba un formato conocido, pero podía ocultar en la caché información HINFO auténtica. La duración elegida también condicionaba futuros cambios de política.

El hueco no era una negación

La respuesta incluye direcciones, pero no incluye TXT. Un programa puede registrar el resultado de dos maneras: «esta consulta no me devolvió TXT» o «este nombre no tiene TXT». La primera describe lo observado. La segunda añade una conclusión que una respuesta ANY mínima no sostiene.

El RFC 8482, publicado en enero de 2019, explica que el servidor puede escoger un conjunto de registros, o un subconjunto pequeño de los disponibles para el nombre consultado. También dice que el mecanismo no incorpora una señal que advierta al cliente de esa selección incompleta.

No se trataba de una lista con casillas marcadas como ausentes. Era una respuesta positiva de alcance limitado. El cliente tenía que conservar esa limitación al decidir qué sabía del nombre.

El problema no comenzó con la nueva política. ANY llevaba tiempo siendo un atajo tentador para pedir más de un tipo de información a la vez. La tentación era convertir ese atajo en una obligación de exhaustividad.

Una palabra amplia en un campo preciso

El RFC 1035, de noviembre de 1987, identificaba con un asterisco el tipo de consulta 255. Las implementaciones lo llamaban habitualmente ANY. Pero el nombre del tipo no eliminaba las demás dimensiones de una pregunta DNS.

En RFC 1034, QNAME indica el nombre, QTYPE el tipo solicitado y QCLASS la clase. Un ANY en QTYPE no es un comodín dentro del nombre ni una transferencia de zona AXFR. Preguntar por los registros de un nombre no enumera todos los nombres de la zona.

El algoritmo descrito también separa los datos de zona de los almacenados en caché. Encontrar registros pertinentes en una caché no acredita que esta conozca todos los que podría servir una fuente autoritativa. La consulta no convierte un conocimiento parcial en una copia universal del inventario.

La tabla vigente de parámetros DNS de IANA describe el tipo 255 como una petición de algunos o todos los registros disponibles en el servidor. HINFO sigue registrado por separado como tipo 13, información del host. Son definiciones registradas, no un censo de cómo responden hoy los operadores.

El intento de rechazar podía generar otro intento

Los operadores no necesitaban considerar maliciosa toda consulta ANY para querer respuestas menores. RFC 8482 reconoce usos legítimos de depuración y comprobación del estado de un servidor para un nombre. También describe aplicaciones que pretendían obtener MX, A y AAAA mediante una sola pregunta.

La advertencia para esas aplicaciones era preparar una alternativa si la consulta no llegaba a una fuente autoritativa o no devolvía todos los conjuntos esperados. El ahorro de preguntas era una expectativa de uso, no una garantía general.

Había, además, costes reales para quien contestaba. Una petición UDP pequeña podía suscitar una respuesta grande, una propiedad atractiva para la reflexión con direcciones de origen falsificadas. Algunas implementaciones debían realizar trabajo adicional para elaborar una respuesta ANY convencional. Reducirla también podía dificultar determinadas formas de recopilar datos, sin volver confidencial el resto del DNS público.

El RFC relata una alternativa discutida: introducir un nuevo código de respuesta que expresara la negativa a contestar de la manera tradicional. El resultado observado para ese enfoque era indeseable. Ante un código desconocido, los resolutores probaban otros servidores autoritativos disponibles en lugar de suprimir nuevas preguntas del mismo tipo.

Una negativa más explícita podía así repartir más trabajo. No significa que cualquier error cause siempre el mismo comportamiento; es la dificultad concreta que el documento intenta evitar.

La solución propuesta daba al cliente algo conocido y no vacío que conservar. Una vez presente en caché, la respuesta pequeña podía satisfacer o reducir futuras consultas ANY para ese nombre. No hacía falta que todos los clientes aprendieran un código nuevo antes de que el operador obtuviera alguna ventaja.

Elegir conjuntos no permitía romperlos

El primer método de minimización devuelve uno o varios RRsets disponibles. Esa unidad merece precisión. El RFC 2181, de julio de 1997, define un conjunto por nombre, clase y tipo comunes, con datos que pueden diferir entre sus miembros.

Si un conjunto contiene varias direcciones, seleccionar ese conjunto no significa escoger arbitrariamente una dirección y omitir las otras como si se hubiera entregado la unidad completa. Las reglas exigen devolver el RRset asociado entero, aplicando la troncatura cuando un conjunto necesario no cabe.

La decisión de incluir menos tipos es distinta de la imposibilidad de transportar completo un conjunto requerido. Por eso, el bit TC tampoco sirve como certificado de que se han enumerado todos los tipos del nombre. La ausencia de troncatura no repara una expectativa de inventario que la política nunca ofreció.

RFC 8482 se refiere en estos mecanismos a nombres existentes, clase IN y QTYPE=ANY. Salvo los cambios especificados, las reglas normales continúan. No autoriza a inventar existencia para nombres ausentes ni a responder NXDOMAIN por conveniencia cuando el nombre sí existe.

La ficha de máquina que ya no describía una máquina

El segundo método puede sintetizar un HINFO cuando no hay CNAME en el nombre correspondiente. La recomendación es devolver un solo registro con la cadena RFC8482 en el campo CPU y una cadena vacía en OS. No exige guardar ese registro de forma permanente en los datos de zona.

HINFO tenía una finalidad anterior. RFC 1035 lo define mediante dos cadenas para procesador y sistema operativo, y menciona usos como las adaptaciones de FTP entre máquinas o sistemas del mismo tipo. Reutilizar esa forma permitía producir algo que los clientes ya sabían manejar.

En un registro creado expresamente por el nuevo mecanismo, RFC8482 no es un modelo de procesador descubierto. OS vacío tampoco significa que la máquina carezca de sistema operativo: el campo sigue existiendo como cadena de longitud cero.

Pero el receptor no puede convertir esas coincidencias en prueba segura del origen. RFC 8482 advierte que no debe suponerse, solo a partir del contenido HINFO, que una respuesta fue sintetizada según esta especificación y merece un tratamiento especial por ese motivo.

El documento permite por separado el almacenamiento ordinario y contempla la supresión opcional de nuevas consultas ANY cuando hay un HINFO correspondiente en caché, o una respuesta normal desde ella. Esa posibilidad no vuelve infalible la identificación de registros sintéticos. La utilidad del formato conocido y la incertidumbre de su procedencia son compatibles.

La caché podía esconder la ficha auténtica

El coste de la reutilización aparece en una consulta posterior. Si la caché ya tiene el HINFO sintético, puede responder con él a una petición específica de HINFO y ocultar temporalmente el registro auténtico que sigue en la zona.

RFC 8482 reconoce el efecto y aconseja a los operadores que dependen del uso convencional de HINFO escoger el método de conjuntos existentes u otro tipo. La creencia de sus autores de que HINFO se usaba poco correspondía a sus observaciones de entonces; no demuestra que no hubiera usuarios afectados ni constituye una medición actual.

Un tercer método intenta acercarse al propósito probable del solicitante devolviendo los conjuntos CNAME, MX, A y AAAA presentes y omitiendo otros, como TXT o DNSKEY. Puede satisfacer ciertas necesidades, pero también producir respuestas mayores y equivocarse sobre lo que la aplicación buscaba.

Las tres alternativas son opcionales. El RFC actualiza las reglas de 1987, pero no elimina ANY ni obliga a todos los servidores a responder con la misma ficha sintética.

La duración también era una decisión operativa

La TTL del HINFO sintético debía ser configurable por el operador. Una duración suficiente podía reducir las consultas repetidas del mismo iniciador para el mismo nombre; una duración excesiva podía dificultar futuros cambios de política sobre ANY.

No había una cifra universal que resolviera ambas cosas. RFC 2181 aclara, además, que TTL expresa una retención máxima, no una obligación de guardar el dato durante todo ese tiempo. Un resolutor puede imponer su propio límite.

Por tanto, cambiar la respuesta en el servidor no garantiza un olvido inmediato y sincronizado en todas las cachés. Una decisión local deja efectos distribuidos durante un intervalo que el operador no controla como si fuera memoria propia.

La ventaja consiste precisamente en que esos efectos persistan lo bastante para evitar nuevo trabajo. El riesgo es olvidar que la misma persistencia acompaña también a una política que después se quiere modificar.

Una respuesta mínima no era una respuesta negativa

El RFC 2308, de marzo de 1998, distingue entre error de nombre NXDOMAIN y NODATA, ausencia del tipo pedido para un nombre válido inferida del contenido de la respuesta. NODATA no es un código separado. La caché negativa tiene sus propias condiciones, incluido el uso de información SOA.

Recibir un HINFO o algunos RRsets en respuesta a ANY es otra cosa. Su contenido no vacío no niega todos los tipos que faltan. Una aplicación que necesite un tipo concreto debe preguntarlo, no transformar su ausencia en una selección en una declaración de inexistencia.

El transporte tampoco garantiza recuperar una supuesta lista completa. RFC 8482 permite políticas diferentes para UDP y TCP, por ejemplo respuesta convencional en el segundo y mínima en el primero. Es una opción admitida, no una obligación ni una vía universal para saltarse la política del operador.

Las firmas acompañaban lo que sí se devolvía

El bit DO, explicado en RFC 3225 en diciembre de 2001, indica capacidad para aceptar registros de seguridad DNSSEC. No prueba que la validación ya se haya realizado ni que una respuesta ANY contenga todos los tipos.

RFC 8482 conserva las condiciones pertinentes de firma. En la respuesta sintética, DO activado y una zona que el servidor sabe firmada requieren un RRSIG válido; con DO desactivado se recomienda omitirlo en ese caso. Las respuestas de subconjuntos y las que estiman la intención también mantienen sus requisitos correspondientes.

La autenticidad del conjunto entregado no equivale a la enumeración de todo lo omitido. Esa conclusión se desprende del alcance de la selección: una firma puede acompañar el conjunto devuelto sin ampliar la pregunta que realmente se ha contestado.