# คู่มือปฏิบัติงานสำหรับการสลับโดเมน DNS และ TLS ไปยังเซิร์ฟเวอร์ใหม่ | SwissOctet Insights

https://swissoctet.com/th/insights/dns-tls-cutover-runbook/

SwissOctet / ข้อมูลเชิงลึก / เว็บและ onion เว็บและ onion ประยุกต์ · อ่าน 4 นาที

คู่มือปฏิบัติงานสำหรับการสลับโดเมน DNS และ TLS ไปยังเซิร์ฟเวอร์ใหม่

เตรียมการกำหนดเส้นทางโฮสต์เนม ใบรับรอง และการย้อนกลับไปพร้อมกัน เพื่อให้การโยกย้ายเปลี่ยนเซิร์ฟเวอร์โดยไม่ทำลายตัวตนของเว็บไซต์หรือการเชื่อมต่อที่ปลอดภัย

โดย SwissOctet Editorial บันทึกคู่มือ คัดลอกลิงก์

ในหน้านี้ 01 จัดทำทะเบียนชื่อและความสัมพันธ์เชิงพึ่งพา 02 เตรียมการกำหนดเส้นทางโฮสต์เนมบนเซิร์ฟเวอร์ใหม่ 03 เลือกวิธีการตรวจสอบใบรับรอง 04 วางแผนช่วงเวลาแคชก่อนเปลี่ยน DNS 05 ตรวจสอบ DNS และ TLS แยกกัน 06 ทำให้การย้อนกลับเป็นการตัดสินใจด้านข้อมูลด้วย 07 สังเกตเว็บไซต์หลังการสลับ รายการตรวจสอบปฏิบัติของคุณ แหล่งอ้างอิงและอ่านเพิ่มเติม กลับไปยังคลัง คำตอบตรงประเด็น เตรียมเซิร์ฟเวอร์และใบรับรองสำหรับโฮสต์เนมที่ต้องการ ทดสอบแอปพลิเคชันก่อนเปลี่ยน DNS สาธารณะ และเก็บสภาพแวดล้อมเก่าไว้ให้พร้อมใช้ระหว่างการเปลี่ยนผ่าน ตรวจสอบเรกคอร์ด authoritative คำตอบที่แคชไว้ และ TLS แยกกัน การอัปเดต DNS เพียงอย่างเดียวไม่ได้ยืนยันว่าแอปพลิเคชันและใบรับรองที่ถูกต้องกำลังให้บริการอยู่

01 จัดทำทะเบียนชื่อและความสัมพันธ์เชิงพึ่งพา

ระบุโฮสต์เนมทุกชื่อที่เว็บไซต์ใช้ รวมถึงโดเมนหลัก ชื่อแทน ปลายทาง API และ callback ของแอปพลิเคชัน บันทึกว่าใครควบคุมการจดทะเบียนและ DNS แบบ authoritative การโฮสต์แอปพลิเคชันไม่ได้จดทะเบียนโดเมนของมันโดยอัตโนมัติ หรือให้ผู้ดูแลเซิร์ฟเวอร์ควบคุมเรกคอร์ดของมัน เก็บการเข้าถึงสภาพแวดล้อมที่มีอยู่ไว้จนกว่าสภาพแวดล้อมใหม่จะได้รับการตรวจสอบ

ระบุเรกคอร์ดอีเมลและการยืนยันจากบุคคลที่สามที่การย้ายควรเก็บรักษาไว้ด้วย การโยกย้ายเว็บไซต์ไม่ควรแทนที่โซน DNS ทั้งหมดอย่างไม่ระมัดระวัง จัดทำแผนการเปลี่ยนแปลงระดับเรกคอร์ดพร้อมที่อยู่ที่ต้องการและค่าย้อนกลับ เก็บข้อมูลรับรองเป็นความลับ คู่มือปฏิบัติงานต้องการเจ้าของและขั้นตอน ไม่ใช่รหัสผ่านจริงหรือโทเค็น API

02 เตรียมการกำหนดเส้นทางโฮสต์เนมบนเซิร์ฟเวอร์ใหม่

เครื่องที่รับการเชื่อมต่อต้องให้บริการแอปพลิเคชันที่ต้องการสำหรับโฮสต์เนมของตน กำหนดค่าเว็บเซิร์ฟเวอร์หรือแผงโฮสติ้งให้สอดคล้อง โดยแยก document root สาธารณะออกจากการกำหนดค่าและข้อมูลรับรองส่วนตัว ทดสอบชื่อและ redirect ที่จำเป็นทั้งหมด ไม่ใช่เพียงหน้า welcome ทั่วไปที่เข้าถึงผ่านที่อยู่ของเซิร์ฟเวอร์

