Resumen

  • ZONEMD compara el objeto canónico de una zona con un resumen ligado a un serial SOA; DNSSEC aporta la autenticidad de origen que el resumen sin firma no puede ofrecer.
  • El éxito prueba identidad e integridad del objeto publicado, no que sus registros expresen la intención correcta ni que el rechazo automático sea siempre la respuesta operativa más segura.

Pensemos en dos copias de una zona. Son visualmente distintas: cambia el uso de mayúsculas, el orden del archivo, los comentarios y los espacios. Sin embargo, representan exactamente los mismos registros DNS. ZONEMD debe considerarlas iguales. Ahora cambiemos una sola dirección por otra equivocada y calculemos de nuevo el resumen con autorización. La nueva zona es criptográficamente coherente y operativamente errónea. Esa diferencia contiene toda la cuestión.

RFC 8976 creó un registro que acompaña al propio contenido de la zona. La comprobación ya no depende de conservar el canal por el que llegaron los datos. Un secundario, un archivo, un consumidor de RPZ o una instancia local de la raíz puede verificar más tarde el objeto completo que recibió.

El ZONEMD válido para la norma está en el ápice y usa el tipo 63. Sus cuatro campos son serial, esquema, algoritmo de resumen y digest. El serial procede del SOA y debe coincidir exactamente durante la verificación. De ese modo, la huella no certifica “alguna versión” de un nombre, sino una instancia concreta de su contenido.

El esquema SIMPLE utiliza el formato canónico en el cable y el orden de RFC 4034. Incluye glue y datos ocultos por una delegación, elimina duplicados idénticos y excluye el marcador ZONEMD del ápice y la firma que cubre ese conjunto. Un registro ZONEMD fuera del ápice se resume como cualquier otro registro, pero no sirve para verificar la zona. La presentación del fichero deja de ser autoridad sobre la identidad del objeto.

El registro de IANA mantiene SIMPLE con valor 1; SHA-384 y SHA-512 son los algoritmos públicos 1 y 2. La combinación SIMPLE/SHA-384 es obligatoria para las implementaciones conformes. En una transición puede haber varios pares distintos, y basta una coincidencia respaldada por un algoritmo que la política local acepte. Por eso una migración necesita fecha de retirada: mantener el par viejo conserva su superficie de riesgo.

La secuencia de control empieza antes de calcular nada. El receptor decide si espera DNSSEC, consultando sus anclas y, si hace falta, el DS validado del padre. Si una prueba DNSSEC afirma que ZONEMD existe y el registro falta en la copia, no puede declararse éxito. Cuando se esperan firmas, SOA y ZONEMD deben validarse. Después vienen la unicidad del par, el serial, el soporte del esquema y algoritmo, la longitud y, por fin, el cálculo y la comparación.

En una zona no firmada, un atacante que puede alterar los registros también puede generar un resumen nuevo. ZONEMD funciona allí como detector de accidentes, no como autenticación. Con DNSSEC, la afirmación se vincula a una cadena que el receptor acepta. El marco general y sus límites están en RFC 4033. No hay competencia entre ambos mecanismos: DNSSEC autentica conjuntos de registros; ZONEMD añade integridad del conjunto completo de la zona.

La semántica queda fuera. Un resumen no sabe si el destino de un servicio era el correcto, si la eliminación tenía aprobación contractual, si una política de respuesta crea falsos positivos o si un cambio estaba previsto para mañana. Una zona publicada por el actor legítimo puede contener el error legítimamente publicado. Decirlo no rebaja la criptografía; evita que una prueba precisa sea usada como certificado universal.

Las implementaciones actuales reflejan ese reparto. Knot DNS separa la verificación en cada carga o actualización de la generación SHA-384/SHA-512, con ambas funciones desactivadas por defecto. Unbound ofrece controles distintos para verificar, exigir presencia y operar en modo permisivo; este último registra el fallo sin bloquear la zona. PowerDNS documenta una verificación explícita de fichero. Implementar el tipo 63 no decide por sí solo cuándo dejar de servir.

RFC 8976 describe una tensión operativa honesta. Rechazar una zona incompleta aumenta la resiliencia, pero un dato perdido o un error de software puede inutilizar información que en lo demás era buena. Para el comparador, sabotaje y fallo de publicación son indistinguibles. Por eso el propio texto sugiere una introducción gradual: primero advertir, luego bloquear cuando la organización haya observado su cadena real.

La continuidad no exige aceptar el candidato. RFC 5936 modela AXFR en dos pasos: guardar y revisar una nueva copia, y cargarla atómicamente solo después; ante un error se elimina el candidato y se sigue sirviendo la versión anterior si existía. ZONEMD mejora la revisión previa, mientras que la última versión conocida como buena mantiene el servicio y la evidencia.

Esa protección también necesita un límite. Servir indefinidamente una zona vieja puede ser tan peligroso como admitir la nueva. La política debe fijar edad máxima, señales de escalado y quién decide cuando el candidato sigue fallando. La elección no está dentro del digest porque depende del daño particular de cada zona.

Hay además una dependencia temporal. El editor debe publicar conjuntamente SOA y ZONEMD. Firmar el ZONEMD no puede incrementar otra vez el serial y romper la asociación recién creada. Una RRSIG todavía vigente puede dejar de ser verificable si, tras un cambio de KSK, ya no está disponible el DS o el ancla que permitía reconstruir la cadena.

SIMPLE recalcula toda la zona con cada modificación. RFC 8976 lo desaconseja para zonas grandes o muy dinámicas cuando el coste se acerca al intervalo entre actualizaciones; Knot advierte del consumo de CPU. El control solo es sostenible si el tiempo de cálculo cabe holgadamente en el presupuesto de propagación.

La arquitectura de decisión debe mostrar seis capas: candidato recibido, identidad canónica ZONEMD, autenticidad DNSSEC, coherencia semántica, admisión local y respuestas efectivamente servidas. Las notas de Heng Lu sobre primacía del código en ejecución, especificación inicial mínima y decisión futura localizada y capas de realidad ofrecen el criterio: una regla común puede verificar de forma determinista sin apropiarse de decisiones que deben seguir en manos de quien opera.

La lista de erratas de RFC 8976 conserva una corrección técnica para un ejemplo de apéndice cuyo SHA-384 privado aparece truncado. La regla normativa de 48 octetos no cambia. Registrar esa excepción enseña el mismo hábito que requiere ZONEMD: conservar la procedencia exacta y no redondear una anomalía hasta hacerla desaparecer.

Por tanto, el control completo no termina con “match”. Termina cuando se puede responder qué serial se comprobó, con qué cadena, algoritmo y versión de software; qué política admitió o aisló el candidato; qué estado anterior quedó disponible; y qué respuestas produjo luego el servidor. Solo entonces la prueba criptográfica se convierte en evidencia operativa.