Resumen

  • La RFC 9539 es Experimental y permite desplegar unilateralmente DoT o DoQ entre resolvers recursivos y servidores autoritativos para dificultar la observación pasiva.
  • El perfil no autentica al servidor: el cliente acepta cualquier certificado y vuelve a Do53 cuando falla el transporte cifrado. No impide un downgrade activo ni sustituye DNSSEC.
  • La capacidad reciente de una IP no prueba la privacidad de cada pregunta. La custodia exige guardar intentos, respuesta procesada, certificado, SNI, timers, causa del fallback y cohorte de red.

Dos caminos, un solo ganador

Supongamos una búsqueda fría. El resolver necesita consultar a la dirección autoritativa X y no recuerda ningún éxito cifrado reciente. Envía la pregunta por Do53 y, en paralelo, inicia DoT o DoQ en el puerto 853. El objetivo es aprender sin añadir un retraso grande a una resolución que ya funcionaba.

La respuesta en claro llega primero. Coincide con una consulta pendiente y se procesa. Poco después termina correctamente el handshake cifrado. El resolver registra que, desde esa IP de origen hacia X, el transporte funciona y podrá evitar Do53 en consultas posteriores mientras siga vigente la persistence.

El servidor demostró capacidad, pero esa pregunta no obtuvo confidencialidad. Si el sistema cuenta handshakes y no preguntas procesadas, puede declarar éxito justo cuando la información sensible ya cruzó el enlace. La RFC 9539 admite esa carrera como parte del aprendizaje; la obligación del operador es no borrarla de la métrica.

El certificado tampoco corrige el registro. En este modo, el cliente debe aceptar el certificado que reciba. Puede conservar un fallo de verificación para análisis, pero no rechazar el canal sólo por esa causa y caer al claro. Así protege frente al observador pasivo, pero deja abierta la interposición activa. El cifrado ocurrió; la identidad no quedó establecida.

Una opción local, no un nuevo registro de poder

La RFC 9539 apareció en febrero de 2024 como experimento IETF. DoT y DoQ definen los transportes. Este perfil explica cómo usarlos en el salto entre recursión y autoridad sin crear una señal previa de inscripción.

Un operador autoritativo puede escuchar en 853 sin esperar a que todos los resolvers cambien. Un resolver puede probar las IP que ya descubre por delegación. No existe una fecha universal, una autorización central ni un registro que convierta la opción en obligación.

Ese diseño aplica la seguridad oportunista de la RFC 7435: cuando el punto de partida es texto claro, cifrar sin autenticar todavía puede reducir la vigilancia masiva. Una política explícita y más fuerte conserva prioridad. Desde la doctrina de Heng Lu, la especificación común permanece mínima y la adopción se vuelve real sólo cuando participantes independientes la implementan y operan.

El límite es tan importante como la mejora. Una máquina que responde en 853 no adquiere autoridad sobre una zona. El experimento no comprueba su identidad, no impide que un atacante fuerce Do53 y no autentica los RRsets. DNSSEC conserva esa última función bajo su propia cadena de confianza.

La memoria pertenece a una ruta concreta

El estado se asocia a la IP autoritativa, no sólo al nombre NS ni a la zona. Un nombre puede resolver a varias direcciones; una dirección puede representar un pool o un anycast. Si un backend acepta DoQ y el siguiente no, generalizar el primer éxito causa esperas evitables.

También importa la IP de origen del resolver. Un balanceador puede asignar backend según el cliente y una ruta anycast puede separar cohortes. La frase auditable es: una fuente concreta alcanzó una dirección concreta, con un protocolo concreto, a una hora concreta. “La autoridad soporta DoT” pierde demasiada topología.

La tabla conserva inicio y fin del intento, success, fail o timeout, última respuesta, sesión, tickets de reanudación y consultas asociadas. Tras reiniciar no puede persistir una sesión viva ni una cola pendiente, aunque sí el historial reciente de capacidad.

