Resumen

  • Un servidor que solo dispone de nuevos Tipos de Delegación puede devolver una respuesta negativa a un resolvedor no compatible y añadir el error extendido 34 para indicar “New Delegation Only”.
  • El código mejora el diagnóstico, pero no aporta capacidad al cliente; la resistencia a una degradación exige además una zona firmada, el compromiso ADT y un resolvedor que valide la prueba NSEC o NSEC3.

La alerta decía que el nombre no existía. La captura de red mostraba algo más preciso: el servidor autoritativo había añadido el Extended DNS Error 34, “New Delegation Only”. El dominio sí formaba parte de una delegación, pero el cliente no hablaba el nuevo mecanismo y el padre ya no tenía un conjunto NS que pudiera entregarle.

Para el equipo de operaciones, el código resolvió un misterio. Para el resolvedor, no resolvió el nombre. EDE describió la frontera de compatibilidad; no la atravesó.

Ese episodio hipotético concentra el problema de DNS Protocol Modifications for Delegation Extensions. La revisión 11, fechada el 17 de septiembre de 2026 y con vencimiento el 21 de marzo de 2027, es un Internet-Draft activo del grupo DNSOP encaminado a la vía de estándares. No es un RFC definitivo ni prueba que un operador o producto haya adoptado el diseño. Su valor analítico está en separar con rigor tres cosas que suelen fundirse en un único indicador: entender una extensión, autenticar la obligación de usarla y completar la resolución.

El texto define Tipos de Delegación, registros autoritativos en el punto de delegación que proporcionan información al resolvedor. Propone reservar los códigos 0xF0000xF1FF y dividirlos según su comportamiento. Los tipos NS-Omitting sustituyen la información de NS. Los NS-Preserving la complementan. Los On-Demand no viajan normalmente en la remisión. Los privados conservan NS.

La compatibilidad tiene una salida negativa

Un resolvedor compatible coloca el bit DE en EDNS(0) para señalar que entiende estos tipos. Si el servidor autoritativo recibe DE a cero, se comporta según el modelo heredado. No presenta los nuevos registros como una delegación que el cliente no podría procesar.

Cuando el nombre delegado todavía tiene NS, ese comportamiento produce una remisión tradicional. Pero el nuevo diseño permite que un tipo NS-Omitting contenga información suficiente para delegar sin NS. Si el padre ha adoptado esa forma y ya no publica NS, una consulta sin DE no puede recibir una remisión útil para el cliente antiguo. El servidor devuelve una respuesta negativa y debería añadir EDE 34, salvo que una política local indique otra cosa.

El código cumple una función institucional importante: evita que la ausencia aparente se confunda con un nombre borrado, una zona mal cargada o un fallo aleatorio. Permite atribuir la causa a una diferencia de capacidades. Aun así, no contiene la información de la nueva delegación, no actualiza el programa y no autoriza un camino alternativo. La observabilidad puede convertir un fallo opaco en uno explicable; no puede convertir por sí sola un cliente incompatible en compatible.

Esa distinción debería reflejarse en los acuerdos de servicio. “EDE recibido” es éxito de diagnóstico. “Nombre resuelto” es resultado de servicio. Mezclarlos recompensa informes claros sobre usuarios que continúan bloqueados.

DE anuncia comprensión, no integridad

El bit DE solicitado en la posición 2 negocia el lenguaje. Un resolvedor recursivo compatible que recibe DE de un stub compatible debe devolverlo para indicar soporte. Esta copia puede crear la apariencia de un recorrido confirmado de extremo a extremo. No es una firma sobre la remisión.

Un atacante en el camino puede quitar DE antes de que la consulta llegue al servidor autoritativo. El servidor, al observarlo a cero, responde con NS solamente o, si no hay NS, con una negativa. También puede retirar de una remisión los tipos NS-Omitting y las pruebas asociadas, dejando registros NS no firmados. La negociación de capacidades en otra frontera no demuestra que esos datos hayan sobrevivido.

El proyecto introduce por eso un compromiso diferente, ADT, en el bit 14 de DNSKEY. El resolvedor que valida obtiene su estado del conjunto DNSKEY autenticado de la zona delegante. Si alguna clave tiene ADT, cada remisión debe incluir prueba NSEC o NSEC3 de presencia o ausencia de Tipos de Delegación en el nombre delegado.

El validador compara los tipos NS-Omitting, NS-Preserving y privados recibidos con los mapas de tipos autenticados. Si el mapa demuestra que un registro existe y la respuesta lo omite, debe tratarla como manipulada e ignorarla. Los tipos On-Demand pueden figurar en el mapa sin aparecer en una remisión ordinaria, porque su ausencia allí está prevista.

ADT vence la retirada de DE precisamente porque su obligación no nace de esa consulta. Proviene de una DNSKEY previamente validada. El atacante puede alterar la negociación efímera, pero no puede eliminar del estado validado la promesa de que la remisión llevará la prueba correspondiente.

La prueba permite rechazar; no garantiza continuidad

