Resumen

  • ZONEMD vincula un serial SOA con el resumen de toda la zona ordenada de manera canónica, incluidos el glue y los datos ocultos. Por eso puede rechazar una copia que llegó por completo y aparenta ser la versión correcta.
  • Con DNSSEC, la comprobación autentica el compromiso del publicador; sin DNSSEC solo detecta cambios accidentales. Ninguno de los dos casos demuestra que la política sea correcta ni que toda la flota esté sirviendo esa generación.

La incidencia empieza con una contradicción. El panel de distribución anuncia que todos los secundarios tienen el serial esperado. Los registros de AXFR muestran finalización normal. El archivo supera la comprobación sintáctica. Aun así, las consultas que dependen de una dirección de glue fallan desde una parte de la red.

La copia activa perdió un RR después de que el publicador construyera la zona. El número de serie no cambió, porque no es una medida del contenido. El canal no informó del problema, porque la alteración pudo ocurrir después de la transacción. El parser no lo consideró inválido, porque una zona sin ese registro todavía puede tener una gramática impecable.

RFC 8976 define ZONEMD para separar esos hechos. El RR situado en el apex contiene un digest de los datos de la zona en reposo. El receptor reproduce el orden canónico, calcula el resumen y lo compara con el publicado. Si un único registro incluido cambia o desaparece, el resultado deja de coincidir aunque el serial siga siendo el esperado.

Ver la versión no equivale a reconocer el objeto

El Serial de la SOA, definido originalmente en RFC 1035, permite que copias distribuidas identifiquen una actualización. RFC 1982 establece cómo comparar números de longitud finita alrededor del reinicio a cero. La regla resuelve el orden temporal sin depender de un reloj global.

No deriva una identidad del contenido. Dos procesos de publicación pueden producir conjuntos distintos bajo un mismo serial. Una copia puede truncarse en disco sin que cambie la SOA. Un backup puede restaurar datos antiguos junto con un número que parece actual. Comparar el serial recibido con el serial esperado no descubre ninguna de esas diferencias.

El RDATA de ZONEMD vuelve a incluir el Serial y añade Scheme, Hash Algorithm y Digest. Así quedan unidas dos afirmaciones que no deben confundirse. La SOA nombra la generación; el digest compromete el contenido canónico completo que pertenece a esa generación.

Esta función tampoco es otra forma de NOTIFY, IXFR o AXFR. RFC 1995 describe la transferencia incremental y RFC 5936 la transferencia completa. Esos mecanismos ayudan a adquirir o reconstruir una copia. ZONEMD permite volver a verificar el objeto después de que cruce almacenamiento, repositorios, restauraciones, firmantes y cargadores. La entrega es un evento; la custodia del contenido continúa.

SIMPLE elimina diferencias de presentación, no diferencias de significado

IANA asigna a ZONEMD el tipo RR 63. RFC 8976 normaliza el esquema SIMPLE con valor 1 y exige que las implementaciones lo soporten. SHA-384, algoritmo 1, también es obligatorio y publica 48 octetos completos. SHA-512, algoritmo 2, debería estar soportado y publica 64. El registro de parámetros DNS de IANA conserva además rangos no asignados y de uso privado.

SIMPLE no calcula sobre el texto literal de un archivo maestro. Los comentarios, espacios y mayúsculas pueden variar sin alterar los RR. La entrada se expresa en formato wire canónico sin compresión y se ordena según RFC 4034, añadiendo orden numérico de tipos para RRsets con el mismo owner. Dos archivos de aspecto diferente pueden producir el mismo digest si representan la misma zona; un RR semánticamente distinto no queda oculto por el formato.

El perímetro incluye todos los registros de la zona salvo excepciones expresas. Incluye glue. Incluye datos occluded. Cuenta una sola vez los duplicados exactamente iguales. Excluye material fuera de la zona. En una zona firmada incluye los RR de DNSSEC, excepto el placeholder ZONEMD del apex y la RRSIG que cubrirá el RRset ZONEMD definitivo.