La RFC sugiere tres días de persistence, un día de damping y cuatro segundos de timeout. Son parámetros experimentales. Deciden cuánto tiempo un éxito evita el claro, cuánto tiempo un fallo frena otro intento y cuánto retraso se tolera antes de abrir la vía ordinaria. Por eso deben figurar en el expediente y analizarse por ruta.

No todos los fallos autorizan la misma memoria

Si falla el handshake o se rompe un transporte ya establecido, el resolver marca el fallo, deriva las preguntas sin cobertura a Do53 y espera el damping antes de probar otra vez. Una clausura limpia es diferente: el servidor puede cerrar conexiones antiguas para proteger memoria; la siguiente consulta aún puede reintentar el cifrado enseguida.

Un timeout de consulta tampoco prueba que toda la sesión haya caído. Otro transporte, otra autoridad o una pregunta distinta pueden continuar. Un SERVFAIL formado es una respuesta DNS, no un error TLS. Un puerto silencioso puede significar ausencia, filtrado o límite de recursos. El atacante activo puede fabricar algunas señales para provocar downgrade.

La evidencia debe nombrar el evento, la consulta afectada, la hora, el camino alternativo y el próximo instante elegible. Reducirlo a encrypted=no impide saber si la política protegió disponibilidad, amplificó una avería o obedeció a un atacante.

El perfil no cierra porque la oferta de cifrado no es un compromiso autenticado. Para una variante fail-closed harían falta señal resistente al downgrade, autenticación del servidor y un alcance definido. Sin esas piezas, exigir 853 daría a una función opcional el poder de cortar nombres que siguen disponibles por DNS ordinario.

Canal, contraparte y datos

Hay tres preguntas. ¿Los bytes viajaron cifrados? ¿La contraparte era la autoridad esperada? ¿Los datos DNS eran auténticos? TLS o QUIC responden la primera para una sesión. La RFC 9539 deja sin resolver la segunda. DNSSEC puede responder la tercera si existe una cadena válida.

Una respuesta DNSSEC válida sobre Do53 tiene autenticidad sin confidencialidad. Una respuesta DoT con certificado no verificado puede tener confidencialidad ante un monitor pasivo sin identidad del peer. Si tampoco valida DNSSEC, no prueba el origen de los datos. Llamar “DNS seguro” a todos estos estados destruye la capacidad de reparación.

SNI puede revelar qué nombre NS comparte una IP y, por extensión, qué zona motivó la consulta. El perfil recomienda omitirlo; ECH reduce la fuga si resulta necesario. El padding de RFC 7830 y RFC 8467 dificulta inferir tamaños. QNAME minimisation reduce el nombre que recibe cada autoridad. Son defensas complementarias, no autenticación.

Un único destino puede esconder estados incompatibles

Las respuestas cifradas y no cifradas deben salir de los mismos datos de zona. Puede variar el tamaño, EDNS o la truncación por propiedades del transporte; no debe variar el estado sustantivo.

Un load balancer puede, sin embargo, alternar backends actualizados y antiguos. Anycast puede llevar a un sitio con otra fase de despliegue. La RFC recomienda activar el pool en un intervalo breve, mantener afinidad por IP de cliente o seleccionar sólo miembros compatibles para 853.

El operador debe medir por fuente, sitio y tiempo, buscar handshakes sin respuesta DNS y comparar los contenidos de Do53, DoT y DoQ. Un éxito es evidencia de esa ruta, no certificado de todo el fleet.

La fila que demuestra privacidad

El registro incluye query ID, QNAME, QTYPE, QCLASS, hora, origen, destino, contexto NS/zona y vantage. Enumera transportes, puerto, ALPN, inicio y fin, cola pendiente y respuesta ganadora.

Añade fingerprint y forma del certificado, resultado de verificación, SNI/ECH, sesión o resumption, early data, fallo exacto, persistence, damping y timeout. Para el DNS conserva bytes o hash, RCODE, flags y estado DNSSEC.

Por último declara si esa pregunta cruzó Do53, cuándo y por qué cayó, cuándo se reintentará, qué cohorte respondió y qué trigger obliga a revisar. La métrica final divide preguntas realmente protegidas por el total elegible; no usa como sustituto el número de listeners.

Fuentes