# Isang runbook sa cutover ng domain, DNS at TLS para sa bagong server | SwissOctet Insights https://swissoctet.com/fil/insights/dns-tls-cutover-runbook/ SwissOctet / Mga Insight / Web at onion Web at onion Praktikal · 4 minutong pagbasa Isang runbook sa cutover ng domain, DNS at TLS para sa bagong server Ihanda nang sabay ang hostname routing, certificate at rollback upang ang migration ay magbago ng server nang hindi sinisira ang pagkakakilanlan ng site o ang mga secure na koneksyon. Ni SwissOctet Editorial I-save ang gabay Kopyahin ang link SA PAHINANG ITO 01 I-inventory ang mga pangalan at dependency 02 Ihanda ang hostname routing sa bagong server 03 Pumili ng paraan ng certificate validation 04 Planuhin ang cache window bago baguhin ang DNS 05 I-verify nang hiwalay ang DNS at TLS 06 Gawing desisyon din sa data ang rollback 07 Obserbahan ang site pagkatapos ng switch Ang iyong praktikal na checklist Mga pinagmulan at karagdagang babasahin Bumalik sa library ANG DIREKTANG SAGOT Ihanda ang server at certificate para sa nilalayong hostname, subukan ang application bago baguhin ang pampublikong DNS, at panatilihing magagamit ang lumang kapaligiran sa panahon ng transition. I-verify nang hiwalay ang mga awtoritatibong record, naka-cache na sagot at TLS. Ang pag-update ng DNS lamang ay hindi nagpapatunay na ang tamang application at certificate ay hinahatid. 01 I-inventory ang mga pangalan at dependency Ilista ang bawat hostname na ginagamit ng site, kabilang ang pangunahing domain, alias, API endpoint at application callback. Itala kung sino ang kumokontrol sa registration at awtoritatibong DNS. Ang pagho-host ng application ay hindi awtomatikong nagrerehistro ng domain nito o nagbibigay sa operator ng server ng kontrol sa mga record nito. Panatilihin ang access sa kasalukuyang kapaligiran hanggang sa ma-validate ang bago. Tukuyin din ang email at third-party verification record na dapat panatilihin ng paglipat. Ang migration ng website ay hindi dapat basta-basta palitan ang buong DNS zone. Gumawa ng plano sa pagbabago sa antas ng record kasama ang nilalayong address at halaga ng rollback. Itago nang pribado ang mga credential; kailangan ng runbook ang mga may-ari at pamamaraan sa halip na aktwal na password o API token. 02 Ihanda ang hostname routing sa bagong server Ang makinang tumatanggap ng koneksyon ay dapat maghatid ng nilalayong application para sa hostname nito. I-configure nang naaayon ang web server o hosting panel, na hiwalay ang pampublikong document root mula sa pribadong configuration at credential. Subukan ang lahat ng kinakailangang pangalan at redirect, hindi lamang ang generic na welcome page na naabot sa pamamagitan ng address ng server. Gumamit ng kontroladong paraan ng pagsubok na nagpapadala ng nilalayong hostname sa bagong endpoint bago ang pampublikong pagbabago. Suriin ang login, upload at mga link na nilikha ng application kung naaangkop. I-disable ang mga trabahong maaaring magduplicate ng production action sa panahon ng pagsubok. Dapat patunayan ng pagsubok ang pag-uugali ng application nang hindi nagpapadala ng tunay na mail, tumatanggap ng bayad o hindi sinasadyang binabago ang lumang live na database. 03 Pumili ng paraan ng certificate validation Ang pagbibigay ng certificate ay nangangailangan ng patunay ng kontrol para sa hinihiling na mga pangalan. Dokumentado ng Let's Encrypt ang HTTP-01 at DNS-01 sa mga paraan ng validation nito. Ang HTTP validation ay nakasalalay sa tamang paghahatid ng kinakailangang challenge; ang DNS validation ay gumagamit ng tinukoy na DNS record at maaaring sumuporta sa wildcard issuance. Pumili ng paraang umaangkop sa aktwal na deployment at maaaring mapanatili nang ligtas. Panatilihing makitid ang saklaw ng validation credential kung posible. Ang DNS automation ay partikular na sensitibo dahil ang malawak na DNS credential ay maaaring makaapekto sa higit sa isang website. Planuhin ang pag-renew ng certificate at kung paano naaabot ng mga na-renew na file ang prosesong naghahatid. Ang matagumpay na unang issuance ay kapaki-pakinabang, ngunit kailangan din ng site ang gumaganang proseso ng pag-renew at pagsubaybay sa certificate na aktwal nitong inihahatid. 04 Planuhin ang cache window bago baguhin ang DNS Ang mga DNS record ay may time-to-live na ginagamit ng mga resolver kapag nag-cache ng mga sagot. Ang pagbabago ng record ay hindi agad pinapalitan ang bawat naka-cache na resulta. Kung ang isang transition ay makikinabang sa mas maikling TTL, planuhin ang pagsasaayos nang maaga upang mag-expire ang mga dating naka-cache na sagot. Panatilihing kayang hawakan ng luma at bagong kapaligiran ang transition na dinisenyo mo. Ang halimbawang pagkakasunod-sunod na ito ay naghihiwalay sa paghahanda mula sa pampublikong cutover. Ang timing nito ay dapat iangkop sa domain, pag-uugali ng resolver at application. Hindi ito universal na iskedyul ng propagation. Ang migration na may kasamang live na writes ay nangangailangan din ng application-specific na data cutover, dahil kung hindi, ang dalawang gumaganang web server ay maaaring tumanggap ng mga pagbabago sa magkaibang dataset. Yugto Aksyon Kundisyon bago magpatuloy Paghahanda I-inventory ang mga record at i-configure ang bagong endpoint Gumagana ang application para sa nilalayong mga pangalan Sertipiko I-issue at i-install ang certificate Nagva-validate ang tamang chain at hostname Paglipat I-update lamang ang mga planong DNS record Tinukoy ang data cutover at rollback Obserbasyon Suriin ang awtoritatibo at resulta ng client Nagtagumpay ang mga user journey sa bagong endpoint Pagkumpleto Iretiro ang lumang serbisyo pagkatapos ng validation Nasuri ang natitirang trapiko at pangangailangan sa pagbawi 05 I-verify nang hiwalay ang DNS at TLS Suriin muna ang awtoritatibong record, pagkatapos ay ihambing ang mga sagot mula sa mga client o resolver na kasangkot sa transition. Ang tamang awtoritatibong halaga at mas lumang naka-cache na halaga ay maaaring magkasabay. Suriin ang endpoint na naabot ng browser sa halip na ipagpalagay na ginagamit na ng bawat koneksyon ang bagong address. Panatilihing may timestamp ang mga obserbasyon upang maunawaan ang transition. Para sa TLS, i-validate ang nilalayong hostname, validity ng certificate at chain sa pamamagitan ng aktwal na koneksyon ng client. Suriin ang bawat kinakailangang alias at redirect path. Ipinaliwanag ng dokumentasyon ng TLS ng Mozilla ang server authentication at mga alalahanin sa mixed-content: ang page at ang mga subresource nito ay dapat ihatid nang secure. Ang certificate sa isang hostname ay hindi awtomatikong sumasaklaw sa ibang application endpoint. 06 Gawing desisyon din sa data ang rollback Ang DNS rollback ay maaaring mag-redirect ng trapiko, ngunit hindi nito binabaligtad ang mga writes na ginawa sa bagong application. Tukuyin kung paano mo hahawakan ang data na iyon bago ang cutover. Para sa static na publikasyon, ang rollback ay maaaring simple; para sa serbisyong tumatanggap ng upload o order, ang estado ng application ay nangangailangan ng malinaw na may-ari at pamamaraan ng reconciliation. Isipin ang pag-migrate ng maliit na publishing site na may mga komento. Maaari kang maghanda ng maintenance interval o kontroladong read-only na transition habang kinokopya ang huling data. Subukan ang pamamaraan ng muling pagbubukas at panatilihing handa ang lumang deployment. Piliin ang paraang umaangkop sa application sa halip na gamitin ang pagbabago ng DNS bilang kapalit ng pagpaplano ng consistency. 07 Obserbahan ang site pagkatapos ng switch I-verify ang tunay na user journey, rate ng error, presentasyon ng certificate at background task pagkatapos makatanggap ng trapiko ang bagong endpoint. Kumpirmahin na sinasaklaw na ng mga backup ang nilalayong application at data. Suriin ang access sa lumang server bago ang retirement at alisin ang mga lipas na credential kapag naresolba na ang pangangailangan sa pagbawi at rollback. Itala ang huling DNS at configuration ng certificate. Kapag pumipili ng SwissOctet web hosting o compute, kumpirmahin ang aktwal na responsibilidad sa domain, certificate at administration para sa configuration. Nagbibigay ang catalogue ng hosting destination at resources; hindi nito pinapatunayan na nakakonekta na ang iyong domain o na-configure na ang pag-renew ng certificate. Panatilihing konkreto at maipapatunayan ang mga hakbang na iyon sa deployment plan. GAWIN ITONG AKSYON Ang iyong praktikal na checklist. ✓ I-inventory ang bawat hostname at panatilihin ang mga walang kaugnayang DNS record. ✓ Subukan ang hostname routing bago ang pampublikong cutover. ✓ Pumili at i-automate ang angkop na certificate challenge. ✓ Planuhin ang mga pagbabago sa TTL at ang transition ng data. ✓ I-verify ang DNS at TLS sa pamamagitan ng magkahiwalay na check. ✓ Panatilihin ang rollback access at resolbahin ang mga bagong write bago bumalik. I-download ang checklist MGA KARANIWANG TANONG Ang mga detalyeng mahalaga. Ina-activate ba ng pagbabago ng A record ang HTTPS? + Hindi. Pinipili ng DNS ang isang endpoint; kailangan pa rin ng endpoint na iyon ang tamang hostname routing at valid at naka-install na certificate. Maaari ko bang ibalik lamang ang DNS record kung may masira? + Maaaring i-redirect ang trapiko, ngunit ang mga write ng application ay nangangailangan ng hiwalay na paghawak. Tukuyin ang plano sa data rollback o reconciliation bago ang migration. Palaging kailangan ba ang wildcard certificate? + Hindi. Piliin ang mga pangalan ng certificate at validation ayon sa aktwal na hostname. Ang wildcard ay may partikular na coverage at mga kinakailangan sa validation; hindi ito universal na shortcut sa migration. MGA PANGUNAHING SANGGUNIAN Pumunta sa pinagmulan. Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system. Let's Encrypt: Mga uri ng challenge letsencrypt.org IETF RFC 1034: Mga konsepto at pasilidad ng DNS datatracker.ietf.org Mozilla MDN: Transport Layer Security developer.mozilla.org Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay. IKONEKTA ANG KAALAMAN Kaugnay na infrastructure. Canvas Web Switzerland Vector VPS Switzerland Pulse NVMe Switzerland PANATILIHIN ANG SINULID Ang iyong susunod na field notes. Tuklasin ang bawat gabay TALA SA PRAKTIKA / 01 + Cloud at VPS Pundasyon Paano pumili ng VPS nang hindi nanghuhula Gawing kapaki-pakinabang na resource budget ang isang ideya ng application, pagkatapos ay ihambing ang CPU, memory, storage at transfer nang magkasama. 4 minutong pagbasa Basahin ang gabay TALA SA PRAKTIKA / 02 + Web at onion Pundasyon Web hosting o isang VPS: piliin ang trabahong gusto mong pagmamay-arian Ihambing ang mga kinakailangan ng aplikasyon, kontrol at mga responsibilidad sa pagpapanatili sa halip na ituring ang isang VPS bilang awtomatikong susunod na hakbang para sa bawat website. 6 min na pagbabasa Basahin ang gabay TALA SA PRAKTIKA / 03 + Web at onion Praktikal Paglathala ng onion service nang hindi nakakalimutan ang application Planuhin ang lehitimong onion publication na may kontroladong backend exposure, maingat na pagsusuri ng content, pagbawi ng service-key at tahasang modelo ng audience-access. 4 minutong pagbasa Basahin ang gabay