Eine DNS-Zone exportieren und dokumentieren: Original und Lücken festhalten

Den Aussageumfang des Exports festlegen

Halten Sie Zone, öffentlichen oder privaten Geltungsbereich, Anbieter, Darstellungsformat und genehmigte Erfassungsmethode fest, bevor ein späterer Export organisiert wird. Welche Recordsets und Einstellungen deckt die dokumentierte Methode ab? Eine herunterladbare Datei, ein passender Hash oder erfolgreiche Parserannahme beweisen weder Vollständigkeit noch gleiche Funktionen oder eine gelungene Wiederherstellung.

Bewahren Sie das Original in genehmigtem geschütztem Speicher auf. Wird es später autorisiert erfasst, dokumentieren Sie tatsächlichen Zeitpunkt mit Zeitzone, Methode, Byteumfang und Hash. Erfinden Sie diese Angaben nicht anhand eines Beispiels. Änderungen gehören in eine getrennte Arbeitskopie. Relevante Kommentare und Herkunftshinweise bleiben erhalten; Kommentare sind nicht grundsätzlich entbehrlich.

Mit einem leeren Evidenzregister beginnen

Deckblatt: Zone/Geltungsbereich ____; Quellanbieter und datierte Dokumentation ____; autorisierte Person und Methode ____; tatsächlicher Erfassungszeitpunkt/Zeitzone ____; geschützter Originalspeicher, Bytes und Hash, sofern erfasst ____; Arbeitskopie ____; Ziel, Importmodus und aktuelle Dokumentation ____; erwartete Recordsets, einzelne Records und Ausschlüsse ____. Fehlende Evidenz ausdrücklich als unbekannt kennzeichnen.

Anhangskarte: Funktion oder Autoritätsfrage ____; Quell- und Zieldokumentation mit Datum ____; verstanden, Umwandlung erforderlich, nicht unterstützt oder unbekannt ____; erwarteter Unterschied ____; Verantwortlicher ____; getrennt autorisiertes späteres Abnahmekriterium und Evidenz ____. Eine dokumentierte Erwartung ist keine bereits abgenommene Aktion.

Quell- und Zielregeln getrennt lesen

Die Cloudflare-Seite vom 16. April 2026 dokumentiert Inline-Kommentare und exportierte reservierte cf- Tags. cf-proxied:true und cf-proxied:false bezeichnen Proxy- beziehungsweise reine DNS-Konfiguration. Beim Import hat ein Tag am einzelnen Record Vorrang vor der allgemeinen Importauswahl; fehlt es, gilt die allgemeine Auswahl. Bewahren Sie diesen Kontext, ohne dieselbe Interpretation oder eine gleichwertige Proxy-Funktion beim Zielanbieter anzunehmen.[2]

Im beschriebenen Importablauf unterstützt Cloudflare $ORIGIN, $TTL und $GENERATE, jedoch nicht $INCLUDE. Der Azure-Portalleitfaden vom 11. August 2026 unterstützt $ORIGIN und $TTL, lehnt aber $GENERATE und $INCLUDE ab. Eignung für einen dokumentierten Importer bedeutet somit keine automatische Eignung für einen anderen. Vor einer Aktion Produkt, Modus und aktuelle Grenzen prüfen.[2][1]

Azure unterscheidet zwischen Import bei Zonenerstellung und Zusammenführen mit einer bestehenden Zone. Beim dokumentierten Zusammenführen bleiben vorhandene Recordset-TTLs im Regelfall erhalten. Ein CNAME kann einen bestehenden CNAME ersetzen; bei Konflikten mit anderen Recordtypen bleibt der vorhandene Eintrag. SOA-Host und Apex-NS-Daten bleiben anbieterbestimmt; andere SOA-Parameter und die Apex-NS-TTL werden gesondert behandelt. Auch die TXT-Zeichenkettenstruktur kann abweichen. Das sind begrenzte Umwandlungsfragen, keine ausgeführte Wiederherstellung.[1]

Copper Lantern Archive: fehlende Evidenz zählen

Vier dargestellt + eins anbieterspezifisch + eins unbekannt = sechs erwartete Inventarzeilen. Vier + eins = fünf in der Quelle vorhandene Sets; sechs − fünf = ein fehlendes Set. Gezählt werden Recordsets, keine Dateizeilen oder einzelnen Records. SOA und Apex-NS sind bewusst ausgeschlossen und separat erfasst. Die Platzhalter sind keine veröffentlichbaren Adressen, SPF-Richtlinien oder Verifizierungswerte.

Offene Lücken von Autoritätserwartungen trennen

G1: R3 ist textlich vorhanden, seine Proxy-Semantik am Ziel bleibt jedoch ungeklärt. Eine CNAME-Zeile belegt keine Funktionsgleichheit. G2: R6 fehlt in der beschriebenen Quelle; die Notiz benennt Evidenzbedarf und autorisiert keinen Veröffentlichungswert. Lena muss genehmigte Abdeckungsevidenz und eine Entscheidung zur Zielfunktion beschaffen. Zwei offene Lücken bedeuten HOLD für Vollständigkeits- und exakte Gleichheitsbehauptungen.

A1: SOA-Host ist anbieterbestimmt. A2: Apex-NS-Daten sind anbieterbestimmt. Das sind zwei dokumentierte Umwandlungserwartungen am Ziel, außerhalb der sechs Anwendungs-/Mail-Sets; weder zusätzliche fehlende Zeilen noch abgeschlossene Umwandlungen. Delegationsänderungen gehören in einen getrennt autorisierten Plan. Die Datei belegt weder Mailkontinuität noch Website-Bereitschaft.[1]

Die spätere Abnahmefrage formulieren

Vor einem getrennt genehmigten Import Zielprodukt und Modus, neue oder vorhandene Zone, relevante Direktiven- und Größenlimits, Konflikte, Umwandlungen und akzeptable spätere Nachweise je Zuständigem festhalten. Datei und Hash identifizieren Bytes; Parserannahme betrifft Syntax im jeweiligen Kontext. Beides schließt weder G1/G2 noch belegt es Autorität, funktionierende Mail, Proxy-Verhalten oder Dienste.

Bezeichnen Sie das Paket nicht als vollständige Kontosicherung. Konten, Zugangsdaten, private Schlüssel und Dienstkonfiguration brauchen eigene genehmigte Wiederherstellungsregelungen. Dokumentieren Sie dargestellte oder referenzierte Einstellungen. Weder fehlen jedem Export sämtliche Funktionen, noch enthält ein einzelner Export zwangsläufig alle.

Eine begrenzte Dokumentationsentscheidung übergeben

Übergeben Sie Originalreferenz, separates Inventar, Funktions-/Autoritätsanhang, Ausschlüsse, offene Zuständigkeiten und spätere Abnahmekriterien. Jede Frage bleibt dokumentiert, bis zur Evidenz zurückgestellt oder nur mit datiertem Nachweis abgenommen. Im fiktiven Fall bleibt HOLD bestehen; daraus folgt keine Importgenehmigung. Umstellungsablauf, Mailabhängigkeiten und TTL-Zeitplanung bleiben in den verlinkten Leitfäden.