Zusammenfassung

  • ZONEMD bindet die SOA-Seriennummer an einen Digest der kanonisch geordneten Gesamtzone einschließlich Glue und verdeckter Daten. Eine vollständig übertragene, scheinbar aktuelle Kopie kann deshalb vor der Aktivierung als inhaltlich abweichend erkannt werden.
  • Mit DNSSEC lässt sich die Verpflichtung des Herausgebers authentisieren; ohne DNSSEC bleibt nur Schutz vor unbeabsichtigter Veränderung. Ob die Politik richtig ist und jede Instanz die Generation tatsächlich ausliefert, benötigt eigene Nachweise.

Die Freigabe wirkte eindeutig. AXFR war abgeschlossen, die Datei geschrieben, die Syntaxprüfung grün. Die SOA enthielt exakt die Seriennummer aus dem Change-Ticket. Dennoch fehlte in der Staging-Kopie ein Glue-RR.

Die Zone blieb syntaktisch gültig. Viele Antworten wären unauffällig gewesen. Nur Delegationen, die auf die verlorene Adresse angewiesen waren, hätten versagt. Eine Überwachung, die lediglich Seriennummern vergleicht, hätte den fehlerhaften Server gerade deshalb als aktuell gemeldet.

RFC 8976 setzt an dieser Beweislücke an. Der ZONEMD-Record am Zonen-Apex trägt einen Message Digest über die ruhenden Zonendaten. Der Empfänger erzeugt dieselbe kanonische Record-Folge, berechnet den Wert und vergleicht ihn mit der veröffentlichten Verpflichtung. Fehlt ein einbezogener RR, bleibt die Seriennummer gleich, der Digest aber nicht.

Versionsordnung ist keine Inhaltsidentität

Das Serial-Feld der SOA stammt aus RFC 1035. RFC 1982 legt fest, wie Werte in einem endlichen Zahlenraum einschließlich des Überlaufs verglichen werden. Damit kann ein Secondary ohne globale Uhr entscheiden, ob eine Generation neuer erscheint.

Die Zahl wird vom Herausgeber gesetzt. Sie wird nicht aus allen RRs abgeleitet. Zwei Build-Pfade können unterschiedlichen Inhalt unter derselben Nummer erzeugen. Ein Speicherfehler kann nach der Übertragung Daten ändern, ohne die SOA anzurühren. Ein Restore kann eine aktuelle Nummer mit einer alten Teilkopie verbinden.

ZONEMD enthält deshalb selbst Serial, Scheme, Hash Algorithm und Digest. Das Serial bindet die Inhaltsverpflichtung an eine benannte Generation. Die SOA beantwortet, welche Generation der Herausgeber ausgerufen hat. ZONEMD beantwortet, welchen vollständigen kanonischen Inhalt er dieser Generation zuordnet. Wer die erste Aussage als Beleg für die zweite nutzt, verliert den neuen Kontrollwert.

Auch IXFR und AXFR bleiben davon getrennt. RFC 1995 beschreibt inkrementelle Übertragung; RFC 5936 die vollständige Zonenübertragung. Beide liefern oder rekonstruieren eine Kandidatenkopie. Sie hinterlassen nach Ablage, Replikation, Wiederherstellung, Neustart und Load keinen fortdauernden Herausgebernachweis über das Gesamtobjekt. ZONEMD macht den Inhalt nach Ende des Transportkanals erneut prüfbar.

SIMPLE normiert DNS-Semantik, nicht Dateiformatierung

ZONEMD ist RR-Typ 63. Das standardisierte Scheme 1 heißt SIMPLE und muss unterstützt werden. SHA-384, Hash Algorithm 1, ist ebenfalls verpflichtend zu unterstützen und wird ungekürzt mit 48 Oktetten veröffentlicht. SHA-512, Algorithmus 2, sollte unterstützt werden und umfasst 64 Oktette. Die aktuellen Zuweisungen führt das IANA-Register der DNS-Parameter.

SIMPLE hasht nicht den wörtlichen Text einer Master-Datei. Kommentare, Leerraum und Großschreibung können variieren, obwohl die DNS-Daten gleich sind. RRs werden in unkomprimiertes kanonisches Wire-Format überführt und gemäß RFC 4034 geordnet; RRsets am selben Owner werden zusätzlich nach numerischem RR TYPE sortiert. Der Nachweis gilt der Bedeutung der Zone, nicht dem Ausgabeformat eines Editors.

Der Einschluss ist weit. Alle Records innerhalb der Zone zählen, sofern keine ausdrückliche Ausnahme greift. Glue zählt. Occluded Data zählt. Exakt gleiche Duplikate zählen einmal. Daten außerhalb der Zone werden nicht durch ihre Nachbarschaft in einer Datei Teil der Verpflichtung. Bei einer signierten Zone fließen DNSSEC-RRs ein, ausgenommen der Apex-ZONEMD-Placeholder und die RRSIG, die das endgültige ZONEMD-RRset abdecken wird.

Damit ersetzt ZONEMD DNSSEC nicht. DNSSEC authentisiert RRsets und die für Antwortvalidierung benötigten Existenz- und Nichtexistenzbelege. Ein vollständig verteiltes Zonenartefakt enthält jedoch Delegations- und Glue-Daten, die nicht alle wie ein gewöhnliches signiertes autoritatives RRset des Child geschützt sind. ZONEMD verpflichtet das Gesamtobjekt für autoritative Server, Repositories und andere Vollzonen-Konsumenten.

Der Gesamtblick verursacht Aufwand. Ändert sich ein RR, muss SIMPLE die gesamte Zone neu durchlaufen. RFC 8976 nennt kleine oder stabile Zonen als geeigneter und warnt vor großen oder hochdynamischen Zonen. Entscheidend ist nicht das Feature im Datenblatt, sondern ob Berechnung und Verifikation mit deutlichem Abstand in das kürzeste Update- und Propagationsfenster passen.

Die Publikationsreihenfolge verhindert einen Selbstwiderspruch

Würde ZONEMD erst nach der DNSSEC-Signierung ergänzt, änderten sich die Type Bit Maps von NSEC oder NSEC3 am Apex. Der Ablauf entfernt deshalb alte Apex-ZONEMDs und deren Signaturen und fügt vor der Signierung einen Placeholder ein. So bilden die Nichtexistenzbelege das Vorhandensein des Typs bereits korrekt ab.

Nach der Signierung wird der SIMPLE-Digest über die kanonische Folge berechnet. Der Apex-Placeholder wird ausgeschlossen, ebenso die RRSIG, die erst den endgültigen ZONEMD-Satz abdecken soll. Danach ersetzt der Digest den provisorischen Wert, und die zugehörige Signatur wird erstellt oder aktualisiert.

Das Erzeugen dieser Signatur darf das SOA Serial nicht erneut erhöhen. Passende SOA und ZONEMD müssen gleichzeitig veröffentlicht werden. Sonst verschiebt der Vorgang, der die Verpflichtung authentisieren soll, genau die Generation, auf die sie verweist.

Eine belastbare Publikationsakte speichert daher mehr als eine Hex-Zeichenfolge: Source Snapshot, freigegebene Policy, Builder- und Signer-Release, Serial, Scheme, Algorithmus, Digest, DNSSEC-Schlüsselkontext und Zeitpunkt des atomaren Cutovers. Erst diese Kette grenzt einen Fehler zwischen Quelle, Build, Signierung und Verteilung ein.

Verifikation beginnt mit der erwarteten Sicherheitslage

Der Empfänger muss zuerst bestimmen, ob DNSSEC zu erwarten ist. Lokale Trust Anchors und bei Nicht-Root-Zonen gegebenenfalls eine validierte DS-Kette im Parent begründen diese Erwartung. RFC 4035 stellt den Validierungsrahmen bereit.

Wer Signaturen erwartet, validiert die Existenz des Apex-ZONEMD-RRsets sowie die Signaturen von SOA und ZONEMD. Belegt DNSSEC die Nichtexistenz, kann keine Digest-Prüfung erfolgen. Belegt DNSSEC die erwartete Existenz, fehlt der Record aber in der empfangenen Zone, ist die Prüfung nicht erfolgreich. Eine ungültige Signatur darf auch dann nicht still zu einer bloßen Prüfsumme herabgestuft werden, wenn lokale und empfangene Werte übereinstimmen.

Danach folgt die Struktur. Bei mehreren ZONEMD-RRs muss jedes Scheme/Hash-Algorithm-Paar eindeutig sein. Lokale Policy darf ein nicht akzeptiertes Paar ignorieren. Für jeden zulässigen Kandidaten müssen SOA- und ZONEMD-Serial exakt gleich, Scheme und Algorithmus unterstützt, die Digest-Länge korrekt und der berechnete Wert identisch sein.

Während einer Migration genügt ein Treffer auf einem unterstützten, lokal erlaubten Paar. Genau deshalb muss das alte Paar später entfernt werden. Mehrere veröffentlichte Digests sind nur so stark wie der schwächste noch akzeptierte Algorithmus. Ein Migrationsverfahren braucht einen Ausstieg, nicht bloß eine Ergänzung.

Das Ergebnis sollte seinen Grund tragen. Erwarteter Record fehlt, DNSSEC-Kette nicht verfügbar, Serial abweichend, Paar doppelt, Verfahren nicht unterstützt, Länge falsch und Inhalt verschieden sind unterschiedliche Fehlerdomänen. Ein einziges rotes Symbol beseitigt die Information, die für Retry, Quarantäne, Rollback oder Eskalation erforderlich ist.

Ohne DNSSEC kann ein Angreifer auch den Digest ersetzen

Bei einer unsignierten Zone erkennt ZONEMD unbeabsichtigte Trunkierung, Übertragungsfehler oder Speicherkorruption, solange der ursprüngliche Digest erhalten bleibt. Wer die Zone absichtlich verändern kann, kann aber auch einen passenden neuen Digest berechnen. RFC 8976 beschreibt diese Nutzung daher als Checksum, nicht als wirksamen Schutz vor diesem Angreifer.

DNSSEC macht Entfernung und Änderung der Verpflichtung erkennbar und authentisiert SOA und ZONEMD bis zu einem Trust Anchor. Authentisiert wird damit, dass der berechtigte Herausgeber genau diesen Inhalt verpflichtet hat. Ein berechtigter Prozess kann eine falsche Delegation kryptografisch einwandfrei signieren. Der Treffer beweist weder Eigentum noch Freigabeabsicht, Ticket-Konformität, Anwendungssicherheit oder die Aktivierung auf allen Instanzen.

TSIG schützt eine andere Grenze. RFC 8945 authentisiert DNS-Transaktionen mit Shared Secrets und ist für AXFR/IXFR-Peers wertvoll. Nach Speichern, Kopieren, Restore oder Reload bleibt der alte Transaktions-MAC nicht am Gesamtobjekt haften. ZONEMD erlaubt die erneute Objektprüfung nach Ende des Kanals.

Auch signierte Nachweise haben eine Zeitgrenze. Der Rückzug eines DS oder ein Trust-Anchor-Wechsel kann historische Validierung verhindern, obwohl eine ZONEMD-RRSIG nach ihren eigenen Zeiten noch gültig wirkt. Langfristige Belege müssen deshalb den damaligen Vertrauenskontext mitführen.

Integritätsschutz schafft eine neue Verfügbarkeitsentscheidung

Ein Server kann eine Kandidatenzone im Staging prüfen und bei Abweichung den Load verweigern. So wird eine beschädigte Kopie nicht zum autoritativen Zustand.

Der Schutz erzeugt zugleich Fragilität. Ein Publikationsfehler, eine Canonicalization-Abweichung oder ein verlorener RR sieht bei der Prüfung zunächst wie Manipulation aus. Hard Fail macht mit dem fehlerhaften Teil auch korrekte Zonendaten unerreichbar. Reagieren mehrere Provider unterschiedlich, können Nutzer je nach Netz eine andere Generation sehen.

RFC 8976 nennt deshalb die schrittweise Einführung von Warning zu Error. Auch ICANN RZERC003 behandelte ZONEMD in der Root Zone als koordinierte Änderung zwischen Maintainer, Root-Server-Betreibern, Implementierern und lokalen Kopien. Daraus folgt keine universelle Root-Policy, sondern die Pflicht, mehrere Fehlerdomänen vor dem Enforcement abzustimmen.

Eine belastbare Betriebsregel unterscheidet drei Wege. Ein verifizierter Kandidat wird aktivierungsfähig. Ein abweichender Kandidat geht in Quarantäne, während eine zuvor verifizierte Generation für eine begrenzte Zeit weiterläuft. Bei unvollständiger Beweislage – etwa einer Trust-Chain-Störung statt eines Inhaltsunterschieds – entscheidet eine benannte Autorität befristet über Fail Open oder Fail Closed.

Die alte Generation ist kein dauerhafter Schutzraum. Bekannte Integrität bleibt, Aktualität sinkt. Refresh, Expire, Änderungsrate und Auswirkung bestimmen das Staleness-Budget. Rollback muss als eigener Ablauf erprobt sein: Objekt vorhanden, erneut unabhängig verifiziert, ladbar und in autoritativen Antworten beobachtbar.

Der Freigabenachweis muss bis zur ausgelieferten Antwort reichen

Autoritativer DNS-Dienst kann über mehrere Provider und viele Anycast-Standorte verteilt sein, wie RFC 8901 beschreibt. Eine erfolgreiche Staging-Prüfung belegt keinen flächendeckenden Load. Ein erfolgreiches Reload-API belegt nicht die Antworten des Prozesses. Eine Abfrage in einem Catchment deckt andere Netze nicht ab.

Der Activation Receipt verbindet fünf Grenzen. Beim Herausgeber: Source, Serial, signierter Digest. Bei Transport oder Repository: Objektidentität, Größe, lokaler Hash, Custody Events. Beim Verifier: erwartetes DNSSEC, Trust Anchors, zugelassenes Paar, berechneter Wert und Grund. Bei der Aktivierung: alte und neue Generation, Entscheidung und Load-Ergebnis. Im Runtime: SOA, ZONEMD und ausgewählte einbezogene RRs über den geforderten Flottenumfang.

Canaries dürfen nicht nur SOA abfragen, sonst wiederholen sie die Seriennummernlücke. Sie prüfen delegationssensitive Namen, ausgewählte Glue-Adressen, signierte RRsets und negative Antworten und speichern autoritative Identität sowie Beobachtungsnetz. Eine Hyperlocal Root nach RFC 8806 benötigt einen eigenen Nachweis für lokale Kopie und Refresh-Pfad; der Zustand der öffentlichen Root-Flotte beweist den lokalen Resolver nicht.

Zum Abschluss gehört negativer Nachweis. Nach Ablehnung oder Rollback müssen der verworfene Digest und die Generation aus Staging-Freigabe, laufenden Prozessen und Stichprobenantworten verschwinden. Die richtige Generation an einigen Orten schließt einen vergessenen, falsch ausliefernden Knoten nicht aus.

Quellen