# Een cutover-draaiboek voor domein, DNS en TLS voor een nieuwe server | SwissOctet Insights https://swissoctet.com/nl/insights/dns-tls-cutover-runbook/ SwissOctet / Insights / Web & onion Web & onion Toegepast · 4 min leestijd Een cutover-draaiboek voor domein, DNS en TLS voor een nieuwe server Bereid hostname-routering, certificaten en rollback samen voor, zodat een migratie de server wijzigt zonder de identiteit van de site of beveiligde verbindingen te breken. Door SwissOctet Editorial Gids opslaan Link kopiëren OP DEZE PAGINA 01 Inventariseer de namen en afhankelijkheden 02 Bereid hostname-routering op de nieuwe server voor 03 Kies een methode voor certificaatvalidatie 04 Plan het cachevenster voordat u DNS wijzigt 05 Verifieer DNS en TLS afzonderlijk 06 Maak van rollback ook een gegevensbeslissing 07 Observeer de site na de omschakeling Uw praktische checklist Bronnen & verder lezen Terug naar de bibliotheek HET DIRECTE ANTWOORD Bereid de server en het certificaat voor de beoogde hostname voor, test de applicatie voordat u openbare DNS wijzigt, en houd de oude omgeving beschikbaar tijdens de overgang. Verifieer gezaghebbende records, gecachte antwoorden en TLS afzonderlijk. Een DNS-update alleen stelt niet vast dat de juiste applicatie en het juiste certificaat worden geserveerd. 01 Inventariseer de namen en afhankelijkheden Maak een lijst van elke hostname die de site gebruikt, inclusief het hoofddomein, aliassen, API-endpoints en applicatie-callbacks. Registreer wie de registratie en gezaghebbende DNS beheert. Het hosten van een applicatie registreert niet automatisch het domein en geeft de serverbeheerder geen controle over de records. Behoud toegang tot de bestaande omgeving totdat de nieuwe is gevalideerd. Identificeer ook e-mail- en verificatierecords van derden die de verhuizing moet behouden. Een websitemigratie mag niet zomaar een hele DNS-zone vervangen. Maak een wijzigingsplan op recordniveau met de beoogde adressen en een rollbackwaarde. Bewaar inloggegevens privé; het draaiboek heeft eigenaren en procedures nodig, niet de werkelijke wachtwoorden of API-tokens. 02 Bereid hostname-routering op de nieuwe server voor Een machine die een verbinding ontvangt, moet de beoogde applicatie voor zijn hostname serveren. Configureer de webserver of het hostingpaneel dienovereenkomstig, met de openbare documentroot gescheiden van privéconfiguratie en inloggegevens. Test alle vereiste namen en redirects, niet alleen een algemene welkomstpagina die via het adres van de server wordt bereikt. Gebruik een gecontroleerde testmethode die de beoogde hostname naar het nieuwe endpoint stuurt voordat de openbare wijziging plaatsvindt. Controleer inloggen, uploads en door de applicatie gegenereerde links waar van toepassing. Schakel taken uit die tijdens het testen productieacties kunnen dupliceren. De test moet applicatiegedrag bewijzen zonder echte e-mail te versturen, betalingen te innen of de oude live database onbedoeld te wijzigen. 03 Kies een methode voor certificaatvalidatie Certificaatuitgifte vereist bewijs van controle over de aangevraagde namen. Let's Encrypt documenteert HTTP-01 en DNS-01 onder zijn validatiemethoden. HTTP-validatie is afhankelijk van het correct serveren van de vereiste challenge; DNS-validatie gebruikt een gespecificeerd DNS-record en kan wildcard-uitgifte ondersteunen. Kies een methode die past bij de werkelijke implementatie en veilig kan worden onderhouden. Beperk validatie-inloggegevens waar mogelijk tot een nauw bereik. DNS-automatisering is bijzonder gevoelig omdat brede DNS-inloggegevens meer dan één website kunnen beïnvloeden. Plan certificaatvernieuwing en hoe de vernieuwde bestanden het serverproces bereiken. Een succesvolle eerste uitgifte is nuttig, maar een site heeft ook een werkend vernieuwingsproces nodig en monitoring van het certificaat dat daadwerkelijk wordt gepresenteerd. 04 Plan het cachevenster voordat u DNS wijzigt DNS-records hebben een time-to-live die door resolvers wordt gebruikt bij het cachen van antwoorden. Een recordwijziging vervangt niet onmiddellijk elk gecacht resultaat. Als een overgang baat heeft bij een kortere TTL, plan de aanpassing dan vroeg genoeg zodat eerder gecachte antwoorden kunnen verlopen. Houd zowel de oude als de nieuwe omgeving in staat om de overgang te verwerken die u hebt ontworpen. Deze illustratieve reeks scheidt voorbereiding van de openbare cutover. De timing moet worden aangepast aan het domein, het gedrag van resolvers en de applicatie. Het is geen universeel propagatieschema. Een migratie met live schrijfacties vereist ook een applicatiespecifieke gegevenscutover, omdat twee werkende webservers anders wijzigingen in verschillende datasets kunnen accepteren. Fase Actie Voorwaarde voordat u verdergaat Voorbereiding Inventariseer records en configureer het nieuwe endpoint Applicatie werkt voor de beoogde namen Certificaat Certificaat uitgeven en installeren Correcte keten en hostname valideren Overgang Werk alleen geplande DNS-records bij Gegevenscutover en rollback zijn gedefinieerd Observatie Controleer gezaghebbende en clientresultaten Gebruikersreizen slagen via het nieuwe endpoint Voltooiing Buit de oude service uit na validatie Resterend verkeer en herstelbehoeften beoordeeld 05 Verifieer DNS en TLS afzonderlijk Controleer eerst het gezaghebbende record en vergelijk daarna antwoorden van clients of resolvers die bij de overgang betrokken zijn. Een correcte gezaghebbende waarde en een oudere gecachte waarde kunnen naast elkaar bestaan. Inspecteer het endpoint dat de browser bereikt in plaats van aan te nemen dat elke verbinding al het nieuwe adres gebruikt. Houd observaties van een tijdstempel voorzien, zodat de overgang begrijpelijk is. Valideer voor TLS de beoogde hostname, certificaatgeldigheid en keten via een daadwerkelijke clientverbinding. Inspecteer elke vereiste alias en redirectpad. De TLS-documentatie van Mozilla legt serverauthenticatie en mixed-contentproblemen uit: de pagina en de subresources moeten veilig worden geleverd. Een certificaat op één hostname dekt niet automatisch een ander applicatie-endpoint. 06 Maak van rollback ook een gegevensbeslissing Een DNS-rollback kan verkeer omleiden, maar draait schrijfacties op de nieuwe applicatie niet terug. Definieer hoe u die gegevens vóór de cutover zult behandelen. Voor een statische publicatie kan rollback eenvoudig zijn; voor een service die uploads of bestellingen accepteert, heeft de applicatiestatus een duidelijke eigenaar en reconciliatieprocedure nodig. Stel u voor dat u een kleine publicatiesite met reacties migreert. U kunt een onderhoudsinterval of een gecontroleerde alleen-lezen overgang voorbereiden terwijl de definitieve gegevens worden gekopieerd. Test de heropeningsprocedure en houd de oude implementatie gereed. Kies de aanpak die bij de applicatie past in plaats van een DNS-wijziging te gebruiken als vervanging voor consistentieplanning. 07 Observeer de site na de omschakeling Verifieer echte gebruikersreizen, foutpercentages, certificaatpresentatie en achtergrondtaken nadat het nieuwe endpoint verkeer ontvangt. Bevestig dat back-ups nu de beoogde applicatie en gegevens dekken. Beoordeel toegang tot de oude server vóór buitengebruikstelling en verwijder verouderde inloggegevens wanneer de herstel- en rollbackbehoeften zijn opgelost. Registreer de definitieve DNS- en certificaatconfiguratie. Bevestig bij het selecteren van SwissOctet webhosting of compute de werkelijke verantwoordelijkheden voor domein, certificaat en beheer voor de configuratie. De catalogus biedt een hostingbestemming en resources; deze stelt niet vast dat uw domein al is verbonden of dat certificaatvernieuwing is geconfigureerd. Houd die stappen concreet en verifieerbaar in het implementatieplan. ZET HET OM IN ACTIE Uw praktische checklist. ✓ Inventariseer elke hostname en behoud niet-gerelateerde DNS-records. ✓ Test hostname-routering vóór de openbare cutover. ✓ Kies en automatiseer een geschikte certificaat-challenge. ✓ Plan TTL-wijzigingen en de gegevensovergang. ✓ Verifieer DNS en TLS via afzonderlijke controles. ✓ Behoud rollbacktoegang en los nieuwe schrijfacties op voordat u terugkeert. Checklist downloaden VEELGESTELDE VRAGEN De details die ertoe doen. Activeert het wijzigen van een A-record HTTPS? + Nee. DNS kiest een endpoint; dat endpoint heeft nog steeds de juiste hostname-routering en een geldig, geïnstalleerd certificaat nodig. Kan ik alleen het DNS-record terugdraaien als er iets misgaat? + Verkeer kan worden omgeleid, maar applicatieschrijfacties vereisen afzonderlijke behandeling. Definieer een gegevensrollback- of reconciliatieplan vóór de migratie. Is een wildcard-certificaat altijd noodzakelijk? + Nee. Kies certificaatnamen en validatie op basis van de werkelijke hostnames. Een wildcard heeft specifieke dekkings- en validatievereisten; het is geen universele migratiesnelkoppeling. PRIMAIRE REFERENTIES Ga naar de bron. Deze referenties ondersteunen de technische concepten in deze gids. Volg de actuele documentatie voordat u een productiesysteem wijzigt. Let's Encrypt: Challenge-typen letsencrypt.org IETF RFC 1034: DNS-concepten en -faciliteiten datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Redactionele begeleiding door SwissOctet. Voorbeelden zijn illustratief. Dienstspecificaties, beschikbare opties en contractuele voorwaarden moeten afzonderlijk worden geverifieerd. VERBIND DE KENNIS Gerelateerde infrastructuur. Canvas Web Zwitserland Vector VPS Zwitserland Pulse NVMe Zwitserland HOUD DE DRAAD VAST Uw volgende veldnotities. Ontdek elke gids VELDNOTITIE / 01 + Cloud & VPS Fundament Hoe je een VPS kiest zonder te gokken Zet een applicatie-idee om in een bruikbaar resourcebudget en vergelijk daarna CPU, geheugen, opslag en overdracht samen. 4 min leestijd Lees de gids VELDNOTITIE / 02 + Web & onion Fundament Webhosting of een VPS: kies het werk dat je wilt beheren Vergelijk applicatievereisten, controle en onderhoudsverantwoordelijkheden in plaats van een VPS te behandelen als de automatische volgende stap voor elke website. 6 min leestijd Lees de gids VELDNOTITIE / 03 + Web & onion Toegepast Publiceer een onion-service zonder de applicatie over het hoofd te zien Plan een legitieme onion-publicatie met gecontroleerde backend-blootstelling, zorgvuldige inhoudsbeoordeling, herstel van servicekeys en een expliciet toegangsmodel voor het publiek. 4 min leestijd Lees de gids