Resumen

  • La opción 12 de EDNS(0) permite añadir relleno de longitud variable a un mensaje DNS cifrado. Estandariza el contenedor, no el resultado de privacidad: los bloques de 128 octetos para consultas y 468 para respuestas son una política experimental de RFC 8467.
  • La protección es conjunta. El cliente rellena la consulta, el servidor decide la respuesta, el transporte cifra y enmarca, y la ruta limita el coste. El tiempo, los extremos y el número de intercambios siguen expuestos.

Supongamos que dos servicios DoT afirman usar relleno. Uno redondea cada consulta al múltiplo de 128 y cada respuesta al de 468. El otro añade siempre 16 bytes. Los dos producen mensajes válidos. Sin embargo, el segundo conserva la distancia entre todos los tamaños originales: para reconstruir la silueta solo hay que restar una constante conocida.

El cifrado protege el contenido del tramo entre cliente y servidor, pero la longitud del texto cifrado suele seguir a la vista. Algunos nombres, tipos de registro y respuestas tienen parejas de tamaños características. Un observador con muestras conocidas puede intentar reconocerlas sin descifrar ni un solo carácter.

RFC 7830 introduce una pieza deliberadamente pequeña. Dentro del pseudorregistro OPT de EDNS, el código 12 identifica Padding. Solo puede aparecer una vez por mensaje. OPTION-LENGTH cuenta los octetos añadidos; cero es válido, aunque la cabecera de la opción ya ocupa cuatro octetos. Se recomienda enviar ceros, pero el receptor debe aceptar cualquier valor. El relleno no es contenido DNS.

La norma no fija la cantidad. Esa omisión separa sintaxis compartida de decisión local. RFC 8467 estudió políticas y recomendó de forma experimental bloques de 128 octetos para consultas y 468 para respuestas. La idea es hacer que varios tamaños originales desemboquen en una misma clase observable.

Una clase sigue revelando información. Si se conoce el bloque, una consulta de 256 octetos acota el tamaño previo. Tampoco cambia el momento, el intervalo, la dirección ni el número de mensajes. Incluso cifrado y relleno, el flujo puede delatar que es DNS. El tráfico de cobertura o la variación artificial de tiempos atacarían otros canales y pagarían otros costes.

La petición no ordena una respuesta sin límites. Si incluye Padding, el servidor debe rellenar su respuesta salvo que supere el tamaño UDP permitido. Puede hacerlo ante una consulta EDNS sin Padding, pero no ante quien no anunció EDNS. La capacidad declarada concede una autorización estrecha; no garantiza que el bloque elegido sea útil.

La ruta convierte privacidad en ingeniería de entrega. El relleno se aplica al final de las opciones EDNS porque consume el espacio restante. El cálculo excluye los dos octetos de longitud propios de DNS sobre TCP para que un cambio de transporte no cree una clase distinta por mero encuadre. Cerca del MTU, un bloque grande fragmenta; por encima, la fragmentación UDP es inevitable. RFC 7830 prohíbe usar la opción en DNS sin cifrar y advierte que el tráfico extra puede ayudar a la amplificación.

DoH y DoQ reparten el control de otra forma. DoH admite Padding dentro de HTTPS autenticado, pero cabeceras, cookies, conexiones y tiempo siguen correlacionando. DoQ puede rellenar el mensaje DNS o, si QUIC ofrece la interfaz necesaria, ajustar el paquete completo y contar también confirmaciones y control de flujo.

No hay un único dueño del resultado. El cliente elige consulta y resolvedor. El servidor elige la respuesta. La biblioteca TLS, HTTP o QUIC puede controlar otra envoltura. La red decide qué tamaño llega sin pérdidas. Que IANA registre la opción demuestra un lenguaje interoperable, no su adopción.

La prueba operativa debe ser una distribución. Hay que comparar tamaños anteriores y emitidos, ocupación de cada bloque, respuestas que incumplen la petición, bytes añadidos, fragmentación, reintentos y fallback. Un selector activado no demuestra que haya aumentado el conjunto de anonimato.