Resumen

  • RFC 9567 permite que una respuesta autoritativa anuncie sin solicitud previa un agente mediante EDNS Report-Channel. El resolutor validador que observa un Extended DNS Error crea después una consulta TXT distinta; el informe no modifica la respuesta original.
  • No existe autenticación integral entre resolutor y agente. TCP o DNS Cookies dificultan falsificar la dirección, pero la caché, el límite del nombre y el criterio del agente siguen determinando qué señal llega y cuánto vale.

Una firma expira en una copia autoritativa de una zona. El servidor sigue contestando y quizá sus métricas no muestran pérdida. Un resolutor que valida DNSSEC recibe el RRset, examina la cadena y lo rechaza. El operador de la zona no presencia esa decisión porque ocurre al otro lado de la relación DNS.

RFC 9567 convierte esa asimetría en un mecanismo pequeño. La respuesta puede incluir la opción EDNS 18, Report-Channel, con el dominio de un agente. Es un anuncio espontáneo: la pregunta no necesita esa opción y jamás debe llevarla. El servidor autoritativo señala un buzón; no ordena al resolutor utilizarlo.

Si el resolutor soporta la función, está configurado para informar y clasifica el fallo con un Extended DNS Error, construye otra pregunta. Un error EDE 7 al validar el tipo A de broken.test puede producir _er.1.broken.test.7._er.a01.agent-domain.example. La consulta solicita TXT, aunque la sustancia del informe ya está en el QNAME.

La nueva transacción separa diagnóstico y autoridad. No devuelve una corrección dentro del paquete fallido ni cambia su RCODE. El agente responde como autoridad de su propio dominio. RFC 9567 no asigna significado al RDATA TXT; la respuesta positiva sirve para cerrar la consulta y, mediante su TTL, evitar repeticiones excesivas.

Quien anuncia el canal no crea la observación

El operador autoritativo elige el dominio del agente. El resolutor elige si el hecho observado merece un EDE y si su política permite comunicarlo. El agente decide cómo graduar la procedencia y agrupar señales. El responsable de la zona decide si cambia claves, firmas, delegación o datos. Compartir una gramática no transfiere esas facultades.

El registro de parámetros DNS de IANA demuestra que el código 18 y _er tienen un significado interoperable. No demuestra que una implementación esté activa, que un informe haya atravesado la red o que el diagnóstico sea correcto.

EDE tampoco es un veredicto universal. RFC 8914 conserva intacto el tratamiento del RCODE y añade información causal. RFC 9567 no define todos los errores ni obliga a todos los resolutores a reconocerlos. El agente recibe una afirmación acotada: un proceso concreto aplicó este código a este nombre y tipo.

En DNSSEC, una firma caducada o una discrepancia DS/DNSKEY puede reproducirse con material público. Pero también una ancla local obsoleta puede hacer que el resolutor informe un problema propio. Por eso la primera tarea del agente no es editar la zona, sino validar de nuevo desde una posición independiente.

El incidente viaja dentro del nombre

El QNAME del informe concatena _er, el QTYPE decimal, el nombre que falló, el código EDE, otro _er y el dominio del agente. No incluye la clase DNS ni el RCODE ordinario. La primera marca indica que llegó el informe completo y no un prefijo visto durante la minimización; la segunda delimita el hecho y el destino.

El diseño hereda el máximo de 255 octetos para un nombre DNS. Si el informe lo supera, no se envía. Además, el resolutor debe limitar profundidad o gasto, porque resolver el dominio del agente podría fallar y provocar otro informe. Una cadena infinita sería peor que perder una señal.

El agente no debe quedar debajo del dominio que se vigila. De lo contrario, la misma avería puede bloquear su salida. Un nombre corto del agente deja espacio para nombres originales largos. La topología nominal forma parte de la fiabilidad.

Una dirección comprobada no autentica una causa

RFC 9567 no autentica al resolutor frente al agente. UDP admite suplantación de origen, y una fuente real también puede equivocarse. El resolutor debería usar DNS Cookies, DNS sobre TCP u otro transporte con conexión. Si llega UDP sin Cookie, el agente debería responder con TC y exigir reintento por TCP.

Estas pruebas elevan la confianza en que alguien puede recibir tráfico en la dirección indicada. No acreditan una organización, un cliente, un estado de anclas ni la verdad del EDE. Una dirección conocida puede justificar prioridad de revisión, pero nunca una modificación automática del DNS.

Conviene modelar la procedencia por niveles. UDP sin Cookie es una pista barata. Cookie o TCP aportan resistencia a la falsificación. Varios resolutores independientes y una reproducción limpia convierten la pista en incidente. La autorización para cambiar la zona pertenece todavía a su control de cambios.

La caché amortigua y también oculta

El agente debería devolver una respuesta TXT positiva. Su TTL hace que un resolutor no repita el mismo informe en cada consulta. Ese ahorro protege la función principal del resolutor y al agente, pero rompe cualquier equivalencia entre «un informe» y «un usuario afectado».

Responder NXDOMAIN puede bloquear mucho más. RFC 8020 permite tratar como inexistentes los descendientes, y RFC 2308 conserva la negación. Por ello el agente no debe devolver NXDOMAIN para los nombres que supervisa; un comodín positivo puede cubrir el espacio.

Si la zona del agente está firmada, RFC 8198 permite sintetizar respuestas negativas desde NSEC o NSEC3 ya validados. Nuevos informes pueden no salir del resolutor. RFC 9567 considera mantener sin firma el dominio del agente para evitar esa carga concreta, pero exige la validación normal de las respuestas: no se puede tratar como inseguro un dominio de víctima que realmente está firmado.

La desaparición de consultas no prueba recuperación. Puede significar que la firma se reparó, que el TTL sigue vigente, que una negación fue sintetizada, que el agente cayó o que el resolutor dejó de informar. La comprobación decisiva es volver a obtener una respuesta validable desde una vista independiente.

El canal también puede ser dirigido contra terceros

El QNAME revela al agente el nombre fallido, el tipo y el código. También puede delatar una configuración local defectuosa del resolutor. La minimización reduce la exposición intermedia, no la información que necesita el destino final.

Un atacante puede publicar una zona rota y señalar como agente el dominio de una víctima. Resolutores abiertos o sistemas distribuidos generarán tráfico adicional hacia ella. Una oleada falsa puede ocultar un incidente verdadero. Límites por origen, pruebas de transporte, independencia entre zona y agente y comparación con validaciones externas son controles necesarios.

El TXT de respuesta tampoco debe convertirse en entrada de confianza. Como RFC 9567 no define su contenido, el agente puede usar una respuesta fija y tratar cualquier texto registrado como hostil. El informe está en la pregunta, no en una instrucción devuelta por un nombre remoto.

Las ideas de Heng Lu sobre primacía del código en funcionamiento, especificación mínima y decisión localizada y capas de realidad ayudan a no mezclar pasos. La norma define una ruta. El servidor la anuncia. El resolutor juzga. La red entrega. El agente pondera. El operador repara. La validación posterior demuestra el efecto.

Una auditoría útil conserva respuesta original, estado DNSSEC, agente anunciado, QNAME calculado, motivos de descarte, transporte, Cookie, TTL, reproducción, decisión y resultado después del cambio. Solo así una pregunta adicional se convierte en retroalimentación responsable.