Resumen

  • draft-ietf-dnsop-ns-revalidation-14 permite preferir el conjunto NS autoritativo del ápice hijo, pero exige volver al padre: un operador anterior que conserva la zona no puede convertir sus propias respuestas en una delegación perpetua.
  • La evidencia útil es la cadena completa y fechada: referral del padre, solapamiento de NS y DS, menor TTL de soporte, invalidación de descendientes y resolución nueva. Ningún eslabón sustituye a los demás.

Una migración con dos realidades

Para el registro, la delegación ya había cambiado. Para el nuevo proveedor, la zona estaba lista. Para un resolutor que conservaba el conjunto NS del hijo anterior, nada parecía haber ocurrido. Preguntaba a los servidores antiguos, recibía respuestas coherentes y renovaba el TTL de datos que seguían marcados como autoritativos.

Las tres observaciones podían ser ciertas al mismo tiempo. Lo que no podía ser cierto era que todas describieran la misma autoridad actual.

La revisión 14 de draft-ietf-dnsop-ns-revalidation, fechada el 2 de septiembre de 2026, aborda esa separación. Es un Internet-Draft activo de DNSOP, con intención de Proposed Standard y estado I-D Exists, a la espera del visto bueno de la presidencia del grupo. No es un RFC ni demuestra que un resolutor concreto despliegue el algoritmo opcional.

El valor del documento está en mostrar que “responde con autoridad” y “sigue delegado por el padre” son afirmaciones diferentes.

La frontera de zona tiene dos conjuntos NS

En el modelo tradicional, el padre publica el conjunto NS de delegación y el hijo publica un conjunto NS en su propio ápice. RFC 1034 pidió que ambos administradores mantuvieran consistencia, pero DNS no incluye una transacción que sincronice esas dos superficies.

RFC 2181 da mayor credibilidad al conjunto del hijo porque es autoritativo; el conjunto del padre llega como datos no autoritativos del referral. Preferir al hijo permite que el operador de la zona use un TTL más corto y cambie servidores sin esperar el plazo más largo impuesto por el padre.

La revisión 14 recomienda consultar de forma explícita el NS del ápice hijo al descubrir un corte. También recomienda volver a consultar A y AAAA cuando solo se conocen como glue o datos adicionales de menor rango.

Esa mejora responde a “¿qué servidores declara el hijo?”. No responde a “¿sigue el padre delegando la zona a ese hijo?”. Si se confundieran ambas preguntas, el antiguo operador podría refrescar indefinidamente su propia apariencia de legitimidad.

El menor de tres relojes

La vuelta al padre debe ocurrir como máximo cuando venza el menor TTL entre el NS delegante del padre, el DS parental —si existe— y el NS del ápice hijo.

Cada reloj limita algo distinto. El NS del padre limita la vigencia de la ruta de delegación. El DS limita la continuidad del firmante delegado. El NS del hijo limita la actualidad de su topología autoritativa. Usar el menor evita que una larga vida en una capa amplíe el poder concedido por otra.

El borrador admite un piso mínimo de TTL para impedir que una zona fuerce trabajo continuo mediante valores diminutos. Ese piso es una defensa local contra consumo computacional. Debe aparecer en el recibo porque aumenta el intervalo real; no es prueba de que la autoridad no cambió durante ese margen.

Un sistema que guarda solo “TTL restante” pierde el origen de la restricción. El operador necesita los tres valores, la política de piso, el instante de adquisición y la fecha límite aplicada.

La continuidad exige solapamiento

Una revalidación satisfactoria no consiste en volver a obtener cualquier respuesta. El padre debe seguir enviando un referral al mismo punto. El nuevo conjunto NS parental debe compartir al menos un nombre con el conjunto guardado. Si había DS antes y después, ambos conjuntos deben compartir al menos un firmante delegado.

Si ya no hay referral, aparece otro corte, el conjunto NS es completamente nuevo o el conjunto DS es completamente nuevo, la forma o la autoridad cambió. Pasar de DS vacío a no vacío, o al revés, también cuenta como cambio.

El solapamiento permite una transición escalonada. No obliga a mantener intacta toda la configuración. Pero tampoco certifica que el servicio, las direcciones y las claves sean equivalentes. Es una decisión sobre la continuidad segura del caché, no sobre propiedad, contrato o resultado de negocio.

Un nombre compartido conserva un puente. No convierte el puente en toda la carretera.

Cuando cambia el soporte, caen los descendientes

El borrador exige no utilizar datos en o por debajo de un punto cuya jerarquía o autoridad haya cambiado. La implementación puede borrarlos, cambiar de generación o invalidarlos de forma diferida; desde fuera, deben comportarse como ausentes.

La regla incluye más que los NS. Bajo aquella delegación pueden existir direcciones, correo, servicios, negativas almacenadas y cortes inferiores. Conservar resultados descendientes tras retirar su apoyo superior mantendría conclusiones sin autoridad vigente.

Por eso conviene revalidar desde la raíz hacia abajo. Un cambio superior puede hacer inútil el trabajo inferior. RFC 8020 muestra cómo una negativa puede abarcar lo que hay debajo de un nombre. Aquí ocurre la dependencia inversa: al desaparecer el soporte superior, los datos inferiores pierden su justificación aunque sus bytes sigan en memoria.

Verificación estricta y continuidad de servicio

El modo estricto puede retener la respuesta que originó la consulta hasta verificar que el servidor tiene nombre y dirección obtenidos autoritativamente. Con infraestructura firmada, reduce la redirección y la escucha por un intermediario.

También elimina el fallback. Si el conjunto NS del hijo está roto o sus servidores responden mal a consultas explícitas del ápice, la resolución puede fallar por completo. La revisión 14 aconseja limitar esta mejora estricta a la raíz y a las zonas delegadas directamente por ella.

El modo oportunista puede entregar la respuesta antes de terminar la validación y volver a los datos del referral parental. Si el hijo no responde correctamente a la consulta NS, el resolutor abandona el algoritmo para esa zona. La disponibilidad mejora, pero el grado de protección es menor.

Por tanto, una métrica binaria “revalidación habilitada” oculta la decisión principal. Hay que distinguir respuestas retenidas, respuestas entregadas antes del control, fallbacks y generaciones de caché realmente sustituidas.

DNSSEC deja infraestructura sin firmar

Los NS del referral, la glue y ciertas direcciones de la sección adicional no están protegidos habitualmente por firmas DNSSEC. Un atacante que altera una dirección puede presentar un servidor hostil como autoritativo y modificar material no firmado en referrals posteriores.

RFC 5452 reduce la probabilidad de aceptar respuestas falsificadas mediante una mejor coincidencia de transacciones y más entropía. La revalidación resuelve otra capa: si la infraestructura seguida conserva credibilidad y apoyo parental.

Una firma válida demuestra autenticidad dentro de su alcance. No prueba que el resolutor volvió al padre a tiempo, que actuó sobre el resultado, que invalidó todos los descendientes o que la aplicación alcanzó el servicio correcto.

Explicar el desacuerdo no lo corrige

La revisión 14 solicita un código Extended DNS Error para el desacuerdo del conjunto NS de un referral. RFC 8914 ofrece un canal de diagnóstico. El código puede explicar por qué se rechazó una ruta, pero no decide cuál operador tiene razón, no publica el nuevo contenido y no verifica la recuperación.

El registro útil enlaza el EDE con la respuesta parental exacta, los conjuntos comparados, los TTL, el modo, la acción sobre el caché y la consulta posterior. Fuera de esa cadena, el código es solo una etiqueta.

RFC 9471 delimita cuándo la glue es necesaria para atravesar una delegación. Que una dirección sea necesaria y alcanzable tampoco la transforma en prueba de delegación vigente ni en evidencia de servicio.

Capacidad implementada no es estado observado

El apéndice del borrador afirma que Unbound ofrece revalidación oportunista con harden-referral-path, desactivada por defecto, y que implementa la sección 7 desde la versión 1.4.17. También registra revalidación del priming de raíz en Knot Resolver. Para el modo estricto, no conoce implementaciones fuera de prototipos y herramientas de los autores.

Son datos importantes sobre código existente, no un censo actual. No establecen la configuración de una instalación, los defaults de cada distribución, la tasa de fallos, la adopción o la interoperabilidad. Para afirmar operación hay que observar binario, configuración, temporizadores, consultas y cambios del caché.

Un recibo que no confunda respuesta y autoridad

El expediente debe conservar la versión y el modo del resolutor; el referral parental original con NS, DS y glue; el NS autoritativo del hijo; las direcciones recuperadas; los tres TTL; el piso local; la cadena desde la raíz; la respuesta parental nueva; los cálculos de solapamiento; cualquier transición DS vacío/no vacío; la generación invalidada; el fallback, fallo o EDE; el servidor nuevo elegido; y una observación independiente del resultado de servicio.

Así, una respuesta antigua puede seguir existiendo sin gobernar la decisión. DNS no necesita fingir simultaneidad. Necesita impedir que la continuidad de los paquetes sea confundida con la continuidad de la autoridad.

Fuentes