Een DNS-zone exporteren en documenteren: bewaar het origineel en de hiaten
Een DNS-export kan bruikbare recordtekst bewaren terwijl belangrijke vragen openblijven. Koppel drie documenten: de ongewijzigde bronweergave, de verwachte recordsetinventaris en een bijlage met providerfuncties of herstelhiaten. Deze gids gebruikt documentatie die op 14 oktober 2026 is geraadpleegd; er wordt geen export, accountinspectie of import uitgevoerd.
De redactie van Boletolibre
Gepubliceerd
Bepaal wat de export weergeeft
Noteer zone, publiek of privaat bereik, provider, representatievorm en toegestane verzamelmethode voordat een latere export wordt geregeld. Welke recordsets en instellingen omvat de gedocumenteerde methode? Een downloadbaar bestand, overeenkomende hash of succesvolle parseracceptatie bewijst niet dat de dekking volledig is, functies gelijk zijn of herstel is geslaagd.
Bewaar het origineel op een goedgekeurde beschermde locatie. Leg pas na een daadwerkelijk toegestane verkrijging het echte tijdstip met tijdzone, de methode, byteomvang en hash vast. Verzin die gegevens niet op basis van een voorbeeld. Bewerk een aparte werkkopie. Behoud relevante opmerkingen en herkomst; commentaar is niet per definitie overbodig.
Begin met een leeg bewijsregister
Voorblad: zone/bereikreferentie ____; bronprovider en gedateerde documentatie ____; bevoegde verzamelaar en methode ____; werkelijk brontijdstip/tijdzone ____; beschermde originele locatie, bytes en hash indien verkregen ____; werkkopie ____; bestemming, importmodus en actuele documentatie ____; verwachte setaantallen, afzonderlijke records en uitsluitingen ____. Ontbrekend bewijs blijft expliciet onbekend.
| Veld | Invullen per verwachte naam/type-set |
|---|---|
| Identiteit en inhoud | Naam/type ____; alle waarden of goedgekeurde afgeschermde verwijzing ____; vindplaats in de bron ____. |
| Recordbetekenis | Expliciete/geërfde TTL en eenheden ____; relevante prioriteit, gewicht, poort of andere typekenmerken ____. |
| Providereigenschappen | Modus/functies/commentaar/tags ____; documentatie en datum ____; weergegeven/providerspecifiek/onbekend ____. |
| Dekking en eigenaar | In bron aanwezig of ontbrekend ____; verschil ____; volgende bewijseigenaar en beoordelingscriterium ____. |
Bijlagekaart: functie of autoriteitsvraag ____; bron- en doeldocumentatie met datum ____; begrepen, omzetting nodig, niet ondersteund of onbekend ____; verwacht verschil ____; verantwoordelijke ____; apart toegestaan later acceptatiecriterium en bewijs ____. Een gedocumenteerde verwachting is geen al geaccepteerde handeling.
Lees bron- en doelregels afzonderlijk
De Cloudflare-pagina van 16 april 2026 beschrijft inlinecommentaar en geëxporteerde gereserveerde cf- tags. cf-proxied:true en cf-proxied:false beschrijven respectievelijk configuratie met proxy en alleen DNS. Bij import gaat een tag per record vóór de algemene importkeuze; zonder tag geldt die algemene keuze. Bewaar deze context zonder aan te nemen dat een andere provider hem begrijpt of een gelijkwaardige proxy aanbiedt.[2]
In de gedocumenteerde importstroom ondersteunt Cloudflare $ORIGIN, $TTL en $GENERATE, maar geen $INCLUDE. De Azure-portalgids van 11 augustus 2026 ondersteunt $ORIGIN en $TTL en wijst $GENERATE en $INCLUDE af. Geschiktheid voor de ene gedocumenteerde importer betekent dus geen automatische geschiktheid voor de andere. Controleer vóór een handeling product, modus en actuele grenzen opnieuw.[2][1]
Azure onderscheidt import bij het maken van een zone van samenvoegen met een bestaande zone. Bij de beschreven samenvoeging blijven bestaande recordset-TTLs doorgaans behouden. Een CNAME kan een bestaande CNAME vervangen; bij conflicten met een ander type blijft het bestaande record. SOA-host en apex-NS-data blijven providerbeheer; andere SOA-parameters en de apex-NS-TTL worden apart behandeld. Ook de TXT-stringstructuur kan verschillen. Dit zijn afgebakende omzettingsvragen, geen uitgevoerde herstelactie.[1]
Copper Lantern Archive: tel het ontbrekende bewijs
| Verwachte fictieve set | Bronweergave en classificatie |
|---|---|
| R1 Apex-A | OneWebV4Old; TTL 1800 seconden; weergegeven. |
| R2 Apex-AAAA | OneWebV6Old; TTL 1800 seconden; weergegeven. |
| R3 WWW-CNAME | TargetApex; TTL Auto; commentaartag cf-proxied:true; providerspecifiek en aanwezig. |
| R4 Apex-MX | Voorkeur 10, MailTarget; TTL 3600 seconden; weergegeven. |
| R5 Apex-SPF-TXT | Tijdelijke aanduiding ExistingProviderApprovedSPF; TTL 3600 seconden; weergegeven. |
| R6 ServiceVerification-TXT | ProviderVerificationPlaceholder in een fictieve eigenaarsnotitie; ontbreekt in F-001, onbekend. |
Vier weergegeven + één providerspecifieke + één onbekende = zes verwachte inventarisrijen. Vier + één = vijf aanwezige bronsets; zes − vijf = één ontbrekende set. Dit telt recordsets, geen bestandsregels of afzonderlijke records. SOA en apex-NS zijn bewust uitgesloten en apart genoteerd. De aanduidingen zijn geen publiceerbare adressen, SPF-beleidsregels of verificatiewaarden.
Scheid open hiaten van autoriteitsverwachtingen
G1: de tekst van R3 is aanwezig, maar de proxybetekenis op de bestemming is onopgelost. Een CNAME-rij bewijst geen functieovereenkomst. G2: R6 ontbreekt in de beschreven bron; de eigenaarsnotitie wijst op een bewijsbehoefte en geeft geen waarde vrij voor publicatie. Lena moet goedgekeurd dekkingsbewijs en een beslissing over de doelfunctie verkrijgen. Twee open hiaten betekenen HOLD voor volledigheid en exacte functieovereenkomst.
A1: de SOA-host valt onder providerbeheer. A2: apex-NS-data eveneens. Dit zijn twee gedocumenteerde omzettingsverwachtingen op de bestemming, buiten de zes applicatie/mailsets; geen extra ontbrekende rijen en geen voltooide omzettingen. Delegatiewijzigingen horen in een apart toegestaan plan. Het bestand bewijst geen mailcontinuïteit of gereedheid van de website.[1]
Bepaal de latere acceptatievraag
Leg vóór een apart toegestane import doelproduct/modus, nieuwe zone of samenvoeging, relevante richtlijn- en omvangslimieten, conflicten, omzettingen en later acceptabel bewijs per verantwoordelijke vast. Bestand en hash identificeren bytes; parseracceptatie betreft syntaxis in die context. Geen van beide sluit G1/G2 of bewijst autoriteit, werkende mail, proxygedrag of diensten.
Noem dit pakket geen volledige accountback-up. Accounts, inloggegevens, privésleutels en dienstconfiguratie vereisen eigen goedgekeurde herstelafspraken. Noteer welke instellingen worden weergegeven of via een referentie vastgelegd. Neem niet aan dat iedere export alle functies mist of dat één export alles bevat.
Draag een afgebakend documentatiebesluit over
Lever de verwijzing naar het ongewijzigde origineel, aparte inventaris, functie-/autoriteitsbijlage, uitsluitingen, eigenaren van open punten en latere acceptatiecriteria. Markeer iedere kwestie als gedocumenteerd, aangehouden voor bewijs of uitsluitend geaccepteerd met gedateerd bewijs. In deze fictieve casus blijft HOLD gelden; dat is geen importtoestemming. Omschakelvolgorde, mailafhankelijkheden en de TTL-tijdbeslissing blijven in de gekoppelde gidsen.
Bronnen en verder lezen
- Azure DNS: portalimport, export en samenvoeging — bijgewerkt 11 augustus 2026Microsoft Learn · Geraadpleegd
- Cloudflare DNS: import, export, richtlijnen en configuratietags — bijgewerkt 16 april 2026Cloudflare · Geraadpleegd