Resumen

  • La revisión 14 del borrador DNSOP sobre revalidación mantiene una delegación como continua cuando el padre sigue remitiendo al mismo punto y el conjunto NS actual comparte al menos un nombre con el almacenado. Si había DS en ambos estados, también debe coincidir al menos un firmante delegado.
  • Un NS completamente nuevo, un DS completamente nuevo o el cambio entre ausencia y presencia de DS significa autoridad nueva para el algoritmo. Los datos almacenados en ese punto y por debajo dejan de ser utilizables; la revalidación estricta y la oportunista reparten de forma distinta la caída y el fallback.
  • La intersección no autentica la migración. Un recibo de transición debe fijar los miembros que se solapan, los estados padre e hijo, el cambio de registro, los tres TTL, la retirada y el responsable de volver atrás. Es una propuesta de Daniel Kade, no una exigencia del IETF.

El DNS clásico describe una delegación desde dos lados. El padre entrega NS, glue y, cuando corresponde, DS. El hijo publica en su ápice un NS autoritativo. La RFC 1034 pide que ambos administradores mantengan consistentes los registros que forman el corte, pero no existe una operación DNS que cambie simultáneamente las dos zonas.

La discrepancia puede ser rutinaria. Los TLD pueden imponer TTL largos, mientras el titular usa uno breve en el hijo. El registro y el proveedor DNS ejecutan colas diferentes. Las respuestas mínimas eliminan datos no imprescindibles, por lo que una aplicación normal quizá nunca provoque que el resolutor vea el NS del ápice. De ahí la diversidad: algunos resolutores prefieren el padre, otros el hijo y otros dependen de la secuencia concreta que llegó a su caché.

La revisión 14 de Delegation Revalidation by DNS Resolvers, fechada el 2 de septiembre de 2026, propone un algoritmo opcional. Es un Internet-Draft activo del grupo DNSOP, con destino Standards Track y estatus previsto Proposed Standard. En Datatracker espera el visto bueno de los presidentes del grupo y caduca el 6 de marzo de 2027. No es una RFC ni una orden de despliegue.

El diseño hace tres trabajos. Consulta expresamente el NS autoritativo del ápice hijo después de seguir una remisión y lo eleva por encima de la copia no autoritativa del padre, siguiendo la clasificación de la RFC 2181. Busca también versiones autoritativas de las direcciones A y AAAA asociadas. Y, al expirar el límite pertinente, vuelve al padre para averiguar si la delegación aún existe y conserva continuidad suficiente.

La continuidad cabe en una intersección pequeña

El resolutor guarda los nombres que recibió del padre, el TTL del NS y el TTL del DS cuando lo vio. En la revalidación, el padre debe seguir respondiendo con una remisión al mismo punto. Entre el NS anterior y el actual ha de quedar por lo menos un nombre común.

Si tanto la fotografía antigua como la nueva contienen DS, la regla exige además un firmante delegado común. Esta condición impide resumir el mecanismo como «una máquina igual basta». La continuidad del camino de firma tiene su propia comparación.

No se pide mayoría. Un conjunto antiguo de cuatro NS puede transformarse en uno antiguo y tres nuevos. Un rollover puede mantener un firmante mientras añade el siguiente. La flexibilidad evita que toda migración gradual vacíe de inmediato el árbol de caché que depende de la delegación.

La ruptura se define con igual precisión. Si ya no hay remisión, cambia el punto del corte, todos los NS son nuevos, todos los DS son nuevos o el DS pasa de vacío a no vacío —o al revés—, la jerarquía o la autoridad cambió. Los datos en ese punto y bajo él no pueden seguir usándose. Pueden borrarse físicamente o quedar fuera de una nueva generación, pero el comportamiento debe equivaler a su ausencia.

La prueba es deliberadamente mecánica. No sabe si el nombre superviviente pertenece al antiguo proveedor, a una plataforma compartida, a un servicio del registrar o a una dependencia olvidada. No demuestra que el servidor esté sano ni que el titular aprobara su permanencia. Resuelve el problema del caché, no la gobernanza contractual.

La verdad autoritativa del hijo no cancela al padre

El hijo es autoritativo para su NS de ápice. Por eso su respuesta tiene mayor credibilidad que la remisión paterna. Como las aplicaciones casi nunca preguntan por ese RRset, el borrador recomienda enviar una consulta NS dedicada en paralelo a la resolución que descubrió el corte.

Si responde bien, las consultas siguientes deben preferir los servidores del hijo. Si falla o devuelve NODATA, el conjunto del padre conserva la mejor posición disponible. En el modo oportunista, el resolutor puede haber servido ya la respuesta del usuario antes de completar la mejora.

Sin embargo, el hijo no puede renovar para siempre su propio mandato. El padre puede haber retirado la delegación o haberla enviado a otro operador. Un resolutor que refresca únicamente el NS del hijo podría aferrarse al proveedor anterior después de una redelegación. Volver al padre impide que la autoridad antigua sobreviva solo porque continúa respondiendo.

Las direcciones de los servidores tienen una cadena de confianza diferente. El glue permite arrancar, aunque sea no autoritativo. Un RRset completo, firmado y validable puede adquirir rango autoritativo; de lo contrario se necesitan consultas específicas. Si todas las direcciones mejores son inalcanzables, el resolutor puede conservar glue inferior como último recurso.

Esa reserva evita caídas, pero convierte el camino real en una decisión de estado. Una lista pública de NS no revela qué dirección estaba viva, qué nivel de caché venció ni si el fallback se activó.

Estricto y oportunista no significan lo mismo

La variante estricta puede retrasar la respuesta inicial hasta verificar que procede de un nombre y una dirección obtenidos autoritativamente. Mejora la resistencia ante redirección y observación en tránsito. También elimina la salida de emergencia: un NS hijo roto puede causar un fallo duro.

Por esa razón, la revisión 14 recomienda limitar la promoción estricta a la raíz y a las zonas delegadas directamente desde ella. Más abajo existen zonas que no contestan correctamente una consulta explícita por el NS del ápice.

La variante oportunista favorece la respuesta inmediata. Aprende en segundo plano y, si el hijo trata mal la consulta, abandona el algoritmo para esa zona y usa la remisión paterna. Conserva disponibilidad, pero no ofrece la misma protección.

La política operativa debe indicar profundidad, variante, datos admitidos para fallback y alcance de la purga. Decir solamente que un producto «revalida delegaciones» oculta la decisión que determinará el impacto de una configuración defectuosa.

El menor de tres TTL no es un reloj universal

La revalidación debe dispararse, como máximo, al vencer el menor TTL entre NS paterno, DS paterno cuando existe y NS del ápice hijo. El padre limita el tiempo durante el que una delegación retirada puede seguir siendo aceptada. El hijo puede usar su TTL para pedir una revisión más rápida de sus servidores.

Pero el resolutor debe protegerse con un suelo mínimo razonable para que una zona no fuerce trabajo computacional continuo mediante valores diminutos. El borrador no fija ese suelo. El TTL publicado más corto no es, por tanto, una garantía de revocación simultánea en todos los cachés.

Los fallos se almacenan negativamente según la RFC 9520 para no repetir consultas agresivas. La revalidación de NS y direcciones puede añadir bastante tráfico a los autoritativos. Un límite de trabajo por consulta forma parte de la defensa frente a abuso.

Una alerta de diferencia no decide la causa

Cuando el NS del hijo difiere del padre, el resolutor puede informar a los canales RFC 9567 de ambos. La revisión propone un código Extended DNS Error para el desacuerdo, pero todavía aparece como TBD.

La diferencia no implica necesariamente fallo. Puede ser una fase correcta, un TTL fijo o un retraso de provisión. El informe aporta la observación de un camino y una hora. No autentica la solicitud de cambio ni dice si el miembro común es legítimo.

El equipo debe tratarlo como evidencia para conciliar. Tampoco el éxito de resolución cierra la cuestión: un servidor residual puede responder bien y carecer ya de un responsable reconocido.

El recibo que explica por qué queda uno

En una migración de A a B puede ser prudente mantener un NS de A y un firmante antiguo. Esa continuidad protege el tráfico. Si nadie registra su caducidad, la prudencia se convierte en autoridad residual.

El recibo de transición separa estado antiguo, estado objetivo y puente autorizado. Incluye NS y glue del padre, DS, NS de ápice y direcciones autoritativas. Identifica exactamente el nombre y el firmante comunes, el propósito y la condición de retirada.

Después enlaza la observación con el plano de control: referencia del cambio en registrar o registro, operador saliente, operador entrante, persona que aprueba la eliminación y responsable de reversión. No sustituye la autenticación ni guarda secretos; conserva el rastro hacia ella.

Los tres TTL aparecen por separado, junto al disparador mínimo y a la hipótesis sobre suelos de resolutores. Dejar de aceptar cambios en el proveedor anterior, eliminar el NS del padre, apagar su servicio autoritativo y dejar de ver tráfico son hitos distintos.

La vigilancia reproduce rutas estrictas y oportunistas. Un resultado correcto en fallback no prueba que el camino estricto funcione. Si la transición deliberadamente usa conjuntos totalmente nuevos, el recibo anticipa la purga descendente y la carga posterior.

Para cerrar, padre e hijo deben converger, el miembro puente debe retirarse, el proveedor anterior debe dejar de responder fuera de lo acordado y la ventana de vuelta atrás debe terminar. El DNS no transporta este recibo. Su función es evitar que una prueba técnica de continuidad se convierta en una presunción administrativa de control.

Fuentes

  1. Revalidación de delegaciones por resolutores DNS — revisión 14
  2. Registro Datatracker del borrador
  3. Historial del documento
  4. Documentos activos de DNSOP
  5. Carta de DNSOP
  6. RFC 1034 — Conceptos y recursos del DNS
  7. RFC 2181 — Aclaraciones de la especificación DNS
  8. RFC 9520 — Caché negativo de fallos de resolución
  9. RFC 9567 — Informes de error DNS
  10. Delegación extensible para DNS — revisión 11