Domeinverhuizing vanuit een technisch perspectief: Volledige instructies

Ik beschrijf de Proces domeinoverdracht technisch, stap voor stap, van het ontgrendelen tot de uiteindelijke bevestiging in het register. Dit is hoe je auth-code, EPP-processen en de DNS bijwerken schoon, zodat de website en e-mail toegankelijk blijven.

Centrale punten

• Ontgrendel en controleer de gegevens van de eigenaar
• Auth code Verzoek op tijd
• EPP-Start overdracht met nieuwe registratiehouder
• DNS bijwerken Van tevoren voorbereiden
• TLD-regels en deadlines naleven

Voorbereiding: domein ontgrendelen en gegevens controleren

Ik begin met het overdrachtsslot: ik deactiveer de Registratorslot in het klantenportaal zodat de wijziging mogelijk is. Vervolgens controleer ik de WHOIS-contactgegevens, met name de E-mail van de houder voor bevestigingen. Als de gegevens niet overeenkomen, stopt het proces vaak onnodig lang. Ik documenteer ook de huidige opstelling zodat ik later betrouwbare vergelijkingen kan maken. Tot slot maak ik checklists zodat ik geen technische stappen vergeet.

DNS-strategie voor de start

Voor productieve verhuizingen plan ik de DNS bijwerken actief om storingen te voorkomen. Ik stel een identieke DNS-zone in bij de nieuwe provider en test A, AAAA, MX en CNAME records. Als je externe nameservers gebruikt, kun je deze tijdens de wijziging behouden en zo het risico aanzienlijk verkleinen. Ik controleer de time-to-live waarden (TTL) en verlaag deze gericht zodat wijzigingen wereldwijd sneller aankomen. Deze gids helpt me om fouten in meer detail te voorkomen: Fouten vermijden tijdens de overdracht, die ik voor de start een keer doorloop.

Veilig Auth-code aanvragen (EPP)

Zonder Auth code Er wordt geen enkele overdracht uitgevoerd. Ik vraag de code van de vorige registrar op in mijn account of vraag er support voor. Veel codes blijven ongeveer 30 dagen geldig, dus ik gebruik ze onmiddellijk. Voor .de kan ik in geval van problemen een alternatieve code (AuthInfo2) aanvragen via de verantwoordelijke operator. Ik sla de code versleuteld op en deel deze nooit via onbeveiligde E-mail.

Start overdracht met nieuwe registrar

Ik start de daadwerkelijke wijziging bij de nieuwe provider, voer het domein in en typ de Auth code correct. Op de achtergrond communiceren de systemen via EPP, het op XML gebaseerde protocol voor registers. De nieuwe registrar stuurt de aanvraag, de registry controleert en informeert de oude provider. In het geval van gTLD's is er vaak een korte bezwaarperiode, waarna de registry het domein overdraagt. Als u het volledige proces in compacte vorm wilt lezen, bekijk dan deze handleiding: Registrar wijzigen: Instructies, die ik graag gebruik als snelle referentie.

Technisch proces in het register

Om je te helpen het pad te begrijpen, zal ik de technische stappen in duidelijke bewoordingen samenvatten en de Brandpunten op EPP en bevestigingen. Eerst stuurt de nieuwe registratiehouder de transferaanvraag met domein en auth-code naar het register. Vervolgens worden statuscontroles uitgevoerd: Eigendom, blokkering, deadlines en eventuele bezwaren. De oude registratiehouder kan akkoord gaan of zwijgen; geen reactie na de deadline betekent meestal goedkeuring. Na goedkeuring wijst het register het domein toe aan de nieuwe registratiehouder en worden contactpersonen, naamservers en Status.

EPP-statuscodes gericht gebruiken

Ik lees het volgende voor hangers EPP-statuscodes consistent omdat ze duidelijk aangeven waar er een probleem is en welke actie er nodig is:

