Resumen

  • RFC 9824 permite responder por un nombre inexistente con RCODE NOERROR, Answer vacía y un NSEC o NSEC3 firmado cuyo bitmap contiene NXNAME. La afirmación autenticada está en el cuerpo; la cabecera DNS no está protegida criptográficamente.
  • La señal EDNS Compact Answers OK puede restaurar NXDOMAIN, pero opera salto a salto. El resolvedor debe conservar esa capacidad junto a la prueba en caché y adaptar la presentación al siguiente consultante.
  • La respuesta compacta reduce pruebas y trabajo de firma frente a otras modalidades de firma en línea, pero pierde síntesis negativa agresiva. Validación, presentación, carga, consultas posteriores y resultado requieren recibos distintos.

La consulta adicional reveló una frontera invisible

El ejemplo inicial es hipotético. Sirve para mostrar una asimetría: el resolvedor puede poseer una conclusión firmada más precisa que la interfaz que entrega a la biblioteca. Si la observabilidad solo cuenta respuestas, la consulta A parece redundante. Si conserva la prueba, la capacidad y la decisión de presentación, explica exactamente por qué ocurrió.

RFC 9824 define Compact Denial of Existence in DNSSEC. En la negación tradicional, la prueba debe demostrar que no existe el nombre exacto y que tampoco pudo intervenir un wildcard. Un firmante en línea puede necesitar hasta dos NSEC firmados o tres NSEC3 firmados.

La respuesta compacta usa otra construcción. Ante un nombre inexistente sin coincidencia wildcard, el servidor autoritativo devuelve una respuesta con forma NODATA: NOERROR, Answer vacía y un único NSEC o NSEC3 firmado que coincide con el QNAME. Para producir la prueba, declara que el nombre existe pero carece del tipo solicitado. Una cobertura mínima reduce el material necesario.

La ficha de RFC Editor y el registro de Datatracker identifican el documento como Proposed Standard de septiembre de 2025 que actualiza RFC 4034 y 4035. El historial, las referencias y el conjunto de textos que lo citan permiten reconstruir su contexto público. No prueban soporte en un producto ni un despliegue.

NXNAME convierte el vacío en una afirmación verificable

Una Answer vacía admite varias realidades. El nombre puede existir sin el tipo consultado. Puede ser un empty non-terminal: existe porque tiene descendientes, aunque no contiene RRsets propios. También puede no existir. El bitmap escaso por sí solo no separa esos casos.

RFC 9824 asigna a NXNAME el valor 128 como Meta-TYPE sintético. En una respuesta compacta NSEC para un nombre inexistente, el bitmap contiene RRSIG, NSEC y NXNAME. Con NSEC3, NXNAME es la única entrada. Un empty non-terminal no lleva esa señal. La conclusión deja de depender de interpretar silencio y pasa a depender de datos firmados.

El registro IANA DNS Parameters coordina NXNAME, el flag CO y EDE 30. Tener código asignado no demuestra que un servidor lo produzca, que un resolvedor lo verifique o que una aplicación lo entienda.

NXNAME tampoco es un RR que tenga sentido consultar. Debe aparecer solo en el bitmap NSEC/NSEC3 de la prueba. Una consulta explícita por ese QTYPE recibe FORMERR; el servidor puede añadir EDE 30, Invalid Query Type, y el resolvedor no debe enviarla aguas arriba. RFC 8914 aporta el marco de Extended DNS Errors; RFC 9824 fija esta utilización.

El RCODE es presentación; la firma es evidencia

DNSSEC no protege criptográficamente la cabecera DNS. Por eso RFC 9824 advierte que el RCODE no se puede autenticar y que inferir el estado a partir del cuerpo firmado es más seguro.

Esta jerarquía no elimina la importancia operativa de la cabecera. Muchas API solo exponen NOERROR, NXDOMAIN u otro código. Una herramienta que vea NOERROR puede clasificar NODATA. El validador que compruebe RRSIG y NXNAME puede afirmar inexistencia. La discrepancia debe conservarse con su punto de observación; no debe resolverse escogiendo el campo más cómodo.

RFC 4034 define NSEC, RRSIG y otros RR de DNSSEC. RFC 4035 especifica su procesamiento y la negación autenticada. RFC 9824 introduce excepciones para la forma compacta dinámica. RFC 9364 resume DNSSEC y RFC 9499 fija el vocabulario DNS. Ninguno convierte una captura de RCODE en prueba firmada.

El recibo mínimo une pregunta, QTYPE, DO y CO, RCODE recibido, forma de prueba, presencia de NXNAME, identificadores públicos de algoritmo y clave, resultado de validación, versión de software, tiempo y huella del material firmado. Nunca incluye la clave privada.

CO permite restaurar un código, no reescribir la prueba

RFC 9824 pide preservar NXDOMAIN cuando resulte posible. Para respuestas DNSSEC define el flag EDNS Compact Answers OK. El resolvedor que envía CO declara que acepta NXNAME firmado junto con RCODE NXDOMAIN. El autoritativo que implementa ambos mecanismos puede devolver CO y restaurar ese código.

EDNS, según RFC 6891, es salto a salto. El resolvedor debe asociar la capacidad CO con los datos de caché. Si el siguiente cliente DNSSEC no manda CO, vuelve a presentar NOERROR para la respuesta NXNAME.

El contenido validado no cambió. Cambió la decisión local sobre compatibilidad. Perder CO al serializar la caché impide reproducir el contrato; guardar solo el último RCODE impide demostrar de dónde vino el veredicto.

Ahorrar material de prueba puede aumentar trabajo en otro lugar

RFC 4470 proporciona el antecedente de NSEC de cobertura mínima y firma en línea. RFC 5155 define NSEC3. RFC 9824 busca respuestas más pequeñas, menos operaciones de firma que otras técnicas dinámicas y menor exposición del contenido de la zona.

Sin embargo, la respuesta compacta no permite la síntesis de NXDOMAIN y wildcard de RFC 8020 y RFC 8198. Consultas por subdominios pseudoaleatorios que una caché agresiva podría absorber llegan al autoritativo. Además, la firma en línea mantiene capacidad privada en infraestructura alcanzable desde Internet y consume cálculo por respuesta.

La técnica reduce operaciones respecto de otras formas online; no equivale a firmas precomputadas. RFC 9824 reconoce la exposición a denegación de servicio computacional y permite escoger métodos convencionales cuando los beneficios de compacidad no justifican el coste.

El resultado pertenece a la aplicación observada

El caso AAAA/A demuestra que una prueba correcta no determina por sí sola la secuencia de la biblioteca. El stub puede no pedir DNSSEC. La caché puede entender NXNAME y adaptar el código a un cliente sin CO. El producto de seguridad puede leer el header y omitir el bitmap.

La primacía del código en ejecución exige seguir cada transición realizada: síntesis autoritativa, firma, validación, interpretación, caché, capacidad, RCODE emitido, nueva consulta y resultado de la aplicación. Las capas de realidad evitan llamar “nombre existente” a un NOERROR cuando la evidencia firmada dice lo contrario, pero también evitan llamar “éxito de aplicación” a una validación correcta.

Fuentes

  1. IETF Datatracker: RFC 9824
  2. Historial de RFC 9824
  3. Documentos que citan RFC 9824
  4. Referencias de RFC 9824
  5. Heng Lu: Minimum Initial Specification
  6. Heng Lu: Reality Layers
  7. Heng Lu: Running-Code Primacy
  8. IANA DNS Parameters
  9. Erratas de RFC 9824
  10. Información de RFC Editor
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824