Resumen

  • La nueva opción propuesta permite que un cliente limite la longitud del prefijo ECS sin aportar una dirección que quizá no conoce detrás de NAT, CGNAT o una VPN.
  • El límite es una instrucción al resolvedor que recibe directamente la consulta, no un consentimiento transferible ni una prueba de lo que llegó a los servidores autoritativos.

El portátil conoce una dirección privada. La VPN presenta otra interfaz. El resolvedor recursivo, al otro extremo, observa una dirección pública distinta. Pedirle al dispositivo que entregue esa dirección para limitar EDNS Client Subnet convierte una preferencia de privacidad en un acertijo de topología.

El problema no es menor. RFC 7871 permite que un resolvedor envíe a servidores autoritativos un prefijo de la dirección del cliente. Ese prefijo ayuda a producir respuestas adaptadas a la red, pero también extiende información de localización más allá del resolvedor. Un cliente puede excluirse enviando una opción ECS con longitud de prefijo fuente igual a cero. Si quiere un límite positivo más corto, la opción tradicional exige una dirección cuyos bits se truncarán.

Client Opt-In Signaling for EDNS Client Subnet propone separar el permiso de la dirección. Su revisión 00, fechada el 20 de agosto de 2026, es un Internet-Draft individual con intención experimental. No ha sido adoptado por DNSOP, no es una RFC, su código de opción sigue como TBD y no acredita implementación alguna. Precisamente por eso conviene leerlo como diseño de controles y no como anuncio de disponibilidad.

Permitir no es identificar

La opción propuesta puede viajar sin datos o con un octeto. Con un octeto, el valor es la cantidad máxima de bits de dirección que el cliente permite reenviar. El resolvedor puede usar la dirección fuente que observa, de modo que el cliente no necesita saber qué traducción realizó el NAT ni qué salida eligió la VPN.

Si la consulta también contiene una opción ECS válida con una dirección IPv4 o IPv6 y un prefijo no nulo, el resolvedor debe usar esa dirección y no sustituirla. Cuando ambos mecanismos expresan un límite, gobierna el menor. También entran en el mínimo la política máxima del resolvedor y el tope de la familia: 32 para IPv4 y 128 para IPv6.

Una dirección privada o no enrutable suministrada por el cliente no debe ser proyectada como si fuera la identidad pública. El borrador hace que el resolvedor no reenvíe información en ese caso. También obtiene un límite efectivo cero si la familia no es IPv4 o IPv6, si rechaza una dirección que el origen no parece servir o si decide no usar ECS.

La forma sin datos merece atención. Significa que el cliente acepta ECS, pero no fija un máximo propio. Queda vigente el máximo del resolvedor. Es una delegación amplia, no una política de minimización. Quien no permite divulgar nada debería omitir la opción; un cero explícito logra el mismo resultado, aunque revela en un transporte abierto que el cliente conoce el mecanismo.

La compatibilidad oculta el incumplimiento

EDNS exige que una opción desconocida sea ignorada. Por eso un resolvedor que no implementa el borrador puede recibir una consulta con límite, descartarlo y responder con normalidad. El navegador funciona y el monitor ve éxito, pero el control nunca existió.

Un resolvedor compatible devolvería la opción con la longitud efectiva. Su ausencia puede significar falta de soporte o manipulación en tránsito. Ninguna de las dos interpretaciones dice por sí sola si el resolvedor empleó ECS según su configuración anterior. El cliente no debe considerar la mera llegada de una respuesta como prueba de respeto del límite.

Este comportamiento es una decisión razonable de compatibilidad: no rompe la resolución entre actualizaciones descoordinadas. También impide usar el éxito de DNS como recibo de privacidad. La misma flexibilidad que conserva el servicio obliga a construir una comprobación separada.

El borrador sugiere una sonda prudente. Un cliente que investiga soporte puede combinar la nueva opción con un ECS de prefijo fuente cero. Un resolvedor antiguo que use ECS debería respetar ese opt-out, mientras uno nuevo aplicaría el mínimo. Así se pregunta por capacidad sin exponer una dirección durante la pregunta. Incluso esta sonda demuestra soporte declarado, no honestidad futura.

El valor devuelto no está firmado

La respuesta de un resolvedor compatible contiene la longitud efectiva. Si devuelve cero, afirma que no reenviará información. Si devuelve N, afirma que no enviará más de N bits. La palabra decisiva es «afirma».

Los registros OPT no están protegidos por DNSSEC. Una respuesta para el nombre puede validar criptográficamente mientras el dato sobre ECS sigue siendo una declaración no firmada del intermediario. Un resolvedor hostil puede divulgar un prefijo más largo y reportar uno corto. El cliente sólo puede detectarlo si obtiene observación en el lado autoritativo.

DNS cifrado protege otro límite. DoT, DoH o DoQ pueden impedir que un atacante en el camino agregue la opción, eleve el valor o falsifique la respuesta entre cliente y resolvedor. No pueden obligar al resolvedor a decir la verdad. Confundir cifrado del salto con cumplimiento del actor convierte una garantía de transporte en una garantía institucional que el protocolo no ofrece.

Una auditoría útil conserva cuatro registros. Primero, la preferencia enviada por el cliente. Segundo, la identidad y protección del canal hacia el resolvedor. Tercero, el cálculo y la declaración del resolvedor. Cuarto, el prefijo efectivamente observado por autoridades o telemetría autorizada. Cada registro tiene un dueño distinto.

El consentimiento termina en el salto que lo recibió

La nueva opción no se copia hacia servidores autoritativos. Tampoco puede ser trasladada sin más de un cliente a una consulta aguas arriba. Es deliberadamente no transitiva porque expresa una instrucción al resolvedor recursivo que recibió directamente la elección.

Un resolvedor de reenvío es cliente del siguiente resolvedor. Puede formular su propia solicitud de opt-in, pero nunca superar el límite que recibió. Si construye ECS con la dirección del cliente, responde por esa decisión. Si deja que el servicio superior seleccione la dirección, lo que el superior observa es la dirección del propio reenviador; debe informar cero bits de la dirección original.

La distinción evita que un intermediario convierta una preferencia local en un mandato universal. El cliente autorizó a un actor concreto bajo una condición concreta. Cada salto posterior requiere una decisión propia y conserva el techo. El sistema coordina sin fingir que la autorización viaja como una credencial.

Una opción ECS tradicional no demuestra esa autorización. Los reenviadores pueden añadirla. Por eso el borrador establece que ECS por sí solo, sin la opción de opt-in, no permite a un resolvedor compatible divulgar la dirección del cliente. Dirección disponible y consentimiento recibido son hechos diferentes.

La caché también tiene una frontera

Un resolvedor compatible no debe entregar a un cliente no señalizante una respuesta obtenida mediante ECS. Debe saber, para cada entrada, si ECS participó en su adquisición. La separación puede materializarse en cachés distintas o en metadatos y reglas equivalentes.

Sin ese dato, una respuesta adaptada a una red podría reutilizarse para alguien que no aceptó el mecanismo. En la respuesta no hay una bandera que anuncie su origen adaptado. El cliente no puede descubrir que el resultado de una divulgación ajena cruzó su contexto.

Para clientes que sí señalan, las reglas de coincidencia de RFC 7871 siguen vigentes. Incluso una entrada con un prefijo fuente más largo que el límite actual puede responder, porque el acceso a caché no envía nuevos bits. Esto obliga a distinguir la política de divulgación de la elegibilidad de reutilización. Prohibir toda reutilización sería una inferencia excesiva; permitirla sin procedencia sería una pérdida de control.

La versión 00 añade otra incertidumbre: el valor de respuesta representa el límite efectivo aunque haya acierto de caché. En ese caso puede no haberse divulgado ningún bit nuevo. El propio texto pregunta si debería reportar los bits realmente usados. «Podía enviar hasta N» y «envió N para obtener esta respuesta» no son equivalentes. Antes de automatizar controles, hay que decidir cuál de las dos magnitudes se está registrando.

Corto no significa anónimo

Un prefijo reducido conserva información sobre una red. Puede llegar a cada servidor autoritativo al que el resolvedor envía ECS y a observadores del tráfico no cifrado. La minimización reduce precisión y superficie, pero no convierte el dato en anonimato. El cliente debería elegir el límite más corto compatible con la utilidad que busca.

Tampoco una futura asignación del código demostraría éxito. El borrador solicita Expert Review para un valor estable en el registro EDNS0, porque elegir arbitrariamente un valor experimental no sirve para interoperabilidad amplia. La asignación permitiría coordinación de software. No demostraría adopción, segregación correcta de caché, honestidad del informe ni un experimento con criterios cumplidos.

El avance real del diseño está en devolver la elección a quien soporta la exposición, incluso cuando ese actor no conoce la dirección pública. Pero la elección sólo produce gobernanza si sus límites se conservan como evidencia. Permiso, dirección observada, tope, reenvío, caché y divulgación son decisiones distintas. Una etiqueta única de «ECS consentido» las volvería invisibles.

Fuentes