• okAlles klaar, geen vergrendelingen actief. De overdracht kan beginnen.
• clientTransferProhibitedRegistratorslot actief. Ik annuleer de vergrendeling van de account.
• serverTransferProhibitedRegister of beleidsblok (bijv. procedure/UDRP). Ik zal de reden met Support bespreken.
• in afwachting van overdrachtDe overdracht is bezig. Ik wacht op de deadline of controleer de bevestigingsmails.
• aflossingsperiode / in afwachting van wissenDomein in verwijderingscyclus. Overdrachten zijn geblokkeerd; eerst herstel mogelijk, dan overdracht.
• clientUpdateVerbodenUpdates vergrendeld. Ik verwijder extra vergrendelingen (registervergrendeling) voordat ik wijzigingen aanbreng.

Ik ben me ervan bewust dat gTLD's, naast de Auth code steeds meer van de term TAC (Transfer Authorisation Code) - het principe blijft hetzelfde: een tijdelijke, gevoelige token die de overdracht legitimeert.

Sloten, 60-dagen regels en toegestane afwijzingen

Ik plan een tijdbuffer voor beleidsregels die vaak over het hoofd worden gezien. Na registratie of succesvolle overdracht stellen veel registrars een 60 dagen slot, gedurende welke verdere overdrachten gewoonlijk worden geweigerd. Een verandering van registrant kan ook een blokkeringsperiode voor gTLD's veroorzaken, tenzij er vooraf een opt-out is ingesteld. Toegestane NACK-redenen van de oude registrar zijn onder meer: actieve blokkering, gebrek aan betaling, identiteitsconflicten of juridische procedures. Als geen van deze redenen van toepassing is, mag een overdracht niet zonder reden worden uitgesteld. Ik controleer daarom vooraf: Betaald? Gedeblokkeerd? Contacten correct? Dan voorkom ik onnodige lussen.

DNS-update zonder fouten

Ik houd de site toegankelijk door de DNS-zone gecontroleerd om te wisselen voordat ik hem opstart en door de TTL lager. Tijdens wereldwijde distributie (propagatie) kunnen er korte verschillen in resolutie zijn. Ik test het doel vanaf verschillende netwerken en controleer A en MX records met tools zoals dig of nslookup. Indien nodig zet ik beide infrastructuren tijdelijk parallel op totdat alle caches zijn omgezet. Als je ook details wilt weten over tijdvensters, gebruik dan mijn opmerking hieronder over de Duur.

DNSSEC netjes migreren

Met DNSSEC Ik houd rekening met de DS-vermelding in het register. Als de naamserver en dus de sleutel verandert, heb ik twee veilige strategieën:

• Conversie met een gat: Ik verwijder de DS uit het register kort voor de omschakeling, wacht op een globale update (lage TTL helpt), schakel over naar nieuwe nameservers en stel dan de nieuwe DS in. Dit voorkomt SERVFAILs door onjuiste handtekeningen.
• Naadloos doorrollen: Ik sla de nieuwe DNSKEY parallel op (KSK rollover), laat hem ondertekenen en update dan de DS. Pas daarna verwijder ik de oude sleutel. Dit vermindert de validatierisico's met strikt validerende resolvers.

Ondersteuningsregister en provider CDS/CDNSKEY, de update van de DS kan gedeeltelijk worden geautomatiseerd. Zonder automatisering regel ik de volgorde handmatig en log ik de tijden in, zodat ik bij fouten snel een dubbele controle kan uitvoeren.

Kindnaamservers en lijmrecords

Als het domein zijn eigen naamservers gebruikt (bijv. ns1.mijndomein.tld), bestaan Hostobjecten/lijmrecords in het register. Ik plan hier afzonderlijk:

• Voor de overdracht voeg ik extra IP's van de nieuwe infrastructuur toe aan de hostobjecten (dual stack, dual provider) zodat de resolutie betrouwbaar werkt tijdens de overgangsfase.
• Na de overdracht verwijder ik de oude IP's weer zodra alle caches veilig naar het nieuwe pad wijzen.
• Ik controleer of de nieuwe registrar het beheer van de hostobjecten direct ondersteunt; zo niet, dan coördineer ik de wijziging nauwgezet met beide ondersteuners.

Dit voorkomt dat domeinen op mijn kindnaamservers onverwacht onoplosbaar worden als gevolg van de verhuizing.

TLD-specificaties en deadlines