La defensa solo existe cuando coinciden cuatro condiciones: la zona delegante está firmada, ADT está establecido, el resolvedor valida DNSSEC y aplica la comprobación. En una zona sin firma, con ADT a cero o ante un resolvedor que no valida, el mecanismo no ofrece protección criptográfica frente a estas degradaciones.

Si ADT está a cero, una respuesta positiva con DELEG no debe considerarse inválida solo por esa ausencia. El resolvedor puede procesarla según las reglas normales. El registro puede ser aceptable y, al mismo tiempo, carecer del compromiso que permitiría detectar su retirada. Un estado binario “válido/inválido” no captura esa diferencia.

La respuesta negativa también necesita una prueba adecuada. Un atacante que quite DE puede intentar provocar una denegación de servicio contra una delegación sin NS. El resolvedor que conoce ADT espera NSEC o NSEC3. Una negativa desnuda queda expuesta como insuficiente.

Compact Denial of Existence introduce una sutileza: una respuesta basada en NXNAME que coincida con el nombre consultado no muestra los bits de Tipos de Delegación en el punto de delegación. Para mantener la detección, el proyecto exige una prueba convencional de Name Error. La elección del formato probatorio determina qué afirmación negativa puede verificarse.

Incluso cuando el validador detecta la manipulación y rechaza la respuesta, el nombre puede seguir sin resolverse. La seguridad produjo un fallo correcto. Un tablero que celebre “ataque bloqueado” sin registrar la indisponibilidad cuenta solo la mitad de la historia; otro que fuerce NS para elevar la disponibilidad podría borrar la propiedad de transporte que los nuevos tipos pretendían preservar.

El comportamiento vive en el número

La franja 0xF0000xF07F corresponde a tipos que omiten NS; 0xF0800xF0FF, a tipos que lo preservan; 0xF1000xF1EF, a datos solicitados bajo demanda; y 0xF1F00xF1FF, a uso privado con conservación de NS.

Esta estructura permite que una implementación compatible con el marco, pero desconocedora de un tipo futuro, sepa cómo tratar la remisión. También convierte la asignación de IANA en una decisión ejecutable. El segmento equivocado no es una etiqueta administrativa equivocada: ordena mantener NS cuando había que reemplazarlo, o retirarlo cuando debía sobrevivir.

La revisión experta debe preguntar si la información basta para procesar una delegación sin NS, si un programa que no entiende el tipo puede manejarlo de forma segura y si sus propiedades encajan con DNSSEC. Para comportamientos nuevos que interactúen con los mecanismos centrales, el proyecto pide un documento de Standards Track. La gobernanza del registro es parte del diseño de seguridad porque fija el comportamiento genérico antes de que exista conocimiento específico.

La prioridad evita una recuperación engañosa

Si una remisión contiene al menos un tipo NS-Omitting, el resolvedor debe usarlo e ignorar cualquier NS acompañante. No debe validar ni almacenar esos NS. Si sabe que el tipo existe pero sus datos son inutilizables, tampoco puede volver a NS; trata los servidores como inalcanzables.

La regla puede parecer hostil a la continuidad. Su propósito es impedir que un fallo en el mecanismo nuevo provoque un regreso silencioso a DNS sobre transporte convencional. La recuperación cambiaría la política. Un operador puede decidir revertir una implantación, pero debe hacerlo como cambio explícito, con evidencia y alcance, no como heurística oculta dentro del resolvedor.

Cuando no hay tipos NS-Omitting, NS sigue siendo la base y los tipos NS-Preserving o privados lo complementan. A través de varios niveles, un resolvedor compatible debe soportar mezclas arbitrarias. La transición no es una versión única instalada en todo el camino; es una sucesión de decisiones locales cuya combinación define el resultado.

Una lista no es una conexión

El proyecto adapta SLIST para representar un conjunto de varias formas de información de delegación y eliminar duplicados exactos. Advierte que las dependencias pueden ser cíclicas y generar procesamiento sin límite, por lo que los resolvedores necesitan cotas.

También deja una frontera probatoria: el algoritmo explica cómo poblar SLIST, no cómo elegir ni usar sus elementos. Que un servidor aparezca en la lista demuestra que cumplió las reglas de construcción. No demuestra que fue elegido, que aceptó una conexión, que el transporte fue cifrado ni que respondió.

La traza operativa debería registrar DE en cada tramo, la DNSKEY y ADT validados, la prueba de tipos, la regla de prioridad, los candidatos añadidos, el servidor escogido, el transporte observado y el resultado final. Cada fase responde a una pregunta distinta. Reducirlas a “Delegation Extensions activado” elimina la información necesaria para explicar tanto una degradación como un fallo seguro.

El código EDE 34 merece quedarse en esa traza. Es una nota clara del servidor: el cliente pidió una versión del mundo que ya no puede usar. Sirve para decidir qué componente debe cambiar. Nunca debería presentarse como si el propio aviso hubiese devuelto el nombre al usuario.

Fuentes