การย้ายเนมเซิร์ฟเวอร์อาจดูเหมือนสำเร็จในแผงควบคุมทุกแห่ง แต่เว็บไซต์กลับยังเข้าไม่ได้ โดเมนยังใช้งานได้ เนมเซิร์ฟเวอร์แบบ authoritative ชุดใหม่ตอบกลับด้วยที่อยู่ที่ถูกต้อง และเว็บเซิร์ฟเวอร์ก็ไม่ได้เปลี่ยนแปลงอะไร แต่ตัวแก้ไขชื่อ DNS ที่ตรวจสอบ DNSSEC กลับตอบ SERVFAIL สาเหตุที่มักถูกมองข้ามคือข้อมูลการมอบหมายความเชื่อถือของ DNSSEC ยังอ้างอิงคีย์ที่ใช้ลงลายเซ็นของผู้ให้บริการ DNS รายเดิม
ในเหตุการณ์ที่นำมาวิเคราะห์นี้ การค้นหา DNS ตามปกติล้มเหลว แต่คำขอเดียวกันกลับสำเร็จเมื่อข้ามการตรวจสอบ DNSSEC โซนแม่ยังประกาศระเบียน DS เก่า ขณะที่โซน authoritative ใหม่ยังไม่ได้ลงลายเซ็นในช่วงแรก หลังจากเผยแพร่คีย์ที่ตรงกันและลงลายเซ็นให้โซนใหม่ ตัวแก้ไขชื่อที่นำมาทดสอบก็กลับมาตอบข้อมูลที่ผ่านการตรวจสอบได้ ประเด็นสำคัญไม่ใช่ว่าควรปิด DNSSEC แต่คือการเปลี่ยนเนมเซิร์ฟเวอร์กับการย้ายสายโซ่ความเชื่อถือของ DNSSEC เป็นการดำเนินการคนละส่วนกัน
เหตุใด A record ที่ถูกต้องจึงยังทำให้เกิด SERVFAIL ได้
DNS ตอบคำถามสองอย่างที่ต่างกัน ระเบียน A บอกว่าชื่อโดเมนชี้ไปยังที่อยู่ IPv4 ใด ส่วน DNSSEC ช่วยให้ตัวแก้ไขชื่อที่มีการตรวจสอบสามารถตัดสินได้ว่าคำตอบนั้นเชื่อถือได้หรือไม่ ที่อยู่ที่ถูกต้องไม่ได้หมายความว่าสายโซ่ความเชื่อถือของ DNSSEC จะถูกต้องตามไปด้วยโดยอัตโนมัติ
สำหรับโดเมนที่มีการลงลายเซ็น สายโซ่ความเชื่อถือจะเริ่มจากโซนแม่ที่เชื่อถือได้ ผ่านระเบียน DS (Delegation Signer) ไปยัง DNSKEY ในโซนลูก โซนลูกเผยแพร่ลายเซ็นของข้อมูล DNS ในรูปของระเบียน RRSIG ระเบียน DS มีข้อมูลแฮชสรุปที่ใช้ระบุ DNSKEY ซึ่งได้รับอนุญาต ไม่ใช่ระเบียน A ไม่ใช่สำเนาของคีย์ส่วนตัว และไม่ใช่เพียงตัวเลือกหนึ่งในเครื่องมือแก้ไขไฟล์โซนทั่วไป
หลังเปลี่ยนเนมเซิร์ฟเวอร์แบบ authoritative โซนแม่อาจยังเผยแพร่ระเบียน DS ที่ผูกกับคีย์ลงลายเซ็นเดิมอยู่ หากโซนใหม่ไม่มี DNSKEY และลายเซ็นที่สอดคล้องกัน ตัวแก้ไขชื่อที่ตรวจสอบ DNSSEC จะไม่สามารถสร้างสายโซ่ความเชื่อถือให้ครบได้ โดยปกติจะถือว่าคำตอบนั้นไม่ผ่านการตรวจสอบ (bogus) และส่ง SERVFAIL กลับมา แทนที่จะส่งที่อยู่ที่ยังไม่ได้รับการยืนยัน
ปัญหานี้ต่างจากเว็บล่มเพราะ HTTP เพราะคำขออาจไปไม่ถึงเว็บเซิร์ฟเวอร์เลย และยังต่างจากใบรับรอง TLS หมดอายุด้วย เพราะ DNSSEC ตรวจสอบข้อมูล DNS ส่วน HTTPS ปกป้องการเชื่อมต่อระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ที่เกิดขึ้นในขั้นตอนถัดไป
วิธีทดสอบเพื่อแยกปัญหา DNSSEC ออกจากกรณีที่ไม่มีระเบียน
การทดสอบที่ช่วยชี้สาเหตุได้ชัดที่สุดคือสอบถามชื่อเดียวกันผ่านตัวแก้ไขชื่อเดียวกันสองครั้ง เริ่มจากค้นหาตามปกติ แล้วดูสถานะของการตอบกลับ ไม่ใช่ดูเฉพาะค่าที่ได้:
dig example.com A +noall +comments +answerจากนั้นส่งคำขอซ้ำ โดยเปิดบิต CD (DNSSEC Checking Disabled):
dig example.com A +cdflag +noall +comments +answerในเหตุการณ์จริง คำขอปกติได้ SERVFAIL แต่คำขอที่ตั้งบิต CD ได้ระเบียน A ตามที่คาดไว้ ความแตกต่างนี้ชี้อย่างมากว่าปัญหาอยู่ที่การตรวจสอบ DNSSEC ไม่ใช่ระเบียน DNS หายไปหรือแอปพลิเคชันไม่ตอบสนอง ตัวเลือก +cdflag ขอให้ recursive resolver ที่รองรับละเว้นการตรวจสอบ DNSSEC ตามปกติสำหรับคำขอนั้น เป็นเพียงวิธีวินิจฉัย ไม่ใช่วิธีซ่อมปัญหาในเบราว์เซอร์ของผู้เข้าชม และไม่ได้ปิด DNSSEC ให้ผู้เข้าชมเว็บไซต์
อย่าสรุปจากผลลัพธ์ว่างของ +short มากเกินไป ทั้งกรณีไม่มีคำตอบและกรณี SERVFAIL อาจแสดงเป็นบรรทัดว่างเมื่อใช้รูปแบบนี้ ระหว่างวิเคราะห์ปัญหาควรคง +comments ไว้ เพื่อให้เห็น status: SERVFAIL หรือ status: NOERROR อย่างชัดเจน
การเปรียบเทียบด้วยบิต CD เพียงอย่างเดียวยังบอกไม่ได้ว่าส่วนใดของ DNSSEC ล้มเหลว แต่ช่วยบอกว่าควรตรวจสอบจุดใดต่อไป อีกทั้งตัวแก้ไขชื่ออาจพบข้อผิดพลาดชั่วคราวจากระบบต้นทาง จึงควรทดสอบซ้ำเมื่อจำเป็นและตรวจสอบข้อมูลการมอบหมายจากโซนแม่ด้วย
ตรวจสอบระเบียน DS ที่โซนแม่ ไม่ใช่ดูแค่หน้าแก้ไข DNS
เริ่มจากค้นหาระเบียน DS ของโดเมน:
dig example.com DS +noall +comments +answerหากต้องการเห็นเส้นทางการมอบหมายในระบบ DNS อย่างละเอียดขึ้น ให้ไล่ค้นหาตามลำดับชั้นของ DNS โดยตรง:
dig +trace example.com DSเนมเซิร์ฟเวอร์แบบ authoritative ของโซนแม่ที่ต้องสอบถามจริง ๆ ขึ้นอยู่กับโดเมนระดับบนสุด สิ่งสำคัญคือชุดระเบียน DS ที่โซนแม่เผยแพร่ ไม่ใช่แค่ข้อมูลสรุปบนแดชบอร์ดของผู้ให้บริการ DNS การย้ายผู้รับจดทะเบียนโดเมนอาจไม่เปลี่ยนเนมเซิร์ฟเวอร์ และการเปลี่ยนเนมเซิร์ฟเวอร์ก็อาจไม่ต้องย้ายผู้รับจดทะเบียน ไม่ว่าแบบใด ระเบียน DS ที่โซนแม่ต้องสอดคล้องกับโซน authoritative ที่กำลังใช้งานอยู่
ระเบียน DS มีข้อมูลสำคัญสี่ส่วน ได้แก่ หมายเลขกำกับคีย์ (key tag) อัลกอริทึม ประเภทไดเจสต์ และค่าไดเจสต์ หมายเลขกำกับคีย์ช่วยให้ตรวจสอบปัญหาได้สะดวก แต่เพียงหมายเลขตรงกันยังพิสูจน์ไม่ได้ว่า DNSKEY นั้นตรงกับ DS ค่าไดเจสต์และข้อมูลอัลกอริทึมก็ต้องสอดคล้องกับคีย์ที่โซน authoritative ให้บริการจริงด้วย
สภาพที่ชี้ขาดในกรณีนี้ชัดเจนมาก: โซนแม่ยังประกาศข้อมูลความเชื่อถือ DNSSEC เดิม ขณะที่โซน authoritative ใหม่ระบุว่าการลงลายเซ็นยังไม่เปิดใช้งาน ระเบียน A มีอยู่จริงและสามารถเรียกดูได้เมื่อข้ามการตรวจสอบ การแก้ค่าของแอปพลิเคชันหรือแก้ระเบียน A เดิมซ้ำ ๆ จึงไม่สามารถแก้ความไม่สอดคล้องนี้ได้
สองวิธีกู้คืนการมอบหมาย DNSSEC ที่ตรวจสอบไม่ผ่าน
มีกลยุทธ์กู้คืนที่ใช้ได้จริงสองแบบ ทั้งคู่แก้ปัญหาสายโซ่ความเชื่อถือไม่ตรงกัน แต่มีผลต่อการปฏิบัติงานต่างกัน ควรเลือกอย่างมีเหตุผล ไม่ใช่สลับทำไปมาระหว่างสองวิธีโดยไม่มีแผน
ทางเลือกที่ 1: ลบ DS ที่ล้าสมัย แล้วใช้โซนที่ยังไม่ลงลายเซ็นชั่วคราว
ขอให้ผู้รับจดทะเบียนโดเมนปัจจุบัน หรือใช้เครื่องมือจัดการ DNSSEC ที่ผู้รับจดทะเบียนรองรับ เพื่อลบระเบียน DS เก่าออกจากโซนแม่ เมื่อโซนแม่ไม่ยืนยันอีกต่อไปว่าการมอบหมายนี้ต้องผ่านการตรวจสอบความปลอดภัย ตัวแก้ไขชื่อที่ตรวจสอบ DNSSEC จะสามารถมองโซนลูกที่ไม่ได้ลงลายเซ็นว่าเป็นโซนแบบ insecure แทนที่จะเป็นโซนที่ตรวจสอบไม่ผ่าน (bogus) DNS จะกลับมาทำงานได้ แต่โดเมนจะไม่ได้รับการยืนยันความถูกต้องด้วย DNSSEC ชั่วคราว
วิธีนี้มักง่ายกว่าสำหรับการแก้เหตุฉุกเฉิน หากสามารถเปลี่ยนชุดระเบียน DS ที่โซนแม่ได้อย่างเชื่อถือได้ ควรรักษาการตั้งค่าการลงลายเซ็นที่ใช้อยู่ให้คงเดิมจนกว่าระเบียน DS เก่าจะหมดอายุจากแคชของ recursive resolver การเห็นข้อความว่าลบ DS แล้วในแผงควบคุมยังไม่เพียงพอ ต้องตรวจสอบระเบียนที่โซนแม่จากภายนอกและเผื่อเวลาตาม TTL ด้วย HTTPS ทำงานแยกจากการตั้งค่า DNSSEC ขั้นตอนการเปลี่ยนเป็นโซนที่ไม่ลงลายเซ็นชั่วคราวยังอธิบายไว้ใน RFC 8078
ทางเลือกที่ 2: ลงลายเซ็นโซนใหม่และเผยแพร่ DS ที่ตรงกัน
อีกวิธีคือเปิดใช้งาน DNSSEC กับผู้ให้บริการ authoritative DNS รายใหม่ สร้างชุดคีย์ DNSKEY ลงลายเซ็นให้โซน และเผยแพร่ระเบียน DS ที่สอดคล้องกันในโซนแม่ จากนั้นตัวแก้ไขชื่อที่ตรวจสอบ DNSSEC จะสามารถสร้างเส้นทางความเชื่อถือไปยัง DNSKEY ใหม่ และตรวจสอบระเบียน A ได้
นี่คือวิธีที่ใช้กู้คืนได้จริงในเหตุการณ์นี้ ระบบจัดการ DNS รายงานว่าได้สร้างคีย์ ลงลายเซ็นให้โซน และเผยแพร่ DS ใหม่แล้ว ต่อมาเมื่อตรวจสอบโซนแม่ก็พบ DS ใหม่อยู่ร่วมกับ DS เก่า การค้นหาผ่าน recursive resolver ที่ตรวจสอบ DNSSEC เริ่มตอบระเบียน A ตามที่คาดไว้ และการทดสอบภายหลังยังได้ NOERROR พร้อมแฟล็ก ad ซึ่งระบุว่าตัวแก้ไขชื่อนั้นยืนยันความถูกต้องของข้อมูลที่ตอบกลับแล้ว
ลำดับขั้นตอนมีความสำคัญ: DS ที่เผยแพร่จะมีประโยชน์ก็ต่อเมื่อบริการ authoritative DNS เปิดให้เรียกดู DNSKEY ที่ตรงกันและลายเซ็นที่ใช้ได้อยู่ก่อนแล้ว ข้อความว่า “เผยแพร่แล้ว” ในแผงควบคุมใช้แทนการตรวจสอบจากภายนอกไม่ได้ ระเบียน DS, DNSKEY, RRSIG และ NS ที่ค้างอยู่ในแคชอาจทำให้ตัวแก้ไขชื่อแต่ละแห่งกลับมาทำงานได้ในเวลาไม่พร้อมกัน
ทำไมการมี DS สองระเบียนจึงไม่ได้ทำให้เว็บไซต์เสียต่อไปเสมอไป
ผลลัพธ์ที่น่าประหลาดใจอย่างหนึ่งคือโซนแม่มีทั้ง DS เก่าที่ใช้ไม่ได้แล้วและ DS ใหม่ที่ถูกต้องอยู่พร้อมกันชั่วคราว แต่การตรวจสอบ DNSSEC กลับผ่าน เรื่องนี้ไม่ได้ขัดแย้งกัน ชุดระเบียน DS สามารถมีได้หลายระเบียน ซึ่งเกิดขึ้นเป็นปกติระหว่างการเปลี่ยนคีย์ ตัวตรวจสอบไม่จำเป็นต้องพบคีย์ที่ยังใช้งานได้สำหรับ DS ทุกระเบียน ขอเพียงมีเส้นทางยืนยันความถูกต้องที่ใช้ได้อย่างน้อยหนึ่งเส้นทาง ผ่าน DS ที่เหมาะสมไปยัง DNSKEY และลายเซ็นที่ถูกต้อง RFC 6840 ชี้แจงว่าตัวตรวจสอบควรยอมรับเส้นทางที่ถูกต้องเพียงเส้นทางเดียว
อย่างไรก็ตาม ไม่ได้หมายความว่าควรเก็บคีย์เก่าที่ใช้ไม่ได้ไว้ตลอดไป DS ที่ล้าสมัยทำให้การดูแลระบบคลุมเครือขึ้น และควรลบออกในที่สุดหลังยืนยันแล้วว่าสายโซ่ความเชื่อถือใหม่ทำงานถูกต้อง แต่การลบระเบียนเก่าเป็นงานบำรุงรักษา ไม่ใช่เหตุผลให้รีเซ็ต DNSSEC อย่างเสี่ยง ๆ อีกครั้ง ทั้งที่การค้นหาแบบตรวจสอบความถูกต้องกลับมาใช้งานได้แล้ว
มีจุดอันตรายเป็นพิเศษในแผงควบคุม: ปุ่มที่ชื่อว่า “ยกเลิกเผยแพร่ DS ฉุกเฉิน” อาจหมายถึงการลบระเบียน DS ทั้งหมด รวมถึงระเบียนใหม่ที่กำลังทำงานได้ด้วย เช่นเดียวกัน หากปิดการลงลายเซ็นของโซนขณะที่โซนแม่ยังประกาศ DS อยู่ ก็อาจทำให้ปัญหาเดิมกลับมาทันที ทั้งสองอย่างไม่เหมือนกับการลบเฉพาะ DS เก่ารายการเดียว หากหน้าจอไม่รองรับการเลือกแก้เฉพาะระเบียน ควรใช้ช่องทางที่ผู้รับจดทะเบียนรองรับเพื่อแก้ไขเฉพาะจุด แทนการรีเซ็ตทั้งหมด
วิธีเปลี่ยนเนมเซิร์ฟเวอร์แบบ authoritative อย่างปลอดภัย
ลำดับที่ปลอดภัยที่สุดขึ้นอยู่กับว่าผู้ให้บริการ DNS เดิมและรายใหม่สามารถประสานงานเรื่องคีย์กันได้หรือไม่ สำหรับการย้ายแบบทั่วไปที่ยอมให้มีช่วงใช้โซนที่ไม่ลงลายเซ็นชั่วคราว ลำดับต่อไปนี้ช่วยหลีกเลี่ยงความไม่สอดคล้องที่เกิดขึ้นในเหตุการณ์นี้:
- เตรียมโซนปลายทางก่อน คัดลอกระเบียน A, AAAA, CNAME, MX, TXT และระเบียนอื่นที่จำเป็น ทดสอบโดยสอบถามเนมเซิร์ฟเวอร์แบบ authoritative ชุดใหม่โดยตรงก่อนเปลี่ยนการมอบหมาย
- ตรวจสอบ DNSSEC ที่โซนแม่ ดูว่ามีระเบียน DS หรือไม่ และใครมีสิทธิ์แก้ไข ต้องตรวจสอบแม้ไม่เคยเปิด DNSSEC เอง เพราะบางบริการ DNS ตั้งค่าการลงลายเซ็นให้อัตโนมัติ
- ลบ DS เก่าขณะที่โซนเดิมซึ่งลงลายเซ็นแล้วยังทำงานอยู่ ยืนยันว่าการเปลี่ยนแปลงเกิดขึ้นที่โซนแม่แบบ authoritative แล้ว จากนั้นรอให้ข้อมูล DS ที่ถูกแคชไว้ก่อนหน้าหมดอายุ ระยะเวลารอขึ้นอยู่กับค่า TTL ที่ตรวจพบจริง ไม่ใช่จำนวนนาทีตายตัวที่ใช้ได้ทุกกรณี
- เปลี่ยนการมอบหมายเนมเซิร์ฟเวอร์ รักษาบริการ authoritative DNS เดิมให้พร้อมใช้งานต่อในช่วงที่ข้อมูลการมอบหมาย NS ในแคชอาจยังชี้ไปที่นั่น คำนึงถึง TTL ของ NS ที่โซนแม่ และตรวจสอบว่าตัวแก้ไขชื่อต่าง ๆ ใช้เซิร์ฟเวอร์ใดจริง
- ตัดสินใจว่าจะเปิด DNSSEC อีกหรือไม่ หากต้องการให้บริการใหม่เป็นโซนที่ไม่ลงลายเซ็นต่อไป ก็อย่าเผยแพร่ DS หากต้องการลงลายเซ็น ให้ตรวจสอบก่อนว่า DNSKEY และลายเซ็นใหม่ถูกให้บริการอย่างถูกต้อง แล้วจึงเผยแพร่ DS ที่ตรงกัน พร้อมประสานจังหวะกับข้อมูล NS เก่าที่ยังค้างในแคช เพื่อไม่ให้เกิดการตรวจสอบไม่ผ่านรอบใหม่
- ตรวจสอบผลจากภายนอกอย่างเป็นอิสระ ตรวจสอบ DS ที่โซนแม่ DNSKEY จากบริการ authoritative DNS ผลการค้นหาผ่าน recursive resolver ตามปกติ และสถานะการยืนยันข้อมูลจากตัวแก้ไขชื่อที่ตรวจสอบ DNSSEC
หากจำเป็นต้องรักษาการป้องกันด้วย DNSSEC โดยไม่มีช่วงขาดตอน ควรใช้การเปลี่ยนคีย์ที่ประสานกันอย่างชัดเจน หรือการย้ายแบบหลายผู้ลงลายเซ็น (multi-signer) ซึ่งต้องอาศัยการรองรับการจัดการคีย์และการลงลายเซ็นที่จำเป็นจากผู้ให้บริการ DNS ทั้งสองฝ่าย การคัดลอกค่าไดเจสต์ของ DS เก่าไปยังผู้ให้บริการใหม่เฉย ๆ ไม่ถือเป็นการเปลี่ยนคีย์
รายการตรวจสอบสั้น ๆ หลังย้ายเนมเซิร์ฟเวอร์
หลังการเปลี่ยนแปลงใด ๆ ที่เกี่ยวข้องกับ DNSSEC ให้ตรวจสอบทั้งระเบียน DNS และหลักฐานว่าตัวแก้ไขชื่อยอมรับการตรวจสอบนั้น:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerใช้ recursive resolver ที่ตรวจสอบ DNSSEC เพื่อเช็กว่าคำตอบได้รับการยืนยันหรือไม่ หากได้ NOERROR พร้อมระเบียน A ที่คาดไว้ แสดงว่าการแก้ไขชื่อสำเร็จ และหากมีแฟล็ก ad ด้วย หมายความว่าตัวแก้ไขชื่อนั้นยืนยันคำตอบตามนโยบาย DNSSEC ของตน อย่างไรก็ตาม การไม่มีแฟล็ก ad เพียงอย่างเดียวไม่ได้พิสูจน์ว่าการตรวจสอบล้มเหลว เพราะความสามารถ นโยบาย และแฟล็กในคำขอของตัวแก้ไขชื่อแต่ละแห่งต่างกัน หากการสอบถาม DNSKEY ผ่านตัวแก้ไขชื่อที่ตรวจสอบ DNSSEC ล้มเหลวระหว่างเกิดเหตุ ให้สอบถามบริการ authoritative DNS ที่ใช้งานอยู่โดยตรงเพื่อประกอบการวิเคราะห์
อย่าหยุดตรวจสอบเพียงเพราะตัวแก้ไขชื่อแห่งหนึ่งตอบสำเร็จแล้ว แคชแต่ละแห่งอาจยังเก็บข้อมูลการมอบหมายและคีย์ต่างชุดกันชั่วคราว นอกจากนี้ควรอัปเดตคำร้องขอความช่วยเหลือด้านปฏิบัติการที่ยังเปิดอยู่ด้วย เพราะคำแนะนำเดิมให้ “ลบระเบียน DS ทั้งหมด” จะกลายเป็นความเสี่ยงทันทีที่ DS ใหม่ที่ใช้งานได้ถูกเผยแพร่แล้ว การติดตามเรื่องควรระบุชัดเจนให้คงคีย์ที่กำลังใช้งานอยู่ และหากจำเป็นให้ลบเฉพาะระเบียนเก่าที่ล้าสมัย
เหตุขัดข้องนี้ไม่ได้เกิดจากที่อยู่เว็บเซิร์ฟเวอร์ผิด แต่เกิดจากการเปลี่ยนแหล่งที่ให้คำตอบ DNS โดยไม่ได้ปรับข้อมูลความเชื่อถือที่ใช้ตัดสินว่าคำตอบใดเชื่อถือได้ให้ตรงกันก่อน ดังนั้นคำถามที่ควรถามก่อนสลับเนมเซิร์ฟเวอร์ทุกครั้งคือ โซนแม่กำลังเผยแพร่ระเบียน DS ใดอยู่บ้าง และ DNSKEY กับลายเซ็นของโซนปลายทางสามารถทำให้การตรวจสอบตามระเบียนเหล่านั้นผ่านได้หรือไม่?