Deadlines en goedkeuringen veranderen afhankelijk van het einde, dus ik kijk goed naar de TLD. gTLD's zoals .com of .net hanteren meestal een bezwaarperiode van enkele dagen voordat de wijziging van kracht wordt. .de verhuist bijna in real time zodra de geldige code beschikbaar is. Landextensies (ccTLD's) gedragen zich anders en volgen hun eigen regels. Het volgende overzicht categoriseert de belangrijkste punten en helpt bij de Planning.

TLD	Overdrachtsproces	Bijzondere kenmerken	Code/bevestiging	Nameservergedrag
.com / .net / .org	Aanvraag via EPP, korte bezwaarfase	Oude pagina blijft toegankelijk met juiste DNS-Voorbereiding	Auth code verplicht, eigenaar ontvangt mails	Nieuwe zone vooraf instellen of externe naamservers behouden
.de	Real-time overdracht na code-invoer	Optionele alternatieve code (AuthInfo2) mogelijk	Auth code verplicht, bevestiging vaak direct in het proces	Oude zone kan worden geannuleerd, bereid daarom zone voor met nieuwe provider
ccTLD's (diverse)	Zeer verschillend, register-afhankelijk	Deels aanvullend bewijs of deadlines	Soms code, soms andere releases	Controleer vooraf of externe naamservers blijven

Afwikkeling, voorwaarden en vervalfasen

Ik verlies de Uitbreidingslogica niet uit het zicht: Voor veel gTLD's verlengt een succesvolle transfer de looptijd met een jaar (tot de maximale limiet). Sommige ccTLD's - waaronder .de - kennen deze automatische verlenging bij verhuizing niet. Als een domein bijna verloopt, kan ik onaangename verrassingen voorkomen:

• Ik start geen transfers op het laatste moment. Als het domein in de Grace- of Aflossingsfase, Overdrachten worden vaak geblokkeerd of zijn alleen mogelijk na herstel.
• Automatische verlenging bij de oude registrar kan leiden tot tussentijdse facturen; na een succesvolle overdracht worden deze bij gTLD's vaak teruggedraaid. Ik documenteer de data duidelijk.
• Na de wijziging activeer ik het volgende bij de nieuwe registrar Automatisch vernieuwen zodat er geen gaten zijn.

Planning en TTL-tijdschema

Voor kritieke projecten zet ik een kleine Runbook-plan rechts:

• T-7 tot T-3 dagen: Zone spiegelen, bewaking instellen (HTTP, MX, DNS). TTL's van relevante records verlagen naar 300-600 seconden.
• T-2 dagen: Auth-code controleren, vergrendelingen verwijderen, contacten opnieuw valideren.
• T-1 dag: Laatste zonesynchronisatie uitvoeren, DNSSEC-plan implementeren (DS verwijderen of rollover).
• T (buiten de spits): Initieer overdracht, controleer logboeken en status in beide portalen.
• T tot T+1: Na succesvolle overname, tests herhalen, DS/records voltooien, oude infrastructuur op een ordelijke manier ontmantelen.
• T+2: Geleidelijk TTL's verhogen, documentatie afronden.

Veelvoorkomende struikelblokken vermijden

Ik vermijd verouderde WHOIS-gegevens, want verkeerd verstuurde mails zijn onnodig duur Tijd. Een actief overdrachtslot blokkeert elke start, dus ik controleer het eerst. Te hoge TTL-waarden veroorzaken lange propagatie, dus ik verlaag ze van tevoren. Verschillende zonelevels bij de oude en nieuwe provider leiden tot inconsistente resolutie. Daarom controleer ik de records zorgvuldig voor de start en documenteer ik elke Amendement.

Plan mail en hosting verhuizing apart

De overdracht heeft alleen invloed op het register, niet op bestanden of mailboxen, en dat houd ik altijd in gedachten. duidelijk. Ik migreer webinhoud via SFTP of backup restore en test het voordat ik live ga. Ik verplaats mailboxen met behulp van IMAP-synchronisatie of export/import zodat er geen berichten ontbreken. Ik zet SPF, DKIM en DMARC netjes over naar de nieuwe zone. Pas als alles op zijn plaats staat, verhoog ik de TTL weer en maak ik een back-up van de Stabiliteit.

Postbezorging en parallelle werking

Ik denk in het bijzonder aan E-mail-stromen. Tijdens de omschakeling kunnen inkomende mails soms bij de oude MX en soms bij de nieuwe MX terechtkomen, afhankelijk van de resolver. Dit is hoe ik reageer:

• Voor grote volumes plan ik een korte freeze-fase voor veranderingen in de mailboxstructuur, zodat er geen verschuivingen verloren gaan.
• Indien nodig gebruik ik Dubbele levering (tijdelijk twee MX-doelen) of een centraal relais dat beide backends bedient - goed gedoseerd en gecontroleerd.
• Na de overdracht controleer ik SPF, DKIM en DMARC opnieuw en controleer ik de evaluatie van de ontvangers met behulp van DMARC-rapporten.

Veiligheidscontroles na de wijziging

Na de succesvolle migratie activeer ik de Overdrachtsverbod opnieuw. Ik stel 2-factor authenticatie in op het account van de klant en stel de geschiedenis van de auth-code veilig. Ik controleer de WHOIS-gegevens opnieuw zodat de zichtbaarheid en gegevensbescherming correct zijn. Ik herstel fouten in DNSSEC, SPF of DKIM onmiddellijk, want e-mails lijden hier enorm onder. Tot slot documenteer ik alle stappen en bewaar ik Back-ups klaar.

Herwerken: Bewaking, automatische verlenging, audit

Ik controleer de Automatisch vernieuwen-instelling en, indien beschikbaar, stel meldingen in voordat de cache verloopt. Ik voer 24-48 uur actieve monitoring uit voor website, API-eindpunten, MX, SPF/DKIM-controles en DNSSEC om edge cases in caches op te sporen. Voor audits archiveer ik schermafbeeldingen, exportbestanden, zonestatussen en EPP-events (bijv. in afwachting van overdracht → ok) zodat latere onderzoeken duidelijk gedocumenteerd kunnen worden.

Privacy, RDAP en contactkanalen

Met actieve Privacy/Proxy Ik zorg ervoor dat bevestigingsmails mij bereiken (doorsturen werkt, ticketsysteem filtert niet weg). Sommige registrars gebruiken nu RDAP-gebaseerde contactkanalen in plaats van WHOIS. Ik houd de geregistreerde e-mails consistent en vermijd spontane contactwijzigingen kort voor de overdracht, zodat er geen validatieblokkade optreedt.

Geïnternationaliseerde domeinen (IDN)

Op IDN's Ik controleer de spelling en Punycode consistent in alle systemen. Ik controleer certificaten (SAN entries), redirects en applicaties die mogelijk alleen ASCII labels accepteren. Een overdracht verandert niets, maar de fouten sluipen erin tijdens de parallelle DNS-reorganisatie.

Stapeltransfers en organisatie

Als ik meerdere domeinen verhuis, bundel ik ze in Stapeltransfers met identieke procedures: gestandaardiseerde TTL-strategie, centrale tabel voor auth-codes en deadlines, duidelijke escalatiepaden. Ik geef prioriteit aan kritieke zones (bijv. SSO-provider, MX) en zorg voor meer monitoring. Hierdoor behoud ik het overzicht en verminder ik contextwisselingen in het team.

Problemen oplossen: Als de overdracht blijft hangen

Als het proces vastloopt, werk ik een duidelijke Lijst van. Ik controleer het slot, de geldigheid van de code, eigenaarsmails en naamserververmeldingen. Vervolgens vraag ik statuslogboeken op bij de nieuwe registrar en vraag ik de oude provider feedback te sturen naar het register. In het geval van .de vraag ik een nieuwe code aan en start ik het proces opnieuw. In geval van twijfel pauzeer ik productieve omschakelingen totdat het DNS consistent is en probleemloos loopt.

Kort samengevat

Ik houd de Proces domeinoverdracht strak: eerst de blokkering opheffen en gegevens controleren, dan auth-code opslaan, dan EPP-overdracht starten. Tegelijkertijd stel ik de DNS-zone in bij de nieuwe provider en verlaag ik de TTL. Tijdens de deadlines controleer ik statusberichten en test ik de resolutie en mail. Na de overdracht activeer ik het overdrachtsblok, stel ik beveiligingscontroles in en verhoog ik de TTL weer. Als u zich aan deze volgorde houdt, kunt u domeinen op een gecontroleerde manier verhuizen en ze veilig houden. Toegankelijkheid.