# En runbook til overgang af domæne, DNS og TLS til en ny server | SwissOctet Insights https://swissoctet.com/da/insights/dns-tls-cutover-runbook/ SwissOctet / Indsigter / Web og onion Web og onion Anvendt · 4 min læsning En runbook til overgang af domæne, DNS og TLS til en ny server Forbered værtsnavnerouting, certifikater og tilbagerulning samlet, så en migrering ændrer serveren uden at bryde webstedets identitet eller sikre forbindelser. Af SwissOctet Editorial Gem guide Kopiér link PÅ DENNE SIDE 01 Kortlæg navnene og afhængighederne 02 Forbered værtsnavnerouting på den nye server 03 Vælg en metode til certifikatvalidering 04 Planlæg cachevinduet, før du ændrer DNS 05 Verificer DNS og TLS separat 06 Gør også tilbagerulning til en databeslutning 07 Overvåg webstedet efter skiftet Din praktiske tjekliste Kilder og videre læsning Tilbage til biblioteket DET DIREKTE SVAR Forbered serveren og certifikatet til det tilsigtede værtsnavn, test applikationen før ændring af offentlig DNS, og hold det gamle miljø tilgængeligt i overgangen. Verificer autoritative poster, cachelagrede svar og TLS uafhængigt. En DNS-opdatering alene fastslår ikke, at den korrekte applikation og det korrekte certifikat leveres. 01 Kortlæg navnene og afhængighederne Oplist alle værtsnavne, som webstedet bruger, herunder hoveddomænet, aliaser, API-endpoints og applikations-callbacks. Registrer, hvem der kontrollerer registrering og autoritativ DNS. Hosting af en applikation registrerer ikke automatisk dens domæne eller giver serveroperatøren kontrol over dens poster. Behold adgangen til det eksisterende miljø, indtil det nye er blevet valideret. Identificer også e-mail- og tredjepartsverifikationsposter, som flytningen bør bevare. En webstedsmigrering bør ikke uden videre erstatte en hel DNS-zone. Lav en ændringsplan på postniveau med de tilsigtede adresser og en tilbagerulningsværdi. Opbevar legitimationsoplysninger privat; runbooken har brug for ejere og procedurer frem for faktiske adgangskoder eller API-tokens. 02 Forbered værtsnavnerouting på den nye server En maskine, der modtager en forbindelse, skal betjene den tilsigtede applikation for sit værtsnavn. Konfigurer webserveren eller hostingpanelet tilsvarende, med den offentlige dokumentrod adskilt fra privat konfiguration og legitimationsoplysninger. Test alle påkrævede navne og omdirigeringer, ikke kun en generisk velkomstside, der nås via serverens adresse. Brug en kontrolleret testmetode, der sender det tilsigtede værtsnavn til det nye endpoint før den offentlige ændring. Kontroller login, uploads og applikationsgenererede links, hvor det er relevant. Deaktiver job, der kan duplikere produktionshandlinger under test. Testen bør bevise applikationsadfærd uden at sende rigtig mail, tage betalinger eller utilsigtet ændre den gamle live-database. 03 Vælg en metode til certifikatvalidering Certifikatudstedelse kræver bevis for kontrol over de ønskede navne. Let's Encrypt dokumenterer HTTP-01 og DNS-01 blandt sine valideringsmetoder. HTTP-validering afhænger af at betjene den påkrævede udfordring korrekt; DNS-validering bruger en angivet DNS-post og kan understøtte wildcard-udstedelse. Vælg en metode, der passer til den faktiske udrulning, og som kan vedligeholdes sikkert. Hold valideringsoplysninger snævert afgrænset, hvor det er muligt. DNS-automatisering er særligt følsom, fordi brede DNS-oplysninger kan påvirke mere end ét websted. Planlæg certifikatfornyelse, og hvordan de fornyede filer når frem til den betjenende proces. Første vellykkede udstedelse er nyttig, men et websted har også brug for en fungerende fornyelsesproces og overvågning af det certifikat, det faktisk præsenterer. 04 Planlæg cachevinduet, før du ændrer DNS DNS-poster har en time-to-live, som resolvere bruger ved cachelagring af svar. En postændring erstatter ikke øjeblikkeligt alle cachelagrede resultater. Hvis en overgang drager fordel af en kortere TTL, skal justeringen planlægges tidligt nok til, at tidligere cachelagrede svar kan udløbe. Hold både det gamle og det nye miljø i stand til at håndtere den overgang, du har designet. Denne illustrative sekvens adskiller forberedelse fra den offentlige overgang. Tidsforløbet skal tilpasses domænet, resolveradfærd og applikationen. Det er ikke en universel udbredelsesplan. En migrering med live-skrivninger kræver også en applikationsspecifik dataovergang, fordi to fungerende webservere ellers kan acceptere ændringer i forskellige datasæt. Fase Handling Betingelse før fortsættelse Forberedelse Kortlæg poster, og konfigurer nyt endpoint Applikationen fungerer for de tilsigtede navne Certifikat Udsted og installer certifikat Korrekt kæde og værtsnavn validerer Overgang Opdater kun planlagte DNS-poster Dataovergang og tilbagerulning er defineret Observation Kontroller autoritative resultater og klientresultater Brugerrejser lykkes via det nye endpoint Afslutning Udfas den gamle tjeneste efter validering Resttrafik og gendannelsesbehov gennemgået 05 Verificer DNS og TLS separat Kontroller først den autoritative post, og sammenlign derefter svar fra klienter eller resolvere, der er involveret i overgangen. En korrekt autoritativ værdi og en ældre cachelagret værdi kan eksistere samtidigt. Undersøg det endpoint, browseren når, i stedet for at antage, at hver forbindelse allerede bruger den nye adresse. Hold observationer tidsstemplede, så overgangen er forståelig. For TLS skal du validere det tilsigtede værtsnavn, certifikatets gyldighed og kæden gennem en faktisk klientforbindelse. Undersøg hvert påkrævet alias og hver omdirigeringssti. Mozillas TLS-dokumentation forklarer servergodkendelse og problemer med blandet indhold: siden og dens underressourcer bør leveres sikkert. Et certifikat på ét værtsnavn dækker ikke automatisk et andet applikationsendpoint. 06 Gør også tilbagerulning til en databeslutning En DNS-tilbagerulning kan omdirigere trafik, men den vender ikke skrivninger foretaget på den nye applikation. Definer, hvordan du vil håndtere disse data før overgangen. For en statisk publikation kan tilbagerulning være ligetil; for en tjeneste, der accepterer uploads eller ordrer, har applikationstilstanden brug for en klar ejer og afstemmelsesprocedure. Forestil dig en migrering af et lille publikationswebsted med kommentarer. Du kan forberede et vedligeholdelsesinterval eller en kontrolleret skrivebeskyttet overgang, mens de endelige data kopieres. Test genåbningsproceduren, og hold den gamle udrulning klar. Vælg den tilgang, der passer til applikationen, i stedet for at bruge en DNS-ændring som erstatning for konsistensplanlægning. 07 Overvåg webstedet efter skiftet Verificer rigtige brugerrejser, fejlprocenter, certifikatpræsentation og baggrundsopgaver, efter at det nye endpoint modtager trafik. Bekræft, at backup nu dækker den tilsigtede applikation og de tilsigtede data. Gennemgå adgangen til den gamle server før udfasning, og fjern forældede legitimationsoplysninger, når gendannelses- og tilbagerulningsbehovene er afklaret. Registrer den endelige DNS- og certifikatkonfiguration. Når du vælger SwissOctet-webhosting eller -compute, skal du bekræfte de faktiske ansvarsområder for domæne, certifikat og administration i konfigurationen. Kataloget leverer en hostingdestination og ressourcer; det fastslår ikke, at dit domæne allerede er forbundet, eller at certifikatfornyelse er konfigureret. Hold disse trin konkrete og verificerbare i udrulningsplanen. GØR DET TIL HANDLING Din praktiske tjekliste. ✓ Kortlæg hvert værtsnavn, og bevar urelaterede DNS-poster. ✓ Test værtsnavnerouting før offentlig overgang. ✓ Vælg og automatiser en passende certifikatudfordring. ✓ Planlæg TTL-ændringer og dataovergangen. ✓ Verificer DNS og TLS gennem separate kontroller. ✓ Behold tilbagerulningsadgang, og afklar nye skrivninger før tilbagerulning. Download tjekliste ALMINDELIGE SPØRGSMÅL De detaljer, der betyder noget. Aktiverer ændring af en A-post HTTPS? + Nej. DNS vælger et endpoint; dette endpoint har stadig brug for korrekt værtsnavnerouting og et gyldigt, installeret certifikat. Kan jeg kun gendanne DNS-posten, hvis noget går i stykker? + Trafik kan omdirigeres, men applikationsskrivninger kræver særskilt håndtering. Definer en data-tilbagerulnings- eller afstemmelsesplan før migreringen. Er et wildcard-certifikat altid nødvendigt? + Nej. Vælg certifikatnavne og validering i overensstemmelse med de faktiske værtsnavne. Et wildcard har specifikke dæknings- og valideringskrav; det er ikke en universel genvej til migrering. PRIMÆRE REFERENCER Gå til kilden. Disse referencer understøtter de tekniske begreber i denne guide. Følg den aktuelle dokumentation, før du ændrer et produktionssystem. Let's Encrypt: Udfordringstyper letsencrypt.org IETF RFC 1034: DNS-begreber og -faciliteter datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Redaktionel vejledning af SwissOctet. Eksempler er illustrative. Servicespecifikationer, tilgængelige valgmuligheder og kontraktvilkår skal verificeres separat. FORBIND VIDENEN Relateret infrastruktur. Canvas Web Schweiz Vector VPS Schweiz Pulse NVMe Schweiz BEHOLD TRÅDEN Dine næste feltnoter. Udforsk alle guider FELTNOTE / 01 + Cloud & VPS Fundament Sådan vælger du en VPS uden at gætte Omsæt en applikationsidé til et brugbart ressourcebudget, og sammenlign derefter CPU, hukommelse, storage og overførsel samlet. 4 min læsning Læs guiden FELTNOTE / 02 + Web og onion Fundament Webhosting eller en VPS: vælg det arbejde, du vil eje Sammenlign applikationskrav, kontrol og vedligeholdelsesansvar i stedet for at behandle en VPS som det automatiske næste skridt for ethvert website. 6 min. læsning Læs guiden FELTNOTE / 03 + Web og onion Anvendt Udgiv en onion-tjeneste uden at overse applikationen Planlæg en legitim onion-udgivelse med kontrolleret backend-eksponering, omhyggelig indholdsgennemgang, gendannelse af tjenestenøgler og en eksplicit model for målgruppeadgang. 4 min læsning Læs guiden