Esta cobertura no convierte ZONEMD en sustituto de DNSSEC. DNSSEC autentica RRsets y las pruebas utilizadas al validar respuestas. La integridad de una zona completa como artefacto distribuido tiene otro alcance, especialmente para datos de delegación y glue que no se protegen del mismo modo que un RRset autoritativo ordinario del child. El digest de zona y la validación DNSSEC se complementan porque responden a consumidores y granularidades diferentes.

El recorrido completo tiene un coste. Con SIMPLE, cambiar un solo RR obliga a recalcular sobre toda la zona. RFC 8976 advierte que puede ser inadecuado para zonas grandes o muy dinámicas. La decisión operativa debe comparar el tiempo de cálculo y verificación con los intervalos reales de actualización y propagación, no limitarse a constatar que una versión de software ofrece la función.

La secuencia de firma determina si el compromiso es coherente

En una zona DNSSEC no basta con añadir ZONEMD al final. Su presencia en el apex afecta a los bitmaps de tipos de NSEC o NSEC3. El proceso elimina antiguos ZONEMD y sus firmas, inserta uno o varios placeholders antes de firmar y deja que las pruebas de inexistencia incorporen correctamente el nuevo tipo.

Después de la firma, SIMPLE calcula el digest sobre la secuencia canónica. No incluye los placeholders del apex ni la RRSIG que deberá cubrir el RRset ZONEMD final. El publicador sustituye el valor provisional por el digest y crea o actualiza esa firma específica.

La generación de la firma ZONEMD no puede provocar otro cambio en el Serial. La SOA y el ZONEMD que se corresponden deben publicarse al mismo tiempo. Si firmar el compromiso moviera de nuevo la versión, la referencia del digest quedaría obsoleta en el mismo acto que intenta autenticarla.

Por eso una evidencia de publicación útil no consiste solo en copiar una cadena hexadecimal. Debe vincular snapshot fuente, política aprobada, versión del constructor y firmante, Serial, esquema, algoritmo, digest, contexto de claves DNSSEC y momento de la publicación atómica. Conservar ese recibo permite localizar una divergencia entre fuente, construcción, firma y distribución.

La verificación empieza por las expectativas de seguridad

Un receptor necesita saber si la zona debería estar firmada antes de interpretar el resultado. Las trust anchors configuradas y, cuando corresponda, una cadena DS validada en el padre establecen esa expectativa. RFC 4035 aporta las reglas de validación DNSSEC aplicables.

Si se esperan firmas, hay que validar la existencia de ZONEMD y las firmas de SOA y ZONEMD. Una prueba autenticada de que el RRset no existe significa que no puede realizarse la comprobación. Si DNSSEC demuestra que debe existir pero la copia recibida no lo contiene, el resultado no puede llamarse éxito. Tampoco es legítimo degradar una firma inválida a un simple checksum porque el cálculo local coincida.

La siguiente capa examina la estructura. En un RRset con varios ZONEMD, cada combinación de esquema y algoritmo debe ser única. La política local puede ignorar combinaciones que no acepta. Para cada candidato permitido, el Serial tiene que coincidir exactamente con la SOA, el esquema y algoritmo deben ser soportados, el tamaño del digest válido y el resultado local igual al recibido.

Durante una transición basta con que coincida una combinación soportada y admitida. Esa flexibilidad hace imprescindible retirar el algoritmo antiguo. Cuando se publican varios, la seguridad global queda limitada por el más débil que un verificador todavía acepta. Una migración necesita condición de salida, no solo una fecha de incorporación.

El verificador debería emitir resultado y motivo. Ausencia esperada, fallo DNSSEC, serial distinto, combinación duplicada, algoritmo no soportado, longitud inválida y mismatch de contenido pertenecen a dominios de fallo diferentes. Un único semáforo rojo destruye la información necesaria para decidir si conviene reintentar, poner en cuarentena, volver atrás o escalar.

Firmar el digest no certifica la política del publicador

Sin DNSSEC, ZONEMD actúa como checksum. Puede revelar truncamiento, corrupción de almacenamiento o modificaciones accidentales mientras el digest original permanezca intacto. Un atacante capaz de cambiar la zona también puede recalcular y reemplazar el digest, de modo que no existe una protección real frente a esa amenaza.

Con DNSSEC se autentican SOA y ZONEMD hasta una trust anchor y se vuelve detectable la eliminación o alteración del compromiso. Lo que se autentica es que el publicador autorizado comprometió ese contenido. Una automatización autorizada también puede comprometer una delegación equivocada con perfecta consistencia criptográfica. La coincidencia no demuestra propiedad, intención legítima, cumplimiento de una solicitud ni seguridad de la aplicación detrás de los nombres.

TSIG delimita otra autoridad. RFC 8945 protege transacciones DNS con secretos compartidos y puede autenticar un par de AXFR o IXFR. Ese MAC no acompaña al archivo durante posteriores copias, restauraciones o reinicios. ZONEMD hace que la comprobación del objeto siga disponible después de agotarse la evidencia efímera del canal.

La validación firmada también depende del tiempo. Retirar un DS o cambiar trust anchors puede impedir una comprobación histórica aunque la RRSIG parezca vigente según sus propias fechas. Un archivo probatorio necesita conservar el contexto de confianza utilizado en la activación, no únicamente los bytes de la zona.

La integridad estricta crea una nueva decisión de disponibilidad

Un servidor puede verificar el candidato en staging y negarse a servirlo si falla. Esa es la ventaja operativa directa: contenido corrupto no alcanza el plano autoritativo.

El mismo mecanismo puede transformar un error de publicación en indisponibilidad. Una diferencia de canonicalización, un RR perdido o un bug resultan inicialmente indistinguibles de una manipulación. El rechazo de toda la zona priva del servicio incluso a sus datos correctos. En un despliegue con varios proveedores, respuestas distintas ante el fallo pueden fragmentar las generaciones visibles.

RFC 8976 contempla una adopción gradual, primero como advertencia y más tarde como error. El documento RZERC003 de ICANN trató la introducción en la raíz como coordinación entre mantenedor, operadores de servidores raíz, desarrolladores y consumidores de copias locales. No prescribe que cualquier zona copie una política de la raíz; demuestra que el enforcement modifica varios dominios de fallo y exige preparación conjunta.

Una política madura distingue tres destinos. Un candidato verificado queda habilitado para activarse. Un candidato fallido se aísla y la generación anterior, ya verificada, continúa durante un plazo definido. Una evidencia incompleta —por ejemplo, una cadena de confianza inaccesible en vez de un digest diferente— requiere una decisión fail-open o fail-closed atribuida a una persona o función concreta.

La generación anterior consume un presupuesto de obsolescencia. Mantiene integridad conocida pero pierde actualidad con cada cambio no publicado. Los temporizadores de la zona, la frecuencia de cambios y el impacto determinan cuánto puede durar. La reversión debe haberse probado: objeto disponible, verificación independiente, carga posible y observación de la generación recuperada en respuestas autoritativas.

El recibo de activación debe terminar en respuestas observables

El servicio autoritativo puede repartirse entre proveedores y emplazamientos anycast, como contempla RFC 8901. Que un host de staging valide no demuestra que todos cargaron. Que una API de despliegue responda con éxito no demuestra lo que sirve el proceso. Que un punto de red observe el nuevo Serial no cubre los demás catchments.

El recibo completo sigue una cadena de custodia. El publicador vincula fuente, Serial y digest firmado. El transporte o repositorio registra objeto, tamaño, hash local y eventos. El verificador conserva expectativa DNSSEC, trust anchors, combinación aceptada, cálculo y motivo. La activación vincula el objeto verificado con generaciones anterior y nueva. La observación consulta SOA, ZONEMD y RR incluidos desde el alcance de red exigido.

Los canarios no deben preguntar solo por SOA. Deben incluir nombres sensibles a delegación, direcciones de glue seleccionadas, RRsets firmados y respuestas negativas, conservando la identidad autoritativa y el punto de observación. Una raíz hyperlocal bajo RFC 8806 necesita un recibo propio para su copia y refresco; la salud de la raíz pública no demuestra la de esa instancia local.

Cerrar una reversión exige evidencia negativa. El digest rechazado debe desaparecer de la elegibilidad de staging, de los procesos activos y de las respuestas muestreadas. Encontrar la generación correcta en algunos lugares no excluye que un nodo olvidado continúe exponiendo la incorrecta.

Fuentes