# Un runbook de comutare pentru domeniu, DNS și TLS către un server nou | SwissOctet Insights https://swissoctet.com/ro/insights/dns-tls-cutover-runbook/ SwissOctet / Perspective / Web și onion Web și onion Aplicat · 4 min de citit Un runbook de comutare pentru domeniu, DNS și TLS către un server nou Pregătiți împreună rutarea numelor de gazdă, certificatele și rollback-ul, astfel încât o migrare să schimbe serverul fără a strica identitatea site-ului sau conexiunile securizate. De SwissOctet Editorial Salvați ghidul Copiați linkul PE ACEASTĂ PAGINĂ 01 Inventariați numele și dependențele 02 Pregătiți rutarea numelor de gazdă pe noul server 03 Alegeți o metodă de validare a certificatului 04 Planificați fereastra de cache înainte de a schimba DNS 05 Verificați separat DNS și TLS 06 Faceți din rollback și o decizie privind datele 07 Observați site-ul după comutare Lista dumneavoastră practică de verificare Surse și lecturi suplimentare Înapoi la bibliotecă RĂSPUNSUL DIRECT Pregătiți serverul și certificatul pentru numele de gazdă dorit, testați aplicația înainte de a schimba DNS public și mențineți mediul vechi disponibil pe durata tranziției. Verificați independent înregistrările autoritative, răspunsurile cache-uite și TLS. O singură actualizare DNS nu demonstrează că sunt servite aplicația și certificatul corecte. 01 Inventariați numele și dependențele Enumerați fiecare nume de gazdă folosit de site, inclusiv domeniul principal, aliasurile, punctele terminale API și callback-urile aplicației. Înregistrați cine controlează înregistrarea și DNS autoritativ. Găzduirea unei aplicații nu înregistrează automat domeniul acesteia și nu îi oferă operatorului serverului controlul asupra înregistrărilor sale. Păstrați accesul la mediul existent până când cel nou a fost validat. Identificați, de asemenea, înregistrările de e-mail și de verificare ale terților pe care mutarea ar trebui să le păstreze. O migrare de site web nu ar trebui să înlocuiască în mod neglijent o întreagă zonă DNS. Realizați un plan de modificare la nivel de înregistrare, cu adresele dorite și o valoare de rollback. Stocați acreditările în mod privat; runbook-ul are nevoie de responsabili și proceduri, nu de parole reale sau tokenuri API. 02 Pregătiți rutarea numelor de gazdă pe noul server O mașină care primește o conexiune trebuie să servească aplicația dorită pentru numele său de gazdă. Configurați serverul web sau panoul de găzduire în consecință, cu rădăcina publică a documentelor separată de configurația și acreditările private. Testați toate numele și redirecționările necesare, nu doar o pagină generică de bun venit accesată prin adresa serverului. Folosiți o metodă de testare controlată care trimite numele de gazdă dorit către noul punct terminal înainte de schimbarea publică. Verificați autentificarea, încărcările și linkurile generate de aplicație, acolo unde este cazul. Dezactivați lucrările care ar putea duplica acțiuni de producție în timpul testării. Testul ar trebui să demonstreze comportamentul aplicației fără a trimite e-mailuri reale, a efectua plăți sau a modifica involuntar vechea bază de date live. 03 Alegeți o metodă de validare a certificatului Emiterea certificatului necesită dovada controlului pentru numele solicitate. Let's Encrypt documentează HTTP-01 și DNS-01 printre metodele sale de validare. Validarea HTTP depinde de servirea corectă a provocării cerute; validarea DNS folosește o înregistrare DNS specificată și poate susține emiterea wildcard. Alegeți o metodă care se potrivește implementării reale și poate fi întreținută în siguranță. Mențineți acreditările de validare cu domeniu de aplicare restrâns, acolo unde este posibil. Automatizarea DNS este deosebit de sensibilă, deoarece acreditările DNS extinse pot afecta mai multe site-uri web. Planificați reînnoirea certificatului și modul în care fișierele reînnoite ajung la procesul de servire. Prima emitere reușită este utilă, dar un site are nevoie și de un proces de reînnoire funcțional și de monitorizarea certificatului pe care îl prezintă efectiv. 04 Planificați fereastra de cache înainte de a schimba DNS Înregistrările DNS au un time-to-live folosit de resolveri la cache-uirea răspunsurilor. O modificare a înregistrării nu înlocuiește instantaneu fiecare rezultat cache-uit. Dacă o tranziție beneficiază de un TTL mai scurt, planificați ajustarea suficient de devreme pentru ca răspunsurile cache-uite anterior să poată expira. Mențineți atât mediul vechi, cât și cel nou capabile să gestioneze tranziția pe care ați proiectat-o. Această secvență ilustrativă separă pregătirea de comutarea publică. Calendarul său trebuie adaptat la domeniu, comportamentul resolverilor și aplicație. Nu este un program universal de propagare. O migrare care implică scrieri live necesită și o comutare a datelor specifică aplicației, deoarece două servere web funcționale pot altfel accepta modificări în seturi de date diferite. Etapă Acțiune Condiție înainte de a continua Pregătire Inventariați înregistrările și configurați noul punct terminal Aplicația funcționează pentru numele dorite Certificat Emiteți și instalați certificatul Lanțul corect și numele de gazdă se validează Tranziție Actualizați doar înregistrările DNS planificate Comutarea datelor și rollback-ul sunt definite Observare Verificați rezultatele autoritative și ale clienților Parcursurile utilizatorilor reușesc prin noul punct terminal Finalizare Retrageți vechiul serviciu după validare Traficul rezidual și nevoile de recuperare au fost examinate 05 Verificați separat DNS și TLS Verificați mai întâi înregistrarea autoritativă, apoi comparați răspunsurile de la clienții sau resolverii implicați în tranziție. O valoare autoritativă corectă și o valoare cache-uită mai veche pot coexista. Inspectați punctul terminal accesat de browser, în loc să presupuneți că fiecare conexiune folosește deja noua adresă. Păstrați observațiile cu marcaje temporale, astfel încât tranziția să fie ușor de înțeles. Pentru TLS, validați numele de gazdă dorit, valabilitatea certificatului și lanțul printr-o conexiune reală de client. Inspectați fiecare alias și cale de redirecționare necesare. Documentația TLS a Mozilla explică autentificarea serverului și problemele legate de conținutul mixt: pagina și subresursele sale ar trebui să fie livrate în siguranță. Un certificat pentru un nume de gazdă nu acoperă automat alt punct terminal al aplicației. 06 Faceți din rollback și o decizie privind datele Un rollback DNS poate redirecționa traficul, dar nu inversează scrierile făcute pe noua aplicație. Definiți modul în care veți gestiona acele date înainte de comutare. Pentru o publicație statică, rollback-ul poate fi simplu; pentru un serviciu care acceptă încărcări sau comenzi, starea aplicației are nevoie de un responsabil clar și de o procedură de reconciliere. Imaginați-vă migrarea unui mic site de publicare cu comentarii. Puteți pregăti un interval de mentenanță sau o tranziție controlată read-only în timp ce datele finale sunt copiate. Testați procedura de redeschidere și mențineți implementarea veche pregătită. Alegeți abordarea care se potrivește aplicației, în loc să folosiți o modificare DNS ca substitut pentru planificarea consistenței. 07 Observați site-ul după comutare Verificați parcursurile reale ale utilizatorilor, ratele de eroare, prezentarea certificatului și sarcinile din fundal după ce noul punct terminal primește trafic. Confirmați că backupurile acoperă acum aplicația și datele dorite. Examinați accesul la vechiul server înainte de retragere și eliminați acreditările obsolete după ce nevoile de recuperare și rollback au fost rezolvate. Înregistrați configurația finală DNS și a certificatului. Atunci când selectați găzduire web sau resurse de calcul SwissOctet, confirmați responsabilitățile reale privind domeniul, certificatul și administrarea pentru configurația respectivă. Catalogul oferă o destinație de găzduire și resurse; nu stabilește că domeniul dvs. a fost deja conectat sau că reînnoirea certificatului a fost configurată. Mențineți acești pași concreți și verificabili în planul de implementare. TRANSFORMAȚI-O ÎN ACȚIUNE Lista dumneavoastră practică de verificare. ✓ Inventariați fiecare nume de gazdă și păstrați înregistrările DNS nelegate. ✓ Testați rutarea numelor de gazdă înainte de comutarea publică. ✓ Alegeți și automatizați o provocare de certificat adecvată. ✓ Planificați modificările TTL și tranziția datelor. ✓ Verificați DNS și TLS prin controale separate. ✓ Păstrați accesul de rollback și rezolvați scrierile noi înainte de a reveni. Descărcați lista de verificare ÎNTREBĂRI FRECVENTE Detaliile care contează. Modificarea unei înregistrări A activează HTTPS? + Nu. DNS alege un punct terminal; acel punct terminal are în continuare nevoie de rutarea corectă a numelui de gazdă și de un certificat valid, instalat. Pot reveni doar la înregistrarea DNS dacă ceva se strică? + Traficul poate fi redirecționat, dar scrierile aplicației necesită o gestionare separată. Definiți un plan de rollback sau reconciliere a datelor înainte de migrare. Este întotdeauna necesar un certificat wildcard? + Nu. Alegeți numele certificatului și validarea în funcție de numele de gazdă reale. Un wildcard are cerințe specifice de acoperire și validare; nu este o scurtătură universală de migrare. REFERINȚE PRINCIPALE Mergeți la sursă. Aceste referințe susțin conceptele tehnice din acest ghid. Urmați documentația actuală înainte de a modifica un sistem de producție. Let's Encrypt: Tipuri de provocări letsencrypt.org IETF RFC 1034: Concepte și facilități DNS datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Îndrumare editorială de SwissOctet. Exemplele sunt ilustrative. Specificațiile serviciilor, opțiunile disponibile și condițiile contractuale trebuie verificate separat. CONECTAȚI CUNOAȘTEREA Infrastructură conexă. Canvas Web Elveția Vector VPS Elveția Pulse NVMe Elveția PĂSTRAȚI FIRUL Următoarele dumneavoastră note de teren. Explorați fiecare ghid NOTĂ DE TEREN / 01 + Cloud și VPS Fundament Cum să alegeți un VPS fără a ghici Transformați o idee de aplicație într-un buget util de resurse, apoi comparați CPU, memoria, stocarea și transferul împreună. 4 min de citit Citiți ghidul NOTĂ DE TEREN / 02 + Web și onion Fundament Găzduire web sau un VPS: alegeți munca pe care doriți să o dețineți Comparați cerințele aplicației, controlul și responsabilitățile de întreținere, în loc să tratați un VPS ca pe următorul pas automat pentru fiecare site web. 6 min de citire Citiți ghidul NOTĂ DE TEREN / 03 + Web și onion Aplicat Publică un serviciu onion fără a neglija aplicația Planificați o publicare onion legitimă cu expunere controlată a backend-ului, examinare atentă a conținutului, recuperarea cheilor de serviciu și un model explicit de acces al publicului. 4 min de citit Citiți ghidul