Resumen

  • DNSOP mantiene hasta el 16 de septiembre la consulta de adopción de draft-farrokhi-dnsop-ede-nta-01. El texto continúa siendo un Internet-Draft individual, no un RFC ni una decisión concluida.
  • EDE 33 comunica que una NTA que cubría el nombre estaba activa al generarse la respuesta. El propio borrador permite incluirlo aunque la excepción no tuviera un efecto material sobre esa respuesta.
  • Un registro de efecto acotado puede enlazar el origen del EDE y la protección del trayecto con una validación contemporánea sin NTA, o conservar explícitamente no medido, sin repetir el expediente de autorización y caducidad.

La consulta y el registro llevan relojes distintos

La convocatoria de DNSOP se abrió el 2 de septiembre para decidir si el grupo asume el documento. Cierra el día 16. El Datatracker aún muestra Call For Adoption By WG Issued; la revisión 01 es un borrador individual de carácter Informational. No hay un resultado de adopción ni un RFC.

Sin embargo, el registro de parámetros DNS de IANA ya asigna el 33 a Negative Trust Anchor. El número evita que las primeras implementaciones colisionen. No concede custodia al grupo, no vuelve definitivo el texto y no demuestra despliegue.

Es una diferencia institucional pequeña y necesaria. IANA coordina un valor. Los copresidentes registran el resultado de la consulta. Una eventual publicación fija otro estado. Los operadores deciden qué software ejecutar. Un mismo titular no debería comprimir cuatro hechos en uno.

La excepción ocurre dentro del resolver

El RFC 7646 sitúa la NTA en el resolver recursivo. En un nombre seleccionado, el validador interrumpe la cadena DNSSEC ordinaria y trata las respuestas cubiertas como si la zona fuera insegura. No repara el RRSIG, no cambia la delegación y no convierte al resolver en autoridad del dominio.

El texto exige disciplina precisamente porque la disponibilidad se recupera suspendiendo una protección. La creación no debe ser automática. Personal capacitado debe valorar si hay configuración defectuosa o ataque, excluir dominios rotos a propósito y tratar de contactar con el responsable de la zona. La excepción ha de ser estrecha, probarse periódicamente y expirar sola. Su vida no debería superar una semana; cuando la validación vuelve a funcionar, debe retirarse cuanto antes y limpiar la caché correspondiente.

Ese expediente de autorización, alcance, vencimiento y retirada ya pertenece a otra cobertura. Aquí el objeto no es justificar de nuevo la NTA. Es interpretar el rastro que recibe un cliente en una sola respuesta.

Cubrir una respuesta no equivale a cambiarla

La revisión 01 dice que una o más instancias de EDE 33 indican que había una NTA aplicable cuando se generó la respuesta. El dato es diagnóstico. No modifica el bit AD ni el procesamiento DNS, y no está pensado para servidores únicamente autoritativos.

El operador debería enviarlo en respuestas afectadas. Pero también puede enviarlo en cualquier respuesta mientras la NTA esté activa, con independencia de que haya alterado materialmente el contenido. Ese permiso es el corazón del límite probatorio.

Imaginemos dos consultas dentro de la misma rama. La primera daría Bogus sin NTA y ofrece datos gracias a la excepción. La segunda validaría con normalidad en ambos caminos. Las dos pueden incluir 33. Una registra intervención; la otra registra contexto. El receptor no dispone del resultado contrafactual.

Obligar al resolver a repetir cada validación con y sin NTA sería costoso y ampliaría el mecanismo. El borrador opta por una señal sencilla y pide que se lea como tal. La transparencia mejora porque la excepción deja de ser invisible; la inferencia debe seguir siendo prudente.

Los campos estructurados no cierran la brecha

EXTRA-TEXT puede contener el nombre configurado, la razón, una referencia o la duración esperada. El formato estructurado permite que d identifique el dominio de la NTA y que t indique hasta cuándo podría permanecer activa.