ใช้วิธีการทดสอบแบบควบคุมที่ส่งโฮสต์เนมที่ต้องการไปยังปลายทางใหม่ก่อนการเปลี่ยนแปลงสาธารณะ ตรวจสอบการเข้าสู่ระบบ การอัปโหลด และลิงก์ที่สร้างโดยแอปพลิเคชันตามความเหมาะสม ปิดใช้งานงานที่อาจทำให้การดำเนินการในโปรดักชันซ้ำซ้อนระหว่างการทดสอบ การทดสอบควรพิสูจน์พฤติกรรมของแอปพลิเคชันโดยไม่ส่งอีเมลจริง รับชำระเงิน หรือแก้ไขฐานข้อมูลจริงเดิมโดยไม่ตั้งใจ

03 เลือกวิธีการตรวจสอบใบรับรอง

การออกใบรับรองต้องมีการพิสูจน์การควบคุมสำหรับชื่อที่ร้องขอ Let's Encrypt ระบุ HTTP-01 และ DNS-01 เป็นหนึ่งในวิธีการตรวจสอบ การตรวจสอบ HTTP ขึ้นอยู่กับการให้บริการ challenge ที่ต้องการอย่างถูกต้อง การตรวจสอบ DNS ใช้เรกคอร์ด DNS ที่ระบุและสามารถรองรับการออกใบรับรองแบบ wildcard เลือกวิธีการที่เหมาะกับการปรับใช้จริงและสามารถดูแลรักษาได้อย่างปลอดภัย

จำกัดขอบเขตข้อมูลรับรองการตรวจสอบให้แคบที่สุดเท่าที่ทำได้ การทำงานอัตโนมัติของ DNS มีความละเอียดอ่อนเป็นพิเศษเพราะข้อมูลรับรอง DNS ที่กว้างขวางอาจส่งผลกระทบมากกว่าหนึ่งเว็บไซต์ วางแผนการต่ออายุใบรับรองและวิธีที่ไฟล์ที่ต่ออายุแล้วไปถึงกระบวนการให้บริการ การออกใบรับรองครั้งแรกสำเร็จนั้นมีประโยชน์ แต่เว็บไซต์ยังต้องมีกระบวนการต่ออายุที่ทำงานได้และการตรวจสอบใบรับรองที่นำเสนอจริง

04 วางแผนช่วงเวลาแคชก่อนเปลี่ยน DNS

เรกคอร์ด DNS มี time-to-live ที่ตัวแก้ชื่อใช้เมื่อแคชคำตอบ การเปลี่ยนเรกคอร์ดไม่ได้แทนที่ผลลัพธ์ที่แคชไว้ทั้งหมดทันที หากการเปลี่ยนผ่านได้ประโยชน์จาก TTL ที่สั้นลง ให้วางแผนปรับตั้งแต่เนิ่นๆ เพื่อให้คำตอบที่แคชไว้ก่อนหน้าหมดอายุได้ เก็บทั้งสภาพแวดล้อมเก่าและใหม่ให้สามารถรองรับการเปลี่ยนผ่านที่คุณออกแบบไว้

ลำดับตัวอย่างนี้แยกการเตรียมการออกจากการสลับระบบสาธารณะ ระยะเวลาต้องปรับให้เหมาะกับโดเมน พฤติกรรมของตัวแก้ชื่อ และแอปพลิเคชัน ไม่ใช่ตารางการแพร่กระจายสากล การโยกย้ายที่เกี่ยวข้องกับการเขียนสดยังต้องมีการสลับข้อมูลเฉพาะแอปพลิเคชัน เพราะเว็บเซิร์ฟเวอร์ที่ทำงานได้สองตัวอาจรับการเปลี่ยนแปลงเข้าสู่ชุดข้อมูลที่ต่างกัน

ขั้นตอน การดำเนินการ เงื่อนไขก่อนดำเนินการต่อ

การเตรียมการ จัดทำทะเบียนเรกคอร์ดและกำหนดค่าปลายทางใหม่ แอปพลิเคชันทำงานสำหรับชื่อที่ต้องการ

ใบรับรอง ออกและติดตั้งใบรับรอง เชนและโฮสต์เนมที่ถูกต้องผ่านการตรวจสอบ

การเปลี่ยนผ่าน อัปเดตเฉพาะเรกคอร์ด DNS ที่วางแผนไว้ กำหนดการสลับข้อมูลและการย้อนกลับแล้ว

