# En runbook för övergång av domän, DNS och TLS till en ny server | SwissOctet Insights https://swissoctet.com/sv/insights/dns-tls-cutover-runbook/ SwissOctet / Insikter / Webb och onion Webb och onion Tillämpad · 4 min läsning En runbook för övergång av domän, DNS och TLS till en ny server Förbered värdnamnsrouting, certifikat och återställning tillsammans så att en migrering byter server utan att bryta webbplatsens identitet eller säkra anslutningar. Av SwissOctet Redaktionellt Spara guide Kopiera länk PÅ DENNA SIDA 01 Inventera namnen och beroendena 02 Förbered värdnamnsrouting på den nya servern 03 Välj en metod för certifikatvalidering 04 Planera cachefönstret innan du ändrar DNS 05 Verifiera DNS och TLS separat 06 Gör återställning till ett databeslut också 07 Observera webbplatsen efter växlingen Din praktiska checklista Källor och vidare läsning Tillbaka till biblioteket DET DIREKTA SVARET Förbered servern och certifikatet för det avsedda värdnamnet, testa applikationen innan du ändrar offentlig DNS och håll den gamla miljön tillgänglig under övergången. Verifiera auktoritativa poster, cachade svar och TLS oberoende av varandra. Enbart en DNS-uppdatering fastställer inte att rätt applikation och certifikat serveras. 01 Inventera namnen och beroendena Lista varje värdnamn som webbplatsen använder, inklusive huvuddomänen, alias, API-slutpunkter och applikationsåteranrop. Registrera vem som kontrollerar registrering och auktoritativ DNS. Att vara värd för en applikation registrerar inte automatiskt dess domän eller ger serveroperatören kontroll över dess poster. Behåll åtkomsten till den befintliga miljön tills den nya har validerats. Identifiera även e-post- och tredjepartsverifieringsposter som flytten bör bevara. En webbplatsmigrering bör inte slentrianmässigt ersätta en hel DNS-zon. Gör en ändringsplan på postnivå med de avsedda adresserna och ett återställningsvärde. Förvara autentiseringsuppgifter privat; runbooken behöver ägare och rutiner snarare än faktiska lösenord eller API-token. 02 Förbered värdnamnsrouting på den nya servern En maskin som tar emot en anslutning måste betjäna den avsedda applikationen för sitt värdnamn. Konfigurera webbservern eller hostingpanelen i enlighet med detta, med den offentliga dokumentroten separerad från privat konfiguration och autentiseringsuppgifter. Testa alla nödvändiga namn och omdirigeringar, inte bara en generisk välkomstsida som nås via serverns adress. Använd en kontrollerad testmetod som skickar det avsedda värdnamnet till den nya slutpunkten före den offentliga ändringen. Kontrollera inloggning, uppladdningar och applikationsgenererade länkar där så är tillämpligt. Inaktivera jobb som skulle kunna dubblera produktionsåtgärder under testning. Testet bör bevisa applikationsbeteende utan att skicka riktig e-post, ta betalt eller oavsiktligt ändra den gamla livedatabasen. 03 Välj en metod för certifikatvalidering Certifikatutfärdande kräver bevis på kontroll över de begärda namnen. Let's Encrypt dokumenterar HTTP-01 och DNS-01 bland sina valideringsmetoder. HTTP-validering beror på att den nödvändiga utmaningen serveras korrekt; DNS-validering använder en angiven DNS-post och kan stödja utfärdande av wildcard-certifikat. Välj en metod som passar den faktiska driftsättningen och som kan underhållas säkert. Håll valideringsuppgifter snävt begränsade där det är möjligt. DNS-automatisering är särskilt känslig eftersom breda DNS-uppgifter kan påverka mer än en webbplats. Planera certifikatsförnyelse och hur de förnyade filerna når den serverande processen. Lyckat första utfärdande är användbart, men en webbplats behöver också en fungerande förnyelseprocess och övervakning av det certifikat den faktiskt presenterar. 04 Planera cachefönstret innan du ändrar DNS DNS-poster har en time-to-live som resolvers använder vid cachning av svar. En poständring ersätter inte omedelbart varje cachat resultat. Om en övergång gynnas av en kortare TTL, planera justeringen tillräckligt tidigt så att tidigare cachade svar kan löpa ut. Håll både gamla och nya miljöer kapabla att hantera den övergång du har utformat. Denna illustrativa sekvens separerar förberedelse från den offentliga övergången. Dess tidsplan måste anpassas till domänen, resolverbeteende och applikationen. Det är inte ett universellt spridningsschema. En migrering som involverar aktiva skrivningar behöver också en applikationsspecifik dataövergång, eftersom två fungerande webbservrar annars kan acceptera ändringar i olika datamängder. Steg Åtgärd Villkor innan fortsättning Förberedelse Inventera poster och konfigurera ny slutpunkt Applikationen fungerar för avsedda namn Certifikat Utfärda och installera certifikat Korrekt kedja och värdnamn validerar Övergång Uppdatera endast planerade DNS-poster Dataövergång och återställning är definierade Observation Kontrollera auktoritativa resultat och klientresultat Användarresor lyckas via ny slutpunkt Slutförande Avveckla gammal tjänst efter validering Kvarvarande trafik och återställningsbehov granskade 05 Verifiera DNS och TLS separat Kontrollera den auktoritativa posten först och jämför sedan svar från klienter eller resolvers som är involverade i övergången. Ett korrekt auktoritativt värde och ett äldre cachat värde kan samexistera. Inspektera slutpunkten som webbläsaren når i stället för att anta att varje anslutning redan använder den nya adressen. Håll observationer tidsstämplade så att övergången blir begriplig. För TLS, validera det avsedda värdnamnet, certifikatets giltighet och kedja genom en faktisk klientanslutning. Inspektera varje nödvändigt alias och varje omdirigeringsväg. Mozillas TLS-dokumentation förklarar serverautentisering och problem med blandat innehåll: sidan och dess underresurser bör levereras säkert. Ett certifikat på ett värdnamn täcker inte automatiskt en annan applikationsslutpunkt. 06 Gör återställning till ett databeslut också En DNS-återställning kan omdirigera trafik, men den återställer inte skrivningar som gjorts i den nya applikationen. Definiera hur du ska hantera dessa data före övergången. För en statisk publicering kan återställning vara enkel; för en tjänst som tar emot uppladdningar eller beställningar behöver applikationstillståndet en tydlig ägare och avstämningsrutin. Föreställ dig att migrera en liten publiceringswebbplats med kommentarer. Du kan förbereda ett underhållsintervall eller en kontrollerad skrivskyddad övergång medan de slutliga data kopieras. Testa återöppningsrutinen och håll den gamla driftsättningen redo. Välj det tillvägagångssätt som passar applikationen i stället för att använda en DNS-ändring som ersättning för konsekvensplanering. 07 Observera webbplatsen efter växlingen Verifiera verkliga användarresor, felfrekvenser, certifikatpresentation och bakgrundsuppgifter efter att den nya slutpunkten tar emot trafik. Bekräfta att säkerhetskopior nu täcker den avsedda applikationen och datan. Granska åtkomsten till den gamla servern före avveckling och ta bort föråldrade autentiseringsuppgifter när behoven av återställning och rollback har lösts. Registrera den slutliga DNS- och certifikatkonfigurationen. När du väljer SwissOctet webbhotell eller beräkningskapacitet, bekräfta de faktiska ansvarsområdena för domän, certifikat och administration för konfigurationen. Katalogen tillhandahåller ett hostingmål och resurser; den fastställer inte att din domän redan har anslutits eller att certifikatsförnyelse har konfigurerats. Håll dessa steg konkreta och verifierbara i driftsättningsplanen. GÖR DET TILL HANDLING Din praktiska checklista. ✓ Inventera varje värdnamn och bevara orelaterade DNS-poster. ✓ Testa värdnamnsrouting före offentlig övergång. ✓ Välj och automatisera en lämplig certifikatutmaning. ✓ Planera TTL-ändringar och dataövergången. ✓ Verifiera DNS och TLS genom separata kontroller. ✓ Behåll återställningsåtkomst och lös nya skrivningar innan du återgår. Ladda ner checklista VANLIGA FRÅGOR Detaljerna som spelar roll. Aktiverar en ändring av en A-post HTTPS? + Nej. DNS väljer en slutpunkt; den slutpunkten behöver fortfarande korrekt värdnamnsrouting och ett giltigt, installerat certifikat. Kan jag återställa endast DNS-posten om något går sönder? + Trafik kan omdirigeras, men applikationsskrivningar behöver separat hantering. Definiera en dataåterställnings- eller avstämningsplan före migreringen. Är ett wildcard-certifikat alltid nödvändigt? + Nej. Välj certifikatnamn och validering utifrån de faktiska värdnamnen. Ett wildcard har specifika täcknings- och valideringskrav; det är inte en universell genväg för migrering. PRIMÄRA REFERENSER Gå till källan. Dessa referenser stöder de tekniska begreppen i denna guide. Följ aktuell dokumentation innan du ändrar ett produktionssystem. Let's Encrypt: Utmaningstyper letsencrypt.org IETF RFC 1034: DNS begrepp och faciliteter datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Redaktionell vägledning av SwissOctet. Exemplen är illustrativa. Tjänstespecifikationer, tillgängliga alternativ och avtalsvillkor måste verifieras separat. KOPPLA KUNSKAPEN Relaterad infrastruktur. Canvas Web Schweiz Vector VPS Schweiz Pulse NVMe Schweiz HÅLL TRÅDEN Dina nästa fältanteckningar. Utforska alla guider FÄLTANTECKNING / 01 + Moln & VPS Grund Hur man väljer en VPS utan att gissa Omvandla en applikationsidé till en användbar resursbudget och jämför sedan CPU, minne, lagring och överföring tillsammans. 4 min läsning Läs guiden FÄLTANTECKNING / 02 + Webb och onion Grund Webbhosting eller en VPS: välj det arbete du vill äga Jämför applikationskrav, kontroll och underhållsansvar istället för att behandla en VPS som det automatiska nästa steget för varje webbplats. 6 min läsning Läs guiden FÄLTANTECKNING / 03 + Webb och onion Tillämpad Publicera en onion-tjänst utan att förbise applikationen Planera en legitim onion-publicering med kontrollerad backend-exponering, noggrann innehållsgranskning, återställning av tjänstnycklar och en tydlig modell för målgruppsåtkomst. 4 min läsning Läs guiden