Son datos opcionales y de alcance limitado. d no demuestra que esa excepción cambió la respuesta. t no certifica su eliminación; es un horario indicativo. La razón es texto del operador, no una auditoría independiente. Si coinciden varias NTA, el resolver puede enviar varias instancias y debe añadir texto a cada una, pero el conjunto sigue sin resolver la causalidad.

El RFC 8914 trata todo EDE como información complementaria que no debe cambiar el procesamiento. Tampoco tiene autenticidad inherente. Un transporte protegido puede asegurar un salto, mientras un reenviador puede suprimir, retransmitir o generar otro EDE. La atribución del origen es importante porque el último salto puede parecer el autor.

Por ello, la afirmación válida es: “el sistema que respondió declara que una NTA cubría esta respuesta en ese momento”. No demuestra que la zona estuviera rota, que la decisión fuera correcta, que el contenido dependiera de ella o que aún siga activa. Y la ausencia del código tampoco prueba que no hubiera NTA: la emisión es SHOULD y un intermediario puede retirarla.

La automatización reparó el escenario de prueba

El hilo de adopción dejó una ilustración excepcionalmente clara. El borrador usa una delegación hija deliberadamente inválida para mostrar EDE 33. En una respuesta del 2 de septiembre, el coautor Joe Abley avisó de que la maquinaria predeterminada de Cloudflare seguía reparando la delegación o eliminando el corte de zona. En ese momento el ejemplo vivo ya no coincidía con la condición descrita, y anunció que lo corregirían.

No es prueba de una caída ni de una mala NTA. Es una advertencia sobre la vigencia de la evidencia. La prosa queda fijada en una revisión; el DNS usado para demostrarla cambia por automatización. Una señal de presencia no puede conservar por sí sola el contrafactual que desapareció.

Una discusión anterior sobre la implementación ya había mostrado una respuesta real con EDE 33. Desde ella no se podía saber si la NTA estaba en el nombre consultado o en un ancestro, si coexistían varias ni si la respuesta habría validado normalmente. La señal decía algo útil y no decía lo demás.

Medir el efecto fuera del paquete

No conviene introducir direcciones de clientes, tickets internos, historiales de consulta o detalles de seguridad en EXTRA-TEXT. Falta un registro de efecto de la NTA separado. Es una propuesta editorial mía, no una obligación de IETF, IANA ni del operador.

Para una muestra o incidente, puede unir la hora y huella de la respuesta; el rol del resolver o reenviador; el origen del EDE; la protección del salto; los valores d y t recibidos; el bit AD; una validación contemporánea en un entorno aislado sin NTA, o la razón no medido; la diferencia de datos o resultado; y un enlace al expediente independiente de autorización y vencimiento.

No hace falta duplicar toda consulta de usuario. Se puede muestrear, reproducir de forma segura o preservar la ausencia de medida. Los informes públicos pueden agrupar clases de efecto sin exponer nombres o usuarios. El valor está en no rellenar un vacío con una explicación no observada.

El Policy Mirror de Heng Lu obliga a separar actor, regla y prueba: IANA mantiene el índice, el proceso IETF define el estado documental, el operador decide la excepción y un trayecto concreto entrega el aviso. Running Code Primary recuerda que la comparación definitiva pertenece al resolver observado, no a la intención del borrador.

EDE 33 vuelve legible una excepción. Su precisión depende de no convertir esa presencia en una causa que nunca midió.

Fuentes

  1. Consulta de adopción de DNSOP
  2. Registro actual del Datatracker
  3. Divulgación de NTA en respuestas DNS, revisión 01
  4. Historial del documento
  5. Aviso de Joe Abley sobre el ejemplo
  6. Discusión del límite de implementación
  7. RFC 7646 — Negative Trust Anchors de DNSSEC
  8. RFC 8914 — Extended DNS Errors
  9. Parámetros DNS de IANA
  10. Registro del grupo DNSOP
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary