Naar hoofdinhoud

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

Drie documentpanelen verbinden een fictieve bron met vijf sets aan zes verwachte rijen, met een onopgeloste proxyfunctie, ontbrekende verificatie en aparte autoriteitsnotities.
Origineel fictief schema: F-001 is beschreven, geen werkelijk exportbestand. R1, R2, R4 en R5 zijn weergegeven; de gele R3 is aanwezig met providerspecifieke proxybetekenis. De omlijnde R6 ontbreekt in de beschreven bron en is onbekend. Vier weergegeven + één providerspecifieke + één onbekende = zes verwachte sets; vijf zijn aanwezig. G1 en G2 blijven open: volledigheid en exacte functieovereenkomst staan op HOLD. A1 SOA-host en A2 apex-NS-data zijn aparte verwachtingen onder beheer van de provider, buiten deze telling. Lees kleine Engelse labels met deze lokale legenda; dit is geen herstelresultaat.

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.

VeldInvullen per verwachte naam/type-set
Identiteit en inhoudNaam/type ____; alle waarden of goedgekeurde afgeschermde verwijzing ____; vindplaats in de bron ____.
RecordbetekenisExpliciete/geërfde TTL en eenheden ____; relevante prioriteit, gewicht, poort of andere typekenmerken ____.
ProvidereigenschappenModus/functies/commentaar/tags ____; documentatie en datum ____; weergegeven/providerspecifiek/onbekend ____.
Dekking en eigenaarIn 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 setBronweergave en classificatie
R1 Apex-AOneWebV4Old; TTL 1800 seconden; weergegeven.
R2 Apex-AAAAOneWebV6Old; TTL 1800 seconden; weergegeven.
R3 WWW-CNAMETargetApex; TTL Auto; commentaartag cf-proxied:true; providerspecifiek en aanwezig.
R4 Apex-MXVoorkeur 10, MailTarget; TTL 3600 seconden; weergegeven.
R5 Apex-SPF-TXTTijdelijke aanduiding ExistingProviderApprovedSPF; TTL 3600 seconden; weergegeven.
R6 ServiceVerification-TXTProviderVerificationPlaceholder 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

  1. Azure DNS: portalimport, export en samenvoeging — bijgewerkt 11 augustus 2026Microsoft Learn · Geraadpleegd
  2. Cloudflare DNS: import, export, richtlijnen en configuratietags — bijgewerkt 16 april 2026Cloudflare · Geraadpleegd