Zusammenfassung

  • ZONEMD bindet den kanonischen Gesamtinhalt einer Zone an eine SOA-Seriennummer. Erst die passende DNSSEC-Validierung macht daraus einen Herkunftsnachweis statt nur eine Prüfsumme gegen Zufallsfehler.
  • Eine Übereinstimmung beweist, dass die empfangene Kopie dem veröffentlichten Objekt entspricht. Sie beweist weder die Richtigkeit der Records noch, dass eine sofortige Sperre betrieblich besser ist als der letzte bekannte gute Stand.

Der entscheidende Fehler kann vor jeder Kryptografie liegen. Ein berechtigter Administrator veröffentlicht versehentlich die Adresse einer Wartungsumgebung. Seriennummer, ZONEMD und Signaturen sind korrekt; alle Secondaries empfangen dasselbe Objekt. Der Dienst zeigt trotzdem auf das falsche Ziel. Der Digest hat nicht versagt, sondern die falsche Entscheidung zuverlässig konserviert.

RFC 8976 löst das Problem einer dauerhaft prüfbaren Zone. Zonen reisen per AXFR, IXFR, Datei, Archiv oder Policy-Feed. Eine gesicherte Übertragung schützt die Sitzung, hinterlässt aber nicht zwingend einen Nachweis am später gelesenen Objekt. ZONEMD trägt den Digest in der Zone selbst.

Der normativ relevante Record liegt am Zonen-Apex und hat Typ 63. Seine Felder sind SOA-Seriennummer, Kollationsschema, Hash-Algorithmus und Digest. Seriennummern müssen bei der Prüfung exakt übereinstimmen. Der Nachweis gehört damit zu einer konkreten Fassung und nicht nur zu einem Zonennamen.

SIMPLE verwendet das kanonische DNSSEC-Drahtformat und die Ordnung aus RFC 4034. Kommentare, Leerraum, Großschreibung und Textreihenfolge bestimmen die Identität nicht. Glue und verdeckte Daten werden einbezogen, identische Duplikate einmal gezählt. Der provisorische Apex-ZONEMD und die RRSIG darüber werden ausgeschlossen. Ein ZONEMD unterhalb des Apex hat in dieser Spezifikation keine Prüfbedeutung.

Das aktuelle IANA-Register führt SIMPLE als öffentliches Schema 1 sowie SHA-384 und SHA-512 als Algorithmen 1 und 2. SIMPLE/SHA-384 muss unterstützt werden. Während eines Übergangs dürfen mehrere eindeutige Paare existieren; ein lokal erlaubter Treffer genügt. Bleibt das alte Paar danach bestehen, bleibt auch dessen schwächerer Akzeptanzpfad bestehen.

Die Prüfung beginnt mit einer Erwartung: Sollte diese Zone DNSSEC enthalten? Lokale Trust Anchors und validierte DS-Records des Parents beantworten das. Beweist DNSSEC die Existenz von ZONEMD, fehlt der Record aber in der Kopie, ist Erfolg ausgeschlossen. Danach werden SOA und ZONEMD validiert, doppelte Paare verworfen, Serie, Schema, Algorithmus und Länge geprüft, die Zone kanonisiert und das Ergebnis verglichen.

Ohne DNSSEC kann ein Angreifer Records und Digest gemeinsam ändern. ZONEMD bleibt eine gute Prüfsumme gegen Übertragungsfehler, Abschneiden oder Kopiendrift, liefert aber keine belastbare Herkunft. Mit DNSSEC lässt sich die SOA/ZONEMD-Aussage an lokal akzeptiertes Vertrauen anbinden. RFC 4033 beschreibt dieses Modell und seine Grenzen. DNSSEC schützt RRsets, ZONEMD ergänzt die Ganzzonenperspektive.

Auch zusammen prüfen sie keine Geschäftssemantik. Ein versehentlich gelöschter MX, eine falsche Serviceadresse oder eine zu breite RPZ-Regel können legitim publiziert und korrekt signiert sein. Der Befund lautet dann: „Genau dieses Objekt wurde veröffentlicht.“ Er lautet nicht: „Dieses Objekt war beabsichtigt, vertraglich freigegeben und ungefährlich.“

Die Produktdokumentation trennt Mechanismus und Folge. Knot DNS bietet zonemd-verify für Load und Update getrennt von SHA-384/SHA-512-Erzeugung; standardmäßig geschieht nichts, und große Zonen können Zeit und CPU kosten. Unbound unterscheidet Prüfung, Ablehnung bei Abwesenheit und einen permissiven Modus, der Fehler protokolliert statt die Zone zu blockieren. PowerDNS dokumentiert einen ausdrücklichen Datei-Prüfbefehl. Protokollunterstützung ist keine universelle Fail-Closed-Entscheidung.

RFC 8976 benennt den Zielkonflikt: Korrupte Daten vor Nutzung zu stoppen erhöht Resilienz. Zugleich kann ein fehlender Record oder Implementierungsfehler sonst gute Daten unzugänglich machen. Für den Digestvergleich sehen Sabotage und Fehlkonfiguration oft gleich aus. Eine anfängliche Warnphase und spätere Durchsetzung sind daher sachgerecht.

Das Transfermodell aus RFC 5936 schützt Kontinuität: Kandidat empfangen und prüfen, erst nach Erfolg atomar laden; bei Fehler den Kandidaten löschen und die bisherige Version weiter bedienen. ZONEMD verbessert diese Kandidatenprüfung, verlangt aber nicht die Aufgabe des letzten guten Zustands.

Dieser Zustand darf dennoch nicht unbegrenzt altern. Maximalalter, Eskalation und Ausnahmeverantwortung gehören in die lokale Policy und unterscheiden sich je nach Zone. Der Digest kennt das konkrete Schadensmodell nicht.

Auch der Herkunftsnachweis ist zeitabhängig. SOA und passender ZONEMD müssen gemeinsam erscheinen; die Signaturerzeugung darf den SOA nicht erneut erhöhen. Nach einem KSK-Rollover kann eine noch gültige Signatur unverifizierbar werden, wenn notwendiger DS oder Trust Anchor nicht mehr verfügbar ist.

SIMPLE durchläuft bei jeder Änderung die ganze Zone. RFC 8976 hält das für große oder hochdynamische Zonen für unpraktisch, wenn Rechenzeit an Update- oder Propagationsintervalle heranreicht. Eine Kontrolle außerhalb des Betriebsbudgets endet als Rückstau oder Notfallumgehung.

Ein belastbarer Audit trennt Kandidat, kanonische Identität, DNSSEC-Herkunft, Semantik, lokale Zulassung, geladenen Stand und beobachtete Antworten. Heng Lus Texte zu Running-Code Primacy, minimaler Anfangsspezifikation und lokaler Folgeentscheidung sowie Realitätsebenen stützen diese Disziplin: Gemeinsame Validierung bleibt deterministisch; die Folge bleibt beim Betreiber, der sie ausführt und trägt.

Die Errata-Seite zu RFC 8976 hält eine technische Korrektur fest: Ein privates SHA-384-Beispiel im Anhang ist zu kurz dargestellt. Die normative Forderung von 48 Oktetten bleibt unverändert. Diese Einschränkung offen zu dokumentieren gehört zur Integrität der Evidenz.

„Digest passt“ ist deshalb kein Abschluss. Nötig sind Serie, Vertrauenskette, Algorithmus, Prüferfassung, Zulassungsentscheidung, vorgehaltener Altstand und der Nachweis, welcher Stand tatsächlich autoritativ antwortete. Erst diese Kette macht kryptografische Integrität zu betrieblicher Gewissheit.