การสังเกต ตรวจสอบผลลัพธ์ authoritative และจากไคลเอนต์ เส้นทางผู้ใช้สำเร็จผ่านปลายทางใหม่

การเสร็จสิ้น ปลดระวางบริการเก่าหลังการตรวจสอบ ทบทวนปริมาณการใช้งานที่เหลือและความต้องการกู้คืน

05 ตรวจสอบ DNS และ TLS แยกกัน

ตรวจสอบเรกคอร์ด authoritative ก่อน จากนั้นเปรียบเทียบคำตอบจากไคลเอนต์หรือตัวแก้ชื่อที่เกี่ยวข้องกับการเปลี่ยนผ่าน ค่าที่ถูกต้องจาก authoritative และค่าที่แคชไว้เก่ากว่าสามารถอยู่ร่วมกันได้ ตรวจสอบปลายทางที่เบราว์เซอร์เข้าถึง แทนที่จะสันนิษฐานว่าทุกการเชื่อมต่อใช้ที่อยู่ใหม่แล้ว เก็บการสังเกตพร้อมประทับเวลาเพื่อให้การเปลี่ยนผ่านเข้าใจได้

สำหรับ TLS ให้ตรวจสอบโฮสต์เนมที่ต้องการ ความถูกต้องของใบรับรอง และเชนผ่านการเชื่อมต่อไคลเอนต์จริง ตรวจสอบชื่อแทนและเส้นทาง redirect ที่จำเป็นทั้งหมด เอกสาร TLS ของ Mozilla อธิบายการพิสูจน์ตัวตนเซิร์ฟเวอร์และข้อกังวลเรื่องเนื้อหาผสม: หน้าเว็บและทรัพยากรย่อยควรถูกส่งอย่างปลอดภัย ใบรับรองบนโฮสต์เนมหนึ่งไม่ได้ครอบคลุมปลายทางแอปพลิเคชันอื่นโดยอัตโนมัติ

06 ทำให้การย้อนกลับเป็นการตัดสินใจด้านข้อมูลด้วย

การย้อนกลับ DNS สามารถเปลี่ยนเส้นทางได้ แต่ไม่ได้ย้อนการเขียนที่เกิดขึ้นบนแอปพลิเคชันใหม่ กำหนดวิธีจัดการข้อมูลนั้นก่อนการสลับระบบ สำหรับสิ่งพิมพ์แบบคงที่ การย้อนกลับอาจตรงไปตรงมา สำหรับบริการที่รับการอัปโหลดหรือคำสั่งซื้อ สถานะของแอปพลิเคชันต้องมีเจ้าของที่ชัดเจนและขั้นตอนการกระทบยอด

ลองจินตนาการถึงการโยกย้ายเว็บไซต์สิ่งพิมพ์ขนาดเล็กที่มีความคิดเห็น คุณสามารถเตรียมช่วงเวลาบำรุงรักษาหรือการเปลี่ยนผ่านแบบอ่านอย่างเดียวที่ควบคุมไว้ระหว่างคัดลอกข้อมูลสุดท้าย ทดสอบขั้นตอนการเปิดใหม่และเตรียมการปรับใช้เก่าให้พร้อม เลือกแนวทางที่เหมาะกับแอปพลิเคชัน แทนที่จะใช้การเปลี่ยน DNS เป็นตัวแทนของการวางแผนความสอดคล้อง

07 สังเกตเว็บไซต์หลังการสลับ

ตรวจสอบเส้นทางผู้ใช้จริง อัตราข้อผิดพลาด การนำเสนอใบรับรอง และงานเบื้องหลังหลังจากปลายทางใหม่รับปริมาณการใช้งาน ยืนยันว่าการสำรองข้อมูลครอบคลุมแอปพลิเคชันและข้อมูลที่ต้องการแล้ว ทบทวนการเข้าถึงเซิร์ฟเวอร์เก่าก่อนปลดระวางและลบข้อมูลรับรองที่ล้าสมัยเมื่อความต้องการด้านการกู้คืนและการย้อนกลับได้รับการแก้ไขแล้ว บันทึกการกำหนดค่า DNS และใบรับรองขั้นสุดท้าย

เมื่อเลือกเว็บโฮสติ้งหรือคอมพิวต์ SwissOctet ให้ยืนยันความรับผิดชอบที่แท้จริงด้านโดเมน ใบรับรอง และการดูแลระบบสำหรับการกำหนดค่านั้น แค็ตตาล็อกมีปลายทางโฮสติ้งและทรัพยากร แต่ไม่ได้ยืนยันว่าโดเมนของคุณเชื่อมต่อแล้วหรือการต่ออายุใบรับรองได้รับการกำหนดค่าแล้ว ทำให้ขั้นตอนเหล่านั้นเป็นรูปธรรมและตรวจสอบได้ในแผนการปรับใช้

เปลี่ยนเป็น行動 รายการตรวจสอบปฏิบัติของคุณ

✓ จัดทำทะเบียนโฮสต์เนมทุกชื่อและเก็บรักษาเรกคอร์ด DNS ที่ไม่เกี่ยวข้อง

✓ ทดสอบการกำหนดเส้นทางโฮสต์เนมก่อนการสลับระบบสาธารณะ

✓ เลือกและทำให้การตรวจสอบใบรับรองที่เหมาะสมเป็นอัตโนมัติ

✓ วางแผนการเปลี่ยน TTL และการเปลี่ยนผ่านข้อมูล

✓ ตรวจสอบ DNS และ TLS ผ่านการตรวจสอบแยกกัน

✓ เก็บการเข้าถึงสำหรับย้อนกลับและจัดการการเขียนใหม่ก่อนย้อนกลับ

ดาวน์โหลดรายการตรวจสอบ

คำถามที่พบบ่อย รายละเอียดที่สำคัญ

การเปลี่ยน A record เปิดใช้งาน HTTPS หรือไม่ +

ไม่ DNS เลือกปลายทาง ปลายทางนั้นยังต้องมีการกำหนดเส้นทางโฮสต์เนมที่ถูกต้องและใบรับรองที่ติดตั้งและใช้งานได้

ฉันสามารถย้อนกลับเฉพาะเรกคอร์ด DNS ได้หรือไม่หากมีบางอย่างเสียหาย +

ปริมาณการใช้งานสามารถเปลี่ยนเส้นทางได้ แต่การเขียนของแอปพลิเคชันต้องจัดการแยกต่างหาก กำหนดแผนการย้อนกลับหรือกระทบยอดข้อมูลก่อนการโยกย้าย

จำเป็นต้องใช้ใบรับรองแบบ wildcard เสมอหรือไม่ +

ไม่ เลือกชื่อใบรับรองและการตรวจสอบตามโฮสต์เนมจริง wildcard มีความครอบคลุมและข้อกำหนดการตรวจสอบเฉพาะ ไม่ใช่ทางลัดสากลสำหรับการโยกย้าย

แหล่งอ้างอิงหลัก ไปที่ต้นทาง

แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน

Let's Encrypt: ประเภทของ Challenge letsencrypt.org

IETF RFC 1034: แนวคิดและความสามารถของ DNS datatracker.ietf.org

Mozilla MDN: Transport Layer Security developer.mozilla.org

คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก

เชื่อมโยงความรู้ โครงสร้างพื้นฐานที่เกี่ยวข้อง

Canvas Web สวิตเซอร์แลนด์ Vector VPS สวิตเซอร์แลนด์ Pulse NVMe สวิตเซอร์แลนด์

รักษาสายไว้ บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ

บันทึกภาคสนาม / 01

+

คลาวด์และ VPS พื้นฐาน

วิธีเลือก VPS โดยไม่เดา

เปลี่ยนไอเดียแอปพลิเคชันเป็นงบประมาณทรัพยากรที่มีประโยชน์ แล้วเปรียบเทียบ CPU, หน่วยความจำ, พื้นที่จัดเก็บ และการรับส่งข้อมูลร่วมกัน

อ่าน 4 นาที อ่านคู่มือ

บันทึกภาคสนาม / 02

+

เว็บและ onion พื้นฐาน

เว็บโฮสติ้งหรือ VPS: เลือกงานที่คุณต้องการรับผิดชอบ

เปรียบเทียบข้อกำหนดของแอปพลิเคชัน การควบคุม และความรับผิดชอบด้านการบำรุงรักษา แทนที่จะถือว่า VPS เป็นขั้นตอนถัดไปอัตโนมัติสำหรับทุกเว็บไซต์

อ่าน 6 นาที อ่านคู่มือ

บันทึกภาคสนาม / 03

+

เว็บและ onion ประยุกต์

เผยแพร่บริการ onion โดยไม่มองข้ามแอปพลิเคชัน

วางแผนการเผยแพร่ onion ที่ชอบด้วยกฎหมายด้วยการเปิดเผยแบ็กเอนด์แบบควบคุม การตรวจสอบเนื้อหาอย่างรอบคอบ การกู้คืนคีย์บริการ และโมเดลการเข้าถึงสำหรับผู้ชมที่ชัดเจน

อ่าน 4 นาที อ่านคู่มือ