Resumen

  • La revisión 01 de dry-run DNSSEC plantea un estado deliberadamente provisional: el resolutor compatible valida y notifica anomalías, pero ante un resultado inválido entrega al cliente común la respuesta insegura que habría obtenido sin el DS de ensayo.
  • El informe NOERROR propuesto acredita que un participante comprobó la zona con éxito. No cuenta a los resolutores silenciosos ni a sus clientes; además, el transporte de la RFC 9567 se amortigua con caché y no autentica la identidad del emisor.
  • Antes de sustituir en el padre el DS de ensayo por el DS real, hace falta un recibo de graduación que conserve cohorte, pruebas de cliente, límites del informe, estado parental e incógnitas. Es una recomendación de Daniel Kade, no una obligación del IETF.

El salto decisivo de DNSSEC ocurre fuera de la zona firmada. Mientras el padre no publica un DS, el operador puede revisar firmas sin haber creado una cadena pública de confianza. Cuando el DS real aparece, un error que ayer era interno puede convertirse en SERVFAIL para usuarios distribuidos entre resolutores y cachés ajenos.

El grupo DNSOP trabaja en un borrador que intenta insertar una etapa entre preparación y cumplimiento. La revisión 01 de dry-run DNSSEC fue publicada el 21 de junio de 2026. El documento se presenta para Standards Track, pero sigue siendo un Internet-Draft activo de grupo de trabajo. No es un RFC, no acredita consenso final y no demuestra que exista una implantación productiva. Sus códigos EDE y EDNS propuestos aún figuran por determinar.

La idea aprovecha la conducta definida por la RFC 6840 para algoritmos de resumen DS desconocidos. Un validador descarta el DS cuyo algoritmo no puede usar y, si no queda ninguna vía admitida de autenticación, trata al hijo como no firmado. El borrador propone derivar valores de ensayo mediante el bit más significativo y exige que todo el conjunto DS parental esté compuesto por tipos de ensayo, no por una mezcla.

Así nacen dos experiencias distintas. El resolutor que desconoce la propuesta ignora el algoritmo y resuelve de forma insegura. El que la implementa interpreta la señal, valida la zona firmada y puede informar del resultado. Si la validación es correcta, puede reconocer datos auténticos. Si es «bogus», no traslada el fallo normal de DNSSEC al cliente corriente: devuelve la respuesta insegura disponible sin aquella señal.

Ese comportamiento es abierto por diseño. No equivale a «algo de DNSSEC». El borrador indica que la delegación todavía no debe considerarse firmada y advierte que el retorno inseguro desactiva la garantía de integridad, permitiendo que una respuesta falsificada afecte a la zona. El ensayo reduce el riesgo de interrupción durante el diagnóstico a cambio de no hacer cumplir todavía la protección.

El fallo observado no es aún el fallo aplicado

Los Extended DNS Errors de la RFC 8914 permiten describir por qué falló la resolución. La RFC 9567 proporciona el canal de notificación: a partir de la información anunciada por el servidor autoritativo, el resolutor formula una consulta hacia el dominio de un agente de monitorización. En el nombre codifica el QNAME defectuoso, el QTYPE y el código EDE.

El operador recibe con ello evidencia de una ruta desplegada, no solo de un banco de pruebas. Intervinieron un validador real, sus decisiones de caché y una consulta que realmente llegó a esa infraestructura. El informe prueba algo útil y estrecho: cierto camino observó cierto error.

No prueba quién era institucionalmente el observador. La RFC 9567 no autentica el resolutor frente al agente. TCP y las DNS Cookies elevan el coste de falsificar la dirección de origen, pero no convierten esa dirección en identidad certificada. Los mensajes UDP y sus fuentes aparentes pueden ser falsos. Los avisos también pueden revelar defectos internos del resolutor, como anclas de confianza antiguas; por eso la RFC recomienda minimizar el nombre consultado.

Además, la caché amortigua envíos repetidos. Los nombres demasiado largos no se transmiten. La indisponibilidad del agente elimina otra parte de la muestra. El contador visible está modelado por protocolo y operación: no es el número bruto de consultas fallidas, resolutores distintos ni usuarios dañados.

Una señal positiva limita una ambigüedad

La ausencia de errores nunca tuvo una sola explicación. Puede significar una zona correcta, pero también ausencia de resolutores compatibles, falta de consultas, amortiguación previa, un agente inaccesible o una implementación que no informa.

La revisión 01 propone el código NOERROR para que un resolutor que valida con éxito comunique su presencia. El informe se construye en el ápice de la zona y también queda sujeto al caché, de modo que revela participación sin generar una señal por cada consulta.

El valor epistemológico es preciso. Un NOERROR demuestra que al menos un observador compatible atravesó una comprobación exitosa. Una combinación de NOERROR y errores describe resultados dentro de la cohorte vista. No descubre a quienes quedaron fuera: los resolutores incompatibles tratan el hijo como no firmado y callan deliberadamente; los compatibles sin tráfico también callan; un informe no enumera los clientes situados detrás ni los estados futuros de su caché.

El borrador cita como precedentes los informes DMARC, el centinela de la clave raíz de la RFC 8509 y la señalización de anclas de la RFC 8145. Todos muestran que una población pequeña, reciente y estratégicamente ubicada puede aportar señales valiosas. Ninguno concede a esa población el título automático de Internet entero.

Wet-Run ensaya la consecuencia aceptada

El cliente ordinario no experimenta el error porque el resolutor compatible vuelve a la respuesta insegura. Por tanto, los informes del resolutor no enseñan cómo responde una aplicación al rechazo que producirá el DS real.

La opción EDNS Wet-Run propuesta cambia esa decisión para una consulta explícita. El cliente pide recibir el verdadero error de validación del ensayo. El resolutor compatible conserva junto a la respuesta almacenada tanto el estado normal como el de ensayo y devuelve la opción al exponer el fallo. Quien no implementa la opción la ignora.

Aquí la unidad probada es una combinación concreta de aplicación, red y resolutor. El opt-in no cubre a las aplicaciones que no lo enviaron. Tampoco un NOERROR emitido por el resolutor sustituye la prueba de cómo procesa el cliente el fracaso. Registrar ambos como un único «aprobado» borraría el consentimiento y el alcance de cada medición.

Las respuestas negativas exigen todavía otra prueba. La RFC 8198 permite sintetizar resultados con pruebas NSEC o NSEC3 validadas que ya están en caché. Esa eficiencia puede ocultar una prueba negativa defectuosa porque no hay nueva consulta al autoritativo. El borrador pide suspender la síntesis durante la comprobación, preguntar de forma explícita, comparar respuestas y señalar la discrepancia mediante un EDE propuesto.

El padre gobierna el momento de graduación

La firma del hijo no basta para activar el ensayo. El padre debe aceptar y publicar el DS especial. Si su interfaz recibe DS, el hijo presenta el valor de ensayo. Si genera DS a partir de DNSKEY, necesita una indicación de modo o debe interpretar un CDS acompañante. CDNSKEY por sí solo no porta la distinción; el texto aconseja publicar CDS y CDNSKEY.

Graduarse significa pedir al padre que sustituya el conjunto de ensayo por el real. Conviene descomponer ese verbo: envío de la solicitud, aceptación, publicación observada y caducidad de estados anteriores en caché son hechos con tiempos distintos.

La sustitución no cambia solo una etiqueta. Bajo el ensayo, un resultado inválido genera telemetría y una respuesta insegura. Bajo un DS real que el resolutor admite, el mismo resultado puede impedir la resolución. Autorizar el cambio significa decidir cuándo actores externos empezarán a imponer las afirmaciones criptográficas del dominio.

La propuesta aún no posee su espacio registral

La revisión 01 pide identificar como DNSSEC de ensayo los valores 128–255 del algoritmo de resumen DS, usando el bit más significativo. El registro de IANA vigente, actualizado el 13 de enero de 2026, no muestra esa asignación: 128–252 constan como reservados, 253–254 como uso privado y 255 como no asignado, con referencia a la RFC 9904.

La discrepancia requiere una reconciliación explícita si la especificación avanza. No demuestra que IANA haya rechazado la idea: una acción solicitada por un borrador no es una asignación aprobada. Mientras tanto, ningún experimento debería presentar el bloque completo como si ya fuera espacio público concedido.

La RFC 9904 distingue además recomendación de uso y recomendación de implementación. Un algoritmo puede estar soportado por código y no estar desplegado por operadores. La misma cautela se aplica aquí: tener capacidad de ensayo, recibir consultas de esta zona y representar rutas de clientes importantes son tres hechos diferentes.

El recibo que une evidencia y autoridad

El recibo de graduación debería fijar primero objetos verificables: huella de la zona firmada, DNSKEY, conjunto DS de ensayo, solicitud al padre, aceptación y publicación observada. También la ventana temporal y los puntos autoritativos desde los que se comprobó la visibilidad.

Después debe definir la cohorte. Algunos resolutores podrán distinguirse con evidencia independiente; otros serán solo fuentes aparentes con mayor o menor confianza de transporte. Los NOERROR y errores se contabilizan junto con amortiguación, nombres, tipos de consulta y reparaciones efectuadas. Una agregación prudente protege la privacidad sin inventar identidades.

Las pruebas de cliente merecen un registro propio: Wet-Run por red, resolutor y clase de aplicación; comparación con el retorno ordinario; respuestas positivas y negativas; consultas explícitas frente a síntesis NSEC/NSEC3; horizontes de caché; poblaciones inalcanzables. Se adjunta la fotografía vigente del registro IANA y se rotulan como experimentales los valores aún no asignados.

Por último se nombra a quien puede ordenar el DS real, qué umbral y qué incertidumbres acepta, quién puede revertir y cómo se probó esa reversión. Solicitud, aceptación, publicación y validación posterior conservan horas separadas.

El propósito no es fabricar certeza mundial. Es impedir que una muestra conveniente pierda su frontera cuando llega al expediente de decisión. Una cohorte limitada puede justificar una acción si quien soportará sus efectos puede inspeccionar lo que incluye y lo que nunca observó.

Fuentes

  1. dry-run DNSSEC — revisión 01
  2. Ficha de dry-run DNSSEC en Datatracker
  3. Historial del documento
  4. Documentos activos de DNSOP
  5. Carta de DNSOP
  6. RFC 9567 — DNS Error Reporting
  7. RFC 8914 — Extended DNS Errors
  8. RFC 6840 — notas de implementación DNSSEC
  9. RFC 8198 — uso agresivo de caché validada
  10. RFC 8509 — centinela de ancla raíz
  11. RFC 8145 — señalización de anclas conocidas
  12. RFC 9904 — actualización de recomendaciones algorítmicas
  13. Registro IANA de algoritmos de resumen DS