Een eventsubdomein aan een andere DNS-provider delegeren: overdrachtschecklist
Een eventteam kan example.org bij de bestaande DNS-beheerder houden, terwijl een ticket-, registratie- of partnerdienst tickets.example.org in een aparte zone beheert. Een NS-record in de parentzone draagt de bevoegdheid over die naam en onderliggende namen over. Dat is ingrijpender dan één host naar een applicatie verwijzen. Gebruik deze checklist om reden, records, beide beheerders en bewijs vast te leggen voordat bezoekersverkeer verandert.
De redactie van Boletolibre
Gepubliceerd
Bepaal of de dienst een aparte childzone nodig heeft
Download de bewerkbare subdomein-overdrachtskaart (Markdown, Engels)
Een A-, AAAA- of CNAME-record in de parentzone is vaak genoeg wanneer een provider slechts één host naar zijn dienst wil laten wijzen. Delegatie is geschikt als een andere beheerder een hele naamruimte met meerdere recordtypen of geneste namen moet beheren. Vraag eerst de exacte DNS-eisen op. Een verificatie-TXT of CNAME is geen automatisch verzoek om NS-delegatie.[1][2]
AWS beschrijft beide mogelijkheden: records in de parentzone of een aparte autoritatieve childzone. Cloudflare beschrijft delegatie, maar de eigen childzone-opzet heeft product- en abonnementsbeperkingen. Controleer daarom de actuele configuratie en geschiktheid van het account.[1][3]
Wijs parent- en childbeheerders aan
Noteer het geregistreerde domein, de exacte childzonenaam, beide autoritatieve DNS-providers en de wijzigingsbevoegde personen. De parentbeheerder beheert het NS-record op het delegatiepunt; de childbeheerder beheert de antwoorden eronder. Het wijzigen van nameservers voor het geregistreerde domein bij de registrar is een andere handeling en niet nodig als alleen tickets.example.org wordt gedelegeerd.[1]
Inventariseer eventpagina, ticketkoop, registratie, bevestiging, e-mail, certificaatvalidatie en providerverificatie die van de childnaam afhangen. Controleer of openbare of private DNS nodig is: een private zone maakt op zichzelf geen publieke delegatie. Wijs een organisator aan voor goedkeuring van bezoekersimpact en een technicus voor de controles.[1]
Bereid childrecords voor vóór de parentwijziging
Maak de childzone volgens de actuele providerhandleiding. Kopieer de werkelijk toegekende autoritatieve nameservers; gebruik nooit voorbeeldnamen. Inventariseer alle records op en onder het delegatiepunt. Plaats benodigde web-, TXT-, MX- en andere records in de childzone en bevraag de autoritatieve childservers direct voordat de parent verandert. Bewaar antwoorden en UTC-tijd.[1]
AWS waarschuwt voor uiteenlopende antwoorden als parent en child tijdens de overgang verschillende gegevens bevatten en resolvers andere nameservers gecachet hebben. Bepaal welke oude parentrecords wanneer verdwijnen; verwijder geen werkend record voordat de childzone antwoordt. Laat bij DNSSEC beide beheerders de ondertekening en parent-DS volgens hun ondersteunde methode beoordelen. Raad geen DS-waarde.[1][3]
Publiceer de delegatie en controleer de autoriteitsketen
Na voorbereiding en goedkeuring publiceert de parentbeheerder een NS-record voor de exacte childnaam met de nameservers van de childprovider. Controleer eerst het autoritatieve parentantwoord en daarna de servicerecords bij de child. Vergelijk onafhankelijke recursieve resolvers terwijl caches veranderen. Een publieke lookup met het juiste NS-paar bewijst nog niet dat de ticketstroom werkt.[1]
Test de eventpagina, ticket- of registratielink, bevestiging en e-mail onder die naam. Controleer certificaat en providerverificatie ook in het betreffende systeem. Noteer tijd, waarnemer en resolver. Beloof geen vaste propagatietijd: TTL, caches en providerprocessen verschillen. Stop afhankelijke wijzigingen bij tegenstrijdige antwoorden en volg het goedgekeurde terugval- of escalatiebesluit.[1]
Houd een terugvalplan en onderhoudseigenaar aan
Het terugvalplan vereist iemand die de parentzone kan bewerken, de oude waarden en een besluitnemer. Terugkeer naar parentrecords moet rekening houden met childantwoorden in caches. Sluit de childzone niet zolang resolvers de NS-set nog kunnen gebruiken. Verwijder na stabilisatie verouderde duplicaten volgens het providerplan en archiveer bewijs van vóór en na.[1]
Leg vast wie de childzone onderhoudt, toekomstige TXT- of certificaatvragen behandelt, de provider betaalt, toegang controleert en de delegatie aan het einde van het contract beëindigt. Anders blijft een vergeten afhankelijkheid bestaan. Zet het subdomein met een herzieningsdatum in het domeinregister. Ook het teruggeven van autoriteit is een nieuwe DNS-wijziging met voorbereiding en bezoekerstests.[1]
Gebruik de bewerkbare overdrachtskaart
De download scheidt besluit, afhankelijkheden, eigenaars, voorbereiding, waarnemingen en overdracht. Vul per childzone één kaart in en bewaar die bij de DNS-goedkeuringen. Het is een coördinatiedocument, geen universeel commandoscript. Zet er geen wachtwoorden, API-tokens, verhuiscodes of privésleutels in.[1]
Als je eventpagina’s of links via Boletolibre.com beheert, noteer de exacte publieke hostnamen en bezoekerstaken in de afhankelijkheidslijst. Volg de DNS-instructies die voor die hosts werkelijk zijn gegeven; deze gids gaat er niet van uit dat Boletolibre je registrar of autoritatieve DNS beheert.[1]
Bronnen en verder lezen
- Routing traffic for subdomainsAmazon Route 53 · Geraadpleegd
- Subdomain delegation and available setupsCloudflare DNS documentation · Geraadpleegd
- Delegate subdomainsCloudflare DNS documentation · Geraadpleegd