Resumen

  • El cifrado entre cliente y resolutor no impide que este último envíe aguas arriba un prefijo truncado de la red de origen mediante ECS.
  • La longitud de prefijo de origen limita lo divulgado; la longitud de alcance que devuelve la autoridad limita qué clientes posteriores pueden reutilizar la respuesta.
  • Esos números no demuestran identidad, consentimiento ni ubicación exacta. RFC 7871 documentó los costes de privacidad y caché, y RFC 8932 recomendó evitar ECS o minimizarlo y explicar su política.

Cifrado en un tramo, divulgación en el siguiente

El cifrado de DNS puede impedir que ciertos observadores vean la consulta entre el usuario y el resolutor. No borra la consulta dentro del servicio ni determina lo que ese servicio envía a los servidores autoritativos. RFC 8932 insistió en esta distinción al tratar la información que un operador de privacidad transmite aguas arriba.

EDNS Client Subnet es un caso concreto. En el modelo habitual, la autoridad ve la dirección del resolutor recursivo, no la del origen. Si un resolutor central reúne usuarios de lugares topológicamente distintos, su propia dirección puede ser un indicio pobre para adaptar una respuesta. ECS permite que el intermediario incluya información sobre la red de origen. El beneficio posible es una respuesta mejor ajustada; el coste es volver a introducir contexto del cliente después del tramo protegido.

RFC 8932 recomienda que un servicio de privacidad evite ECS o proporcione una alternativa que no lo use. Si lo emplea, debería enviar el prefijo operativo más corto posible, limitar preferiblemente los servidores que lo reciben y comunicar el tamaño y la política. Por eso «DNS cifrado» y «minimización de datos aguas arriba» no son sinónimos.

Un prefijo, no una identidad

La opción ECS contiene la familia de direcciones, una longitud de prefijo de origen, una longitud de alcance y un campo de dirección variable. En IPv4 e IPv6, la dirección queda truncada a los bits significativos del prefijo y solo se completa el último octeto necesario. No es obligatorio reenviar la dirección completa.

El resolutor establece un máximo compatible con su caché y debería usar menos bits que una dirección completa. Si recibe una consulta que ya impone un prefijo más corto, un reenviador posterior no puede ampliar la divulgación. En la consulta, la longitud de alcance vale cero: todavía no es una afirmación sobre la cobertura de la respuesta.

Un prefijo de red tampoco identifica a una persona, dispositivo o aplicación. La topología solo se relaciona de manera aproximada con la geografía, y RFC 7871 no especifica cómo debe una autoridad elegir una respuesta adaptada. ECS ofrece un indicio; no certifica el servidor más cercano, rápido o disponible.

La respuesta trae su propia frontera

La autoridad copia en la respuesta la longitud de origen de la consulta y añade una longitud de alcance significativa. Esta indica cuántos bits iniciales definen la red para la que puede utilizarse la respuesta. Un alcance corto cubre un conjunto más amplio; uno largo puede señalar que hacía falta un prefijo más específico para la selección.

Así aparecen dos decisiones distintas. El resolutor decide cuánto contexto de cliente revela. La autoridad decide cuánto puede extenderse el efecto de su respuesta en la caché. Confundir ambas longitudes oculta la gobernanza del mecanismo: una trata de divulgación; la otra, de reutilización.

La caché empieza por nombre, tipo y clase, como en DNS ordinario, y luego busca el conjunto adecuado por coincidencia de prefijos. Cuando una respuesta no contiene ECS se considera normalmente de alcance /0, válida para todas las direcciones. Si la autoridad devuelve REFUSED, el resolutor compatible repite la consulta sin ECS para diferenciar el rechazo de la opción de otros usos del código.

El precio de dividir la caché

Para el mismo nombre, tipo y clase pueden existir respuestas separadas por redes. Esa partición aumenta el número de entradas, reduce oportunidades de reutilización y puede elevar la carga del resolutor y de la autoridad. RFC 7871 recomendó mantener ECS desactivado por defecto, habilitarlo cuando exista un beneficio claro y limitar cuántas redes y respuestas se guardan.

La seguridad de la correspondencia tampoco autentica al cliente. El RFC aconseja descartar respuestas cuyos campos de identidad no coincidan con los de la consulta, lo que reduce algunas vías de suplantación y contaminación de caché. Pero una coincidencia no demuestra que el prefijo pertenezca a una persona determinada ni vuelve fiable la política de selección.

El /0 como instrucción y sus límites

Un stub puede fijar en cero la longitud de prefijo de origen. Al recibirlo, el resolutor no debe incorporar la dirección del cliente a la consulta posterior; puede omitir ECS o usar información propia. Los reenviadores han de conservar una limitación ya presente.

RFC 7871 advertía en 2016 que pocos entornos exponían ese control de forma práctica. La afirmación pertenece a ese momento histórico. Las fuentes de este artículo no contienen un inventario actual de programas, proveedores o tasas de adopción.

DNSSEC tampoco resuelve la cuestión. RFC 7871 recomienda alcance /0 para la mayoría de los registros DNSSEC, y una RRSIG sigue ligada al RRset que firma. La validación no firma la decisión del resolutor de revelar un prefijo, no demuestra geografía y no autentica la política de localidad de la autoridad.

La lección histórica es limitada pero duradera: una optimización de localidad convirtió la política del intermediario y la estructura de la caché en parte del resultado. Esa es una inferencia editorial basada en la mecánica de los RFC, no una medición de los despliegues actuales.

Fuentes