DNS ตอบได้ ไม่ได้แปลว่า DNSSEC ปลอดภัย: บทเรียนจากสองเซิร์ฟเวอร์

เวลาเว็บไซต์เข้าได้ เรามักถือว่า DNS ทำงานปกติ แต่คำตอบที่ส่งกลับมาไม่ได้บอกเองว่ามีการตรวจลายเซ็น DNSSEC แล้ว บทความนี้เล่างานจริงบนสองเซิร์ฟเวอร์: เครื่องที่เป็นทั้ง authoritative DNS และ resolver ซึ่งเราตรวจหลัง root KSK เปลี่ยน กับ resolver อีกเครื่องที่ต้องแก้ validation และ trust anchor โดยเก็บหลักฐานแยกกัน

สรุปสำหรับผู้บริหาร

เซิร์ฟเวอร์ A ทำทั้ง authoritative และ resolver; การตรวจ root KSK เป็นงานฝั่ง resolver
ผลติดตาม A พบ root DNSKEY ลงนามด้วยกุญแจใหม่พร้อม AD ไม่ใช่อาศัย cache signer เก่า
เซิร์ฟเวอร์ B ปิด validation; เมื่อเปิดพบ bootstrap anchor ไม่พร้อมและต้องแก้
หลังแก้ B ผ่านในเส้นทางที่ทดสอบ แต่ยังไม่ครอบคลุม client ทุก view และการ restart
DNSSEC ตรวจความถูกต้องและที่มาของข้อมูล ไม่ได้เข้ารหัส DNS หรือรับรองความปลอดภัยเว็บไซต์

DNSSEC เพิ่มอะไรให้ DNS

DNS Security Extensions หรือ DNSSEC เพิ่มลายเซ็นดิจิทัลให้ข้อมูล DNS เพื่อให้ผู้ตรวจสอบพิสูจน์ความถูกต้องและที่มาของข้อมูลได้ ฝั่ง authoritative server เผยแพร่ข้อมูลพร้อมลายเซ็น ส่วน validating resolver ตรวจลายเซ็นและเชื่อม chain of trust ไปยัง trust anchor ที่เชื่อถืออยู่แล้ว การมีข้อมูล DNSSEC ให้ดาวน์โหลดจึงไม่เท่ากับ resolver กำลังตรวจข้อมูลนั้น

DNSSEC ไม่ใช่การเข้ารหัสการรับส่ง DNS และไม่ได้รับรองว่าเว็บไซต์ปลายทางปลอดภัย สำหรับผู้ดูแล recursive resolver คำถามสำคัญคือระบบบังคับปฏิเสธข้อมูลที่ตรวจไม่ผ่านหรือไม่ โดยยังต้องรองรับชื่อที่ไม่ได้ลงนามอย่างถูกต้องตาม chain of trust ด้วย

Resolver ตรวจ DNSSEC อย่างไร: มองผ่านสถานะและ actors

ภาพนี้เป็นสถานะเชิงแนวคิดสำหรับคำขอหนึ่ง ไม่ใช่สถานะของทั้งเซิร์ฟเวอร์หรือ packet trace กล่องเหลี่ยมคือ Client และ Root DNS; กล่องมนในกรอบคือสถานะภายใน resolver. Chain ยังมีข้อมูลจาก parent และ zone ปลายทางต่อหลังตรวจ root RRset ซึ่ง diagram ย่อไว้

ภาพนี้เจาะจงกรณี root KSK ที่เราตรวจ: ข้อมูลก่อนหน้าใน cache ลงนามด้วย signer 20326; หลัง cache miss/หมดอายุ authoritative root ให้ root DNSKEY ชุดใหม่ที่ลงนามด้วย 38696. กุญแจ 38696 ต้องเป็น trust anchor ที่ resolver ยอมรับจึงจะยืนยัน root RRset ใหม่ได้ ทั้ง key tag และช่วงเวลานี้เป็นหลักฐานของเหตุการณ์ที่เล่า ไม่ใช่ค่าหรือกำหนดการของทุกระบบ เส้นประแสดงการ fetch/รับ root DNSKEY ไม่ได้หมายถึงต้องถาม root ใหม่ทุก query

KSK ใช้ลงนาม DNSKEY RRset ของ root ไม่ได้ลงนามคำตอบของแต่ละเว็บไซต์โดยตรง เมื่อยืนยัน root DNSKEY แล้ว resolver ยังต้องตรวจ DS/DNSKEY และ RRSIG ของ zone ที่เกี่ยวข้องต่อ หาก root DNSKEY ชุดใหม่ยังยืนยันไม่ได้ คำตอบปกติหรือ SERVFAIL ที่เห็นต้องวินิจฉัยต่อจาก trust anchor และหลักฐานใน runtime ไม่สรุปจากการพบ key tag ใหม่เพียงอย่างเดียว

Resolver เริ่มจากเลือก view และนโยบายของคำขอ จากนั้นรวบรวม RRset ที่ต้องการพร้อมข้อมูลประกอบการตรวจ เมื่อจำเป็นต้องสร้าง chain of trust จะใช้ trust anchor ที่เชื่อถืออยู่แล้วตรวจ DNSKEY/DS ต่อไปยัง zone ลูก และใช้ DNSKEY ตรวจ RRSIG ของ RRset เป้าหมาย รวมถึงตรวจช่วงเวลาที่ลายเซ็นใช้ได้ การเห็น DNSKEY หรือ RRSIG ในคำตอบเพียงอย่างเดียวจึงยังไม่พอ

Secure: มี chain ที่ยืนยันข้อมูลได้ถึง trust anchor คำตอบอาจตั้ง AD เมื่อข้อมูลที่เกี่ยวข้องผ่านเงื่อนไขของ response ทั้งหมด ไม่ใช่เพราะ RRset หนึ่งชุดผ่านเพียงชุดเดียว และคำตอบที่ยืนยันว่าไม่มีชื่อหรือไม่มีชนิดข้อมูลก็อาจเป็น Secure ได้
Insecure: มีเหตุผลที่พิสูจน์ได้ว่าเส้นทางนั้นไม่ต้องลงนาม เช่น insecure delegation ที่ตรวจจาก parent แล้ว คำตอบปกติจึงออกได้โดยไม่มี AD การไม่พบลายเซ็นเฉย ๆ ไม่ใช่หลักฐานเพียงพอให้จัดเป็น Insecure
Bogus: ตาม chain ควรตรวจความถูกต้องได้ แต่การตรวจล้มเหลว เช่น ลายเซ็นไม่ผ่านหรือข้อมูล DNSSEC ที่ควรมีขาดหาย สำหรับ validating resolver ที่ใช้พฤติกรรมปกติและคำขอ CD=0 ข้อมูลนี้ต้องไม่ถูกส่งเป็นคำตอบที่เชื่อถือได้ และตอบ SERVFAIL ตามกรณีในภาพ
Indeterminate: ยังตัดสินไม่ได้ว่าข้อมูลควรมีลายเซ็นหรือไม่ เพราะไม่มี trust anchor ที่ใช้ได้หรือรวบรวมหลักฐานที่จำเป็นไม่ได้ ไม่ใช่คำพ้องกับ Bogus และไม่ใช่สถานะ “ปลอดภัยแล้ว” การตอบกลับหรือความล้มเหลวของ resolution ขึ้นกับนโยบายและสาเหตุที่เกิดขึ้น จึงไม่ผูกสถานะนี้กับรหัสตอบกลับตายตัวในภาพ

ภาพสมมติว่าเปิด validation ใช้ CD=0 และไม่มีนโยบายยกเว้นมาข้ามการตรวจ หาก client ส่ง +cd หรือปิด validation เส้นทางตอบกลับอาจต่างออกไป จึงใช้ภาพนี้ตีความผลเหล่านั้นโดยตรงไม่ได้ เช่นเดียวกับ SERVFAIL หรือ timeout ที่ต้องหาสาเหตุเพิ่มเติม ไม่ใช่หลักฐานว่าเป็น Bogus เสมอไป

เมื่อเทียบกับงานจริงของเรา A ต้องพิสูจน์ว่าข้อมูลที่ลงนามด้วย root key ใหม่ยังตรวจผ่าน ไม่ใช่อาศัยข้อมูลเก่าใน cache ส่วน B เริ่มจากปิด validation ซึ่งอยู่นอกสมมติฐานของภาพ เมื่อเปิดแล้วจึงตรวจพบข้อจำกัดของ bootstrap anchor และแก้จากหลักฐาน runtime ดังที่เล่าต่อไป

เป้าหมายและขอบเขตของงานสองเครื่อง

เราเรียกเครื่องทั้งสองว่าเซิร์ฟเวอร์ A และ B เพื่อไม่เปิดเผยตัวระบบจริง A ให้บริการ authoritative DNS และ recursive resolution ในเครื่องเดียวกัน ส่วนกรณี B เราเน้นเส้นทาง resolver ที่ต้องแก้นโยบาย validation กับ bootstrap anchor ไม่ถือว่าเครื่องใดเป็นหลักฐานแทนอีกเครื่อง

เกณฑ์ที่ต้องการคือ runtime ยอมรับ root anchor ที่ใช้จริง ชื่อที่ลงนามถูกต้องตรวจผ่าน และโดเมนทดสอบลายเซ็นผิดถูกปฏิเสธ ฝั่ง A ต้องตรวจซ้ำเมื่อข้อมูล root DNSKEY ใน cache เปลี่ยนไป ส่วน B ต้องเทียบผลก่อนและหลัง change โดยไม่ทำให้คำตอบ authoritative เดิมถดถอย งานนี้ไม่ใช่การรับรองทุก zone หรือการตรวจระบบอื่นที่เกี่ยวข้องทั้งหมด

เซิร์ฟเวอร์ A: มี anchor แล้ว ทำไมยังต้องรอ cache turnover

การตรวจก่อนเปลี่ยน root signer เมื่อวันที่ 11 ตุลาคม 2026 พบว่า A ยอมรับกุญแจใหม่ 38696 ใน runtime แล้ว แต่ root DNSKEY ที่ได้รับขณะนั้นยังมีลายเซ็นจากกุญแจเดิม 20326 ผลนั้นยืนยันความพร้อมส่วนหนึ่ง แต่ยังไม่พิสูจน์ว่า resolver ตรวจข้อมูลที่ลงนามด้วยกุญแจใหม่ได้จริง

สิ่งที่รอไม่ใช่ “กุญแจ KSK หมดอายุ” แต่เป็นข้อมูล root DNSKEY และลายเซ็นชุดเดิมใน cache หมด TTL หรือถูกแทนที่ การรอครบช่วงเวลาประมาณหนึ่งอย่างเดียวไม่พอ ต้องกลับมาอ่าน signer และผล validation จริง โดยไม่ flush cache เพื่อบังคับให้ได้คำตอบตามที่ต้องการ

ผลติดตามวันที่ 22 ตุลาคม 2026 พบ root DNSKEY ลงนามด้วย 38696 และได้ NOERROR พร้อม AD ทั้ง UDP และ TCP ขณะ runtime ยังแสดงกุญแจใหม่เป็น managed/trusted ชื่อ signed control ผ่าน และ delv รายงาน fully validated จึงได้หลักฐานปัจจุบันที่ไม่อาศัย signer เก่าแล้ว แต่ไม่ได้พิสูจน์เวลาที่ cache เปลี่ยนครั้งแรกหรือรับรองความต่อเนื่องตลอดช่วงระหว่างการตรวจ

โดเมนทดสอบลายเซ็นผิดมี query แรก timeout ก่อน เมื่อทดสอบซ้ำด้วยเวลารอที่ยาวขึ้นได้ SERVFAIL ทั้ง UDP/TCP และเมื่อใช้ +cd ได้ NOERROR เราแยก timeout ออกจากผลปฏิเสธ เพราะ timeout ไม่ใช่หลักฐานว่า DNSSEC ทำงานถูกต้อง

บทบาท authoritative ต้องแยกจาก resolver: dnssec-validation auto ใช้ตรวจข้อมูลที่ resolver รับมา ไม่ได้ลงนาม zone ให้โดยอัตโนมัติ และการตรวจ root KSK ผ่านไม่ได้รับรองว่า authoritative zones โหลดครบหรือมีระบบ re-signing ที่ถูกต้อง

เซิร์ฟเวอร์ B: คำตอบปกติซ่อนช่องว่างของการตรวจ

ในรอบตรวจเริ่มต้น resolver ตอบชื่อที่ใช้งานทั่วไปได้ แต่เมื่อถามโดเมนทดสอบ DNSSEC ที่จงใจมีปัญหา ก็ยังได้ NOERROR โดยไม่มี flag AD การอ่าน effective configuration พบว่า dnssec-validation no; มีผลกับแต่ละ view ที่ตรวจ และ runtime trust-anchor state ยังว่าง สัญญาณทั้งหมดประกอบกันจึงรองรับข้อสรุปว่า local validation ถูกปิด ไม่ใช่สรุปจากการไม่มี AD เพียงอย่างเดียว

ข้อสรุปนี้มาจากคำตอบของ endpoint ที่ client ใช้จริง ประกอบกับ effective configuration และ runtime ของ B ไม่ได้อนุมานจากผลบน A การเห็นชื่อทั่วไปตอบได้จึงยังไม่บอกว่า B บังคับตรวจข้อมูล DNSSEC แล้ว

ภาพนี้เป็นขั้นตอนตรวจเชิงแนวคิด ไม่ใช่โครงสร้างเครือข่ายจริง และไม่ใช่เงื่อนไขรับรองระบบจาก query เดียว

เซิร์ฟเวอร์ B: เปิด validation แล้วพบปัญหาอีกชั้น

การเปลี่ยนค่าเป็น auto อย่างเดียวไม่ใช่คำตอบเสมอไป บันทึกระหว่างตรวจพบว่าเมื่อเปิด validation ตัว resolver ใช้ bootstrap root anchor ที่ไม่ครอบคลุมกุญแจซึ่งใช้ตรวจ root DNSKEY ในรอบนั้น Log และ managed-key state แสดงการตรวจไม่ผ่าน และชื่อปกติเริ่มตอบ SERVFAIL

จุดตัดสินไม่ใช่แค่ว่าติดตั้งแพ็กเกจข้อมูลกุญแจแล้วหรือยัง แต่คือ BIND build นี้อ่าน anchor จากที่ใด มีไฟล์นั้นจริงหรือไม่ และ runtime ยอมรับกุญแจแล้วหรือยัง ไฟล์ bootstrap กับ managed-key state มีบทบาทต่างกัน การเห็นกุญแจอยู่บน disk จึงยังไม่รับรองว่าระบบที่กำลังให้บริการใช้มันได้

ก่อนแก้ เราตรวจที่มาของ candidate anchor กับข้อมูล IANA ที่ตรวจลายเซ็นแล้ว และตรวจความเข้ากันได้ของ syntax กับ BIND ที่ติดตั้งจริง หลังได้รับอนุมัติจึงวาง anchor ที่ตรวจแล้ว เปิด validation และ activate ด้วย rndc reconfig รอบนี้ไม่ได้อัปเกรดแพ็กเกจ ไม่ restart ไม่ล้าง cache และไม่ลบ managed-key database เพื่อบังคับให้ผลผ่าน

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

หลักฐานก่อนและหลังเปลี่ยนของ B

ตารางนี้เป็นผลเฉพาะ B จากบันทึกการปฏิบัติงานวันที่ 12 ตุลาคม 2026 ไม่ใช่ผลตรวจสดของ B ในวันที่เขียนบทความ และไม่ใช่ผลก่อน/หลังของ A

จุดตรวจ	ก่อนแก้	หลังแก้ในขอบเขตที่ทดสอบ
นโยบาย validation	ปิดใน effective configuration	เปิดและ runtime ยอมรับ root anchor ในแต่ละ view ที่ตรวจ
ชื่อที่ลงนามถูกต้อง	ได้คำตอบโดยไม่มี `AD`	เส้นทาง client ที่ทดสอบได้ `NOERROR` พร้อม `AD`
โดเมนทดสอบลายเซ็นผิด	ได้ `NOERROR`	query ปกติได้ `SERVFAIL`; เมื่อขอ `+cd` ได้ `NOERROR`
ตรวจด้วย `delv`	ไม่ใช้ผลส่วนนี้รับรองสถานะก่อนแก้	ชื่อที่เลือกตรวจรายงาน `fully validated`
บริการ authoritative เดิม	เก็บคำตอบและ serial เป็น baseline	status และ serial ของชุดที่เทียบไม่เปลี่ยน
managed-key state บน disk	ยังไม่มี state ที่พร้อมใช้ใน view ที่ตรวจ	หลังสั่ง sync พบ state ของกุญแจที่ยอมรับแล้ว

AD หรือ Authenticated Data เป็นคำยืนยันจาก resolver ว่าข้อมูลที่เกี่ยวข้องผ่าน validation ผู้ใช้ยังต้องเชื่อถือ resolver และเส้นทางรับส่ง ไม่ควรตีความ flag นี้ว่า client ตรวจลายเซ็นเอง ส่วน delv ทำ validation ฝั่งเครื่องมือโดยไม่อาศัยเพียงคำกล่าวของ resolver แต่ใช้ resolver/validator logic ของ BIND เช่นกัน จึงไม่ใช่การเทียบกับ implementation คนละผู้ผลิต

ที่สำคัญ NOERROR โดยไม่มี AD ไม่ได้แปลว่าระบบเสียเสมอไป โดเมนที่ไม่มีลายเซ็นและพิสูจน์ insecure delegation ได้อาจตอบเช่นนั้นอย่างถูกต้อง ต้องเลือก signed control ที่เหมาะสมและอ่านสถานะข้อมูลประกอบ

ลองตรวจของตัวเองอย่างไรโดยไม่แก้ config

ตัวอย่างนี้เป็นคำสั่งสำหรับปรับไปใช้กับ resolver ที่คุณมีสิทธิ์ทดสอบ ไม่ใช่คำสั่งที่รันใหม่เพื่อจัดทำบทความ ให้แทน resolver.example.com ด้วยเครื่องเป้าหมายของคุณ และตรวจว่ามี dig กับ delv รุ่นที่รองรับ trust anchor ปัจจุบันอยู่แล้ว

# resolver.example.com เป็น placeholder ไม่ใช่เครื่องทดสอบสาธารณะ
resolver=resolver.example.com

# ขอข้อมูล DNSSEC จาก root และ signed control
 dig @"$resolver" . DNSKEY +dnssec
 dig @"$resolver" isc.org. A +dnssec

# เทียบโดเมนทดสอบที่ควรถูกปฏิเสธ กับคำขอปิด checking สำหรับ query นี้
 dig @"$resolver" dnssec-failed.org. A +dnssec
 dig @"$resolver" dnssec-failed.org. A +dnssec +cd

# ตรวจ validation ฝั่งเครื่องมือ และอ่าน trace เมื่อไม่ผ่าน
 delv @"$resolver" +rtrace iana.org. A

+dnssec ขอให้ส่งข้อมูล DNSSEC มาประกอบ ไม่ได้สั่งให้ dig ตรวจลายเซ็นเอง ส่วน +cd ขอปิด checking ที่ resolver สำหรับ query นั้นเพื่อช่วยวินิจฉัย ไม่ใช่วิธีแก้ถาวร โดเมนทดสอบและสถานะลายเซ็นของ control ต้องตรวจยืนยันอีกครั้งในวันที่นำไปใช้

ถ้าคำถามปกติได้ SERVFAIL แต่ +cd ได้คำตอบ ให้ถือว่าเป็นเบาะแสของเส้นทาง validation แล้วตรวจ log, trust anchor, เวลาเครื่อง และข้อมูลลายเซ็นต่อ ไม่ควรสรุปทันทีว่าขาด root key ส่วน delv ต้องอ่านข้อความผลตรวจและ trace ด้วย ไม่ควรตัดสินว่า validation ผ่านจาก exit code อย่างเดียว

View และ ACL ทำให้คำว่า “ตรวจครบ” ยากกว่าที่คิด

BIND view เลือกข้อมูลและนโยบายตามเงื่อนไขของ client การ query จากเครื่องผู้ดูแลหรือจาก localhost จึงอาจไม่ได้เข้า view เดียวกับผู้ใช้ที่ต้องการตรวจ ในกรณี B เราใช้ source address, ACL และความแตกต่างของ authoritative answers ประกอบการยืนยัน view แทนการเดาจากชื่อเครื่อง

แม้ runtime anchor ของแต่ละ view ที่ตรวจจะพร้อม แต่ยังไม่มี client ที่ได้รับอนุญาต recursion สำหรับ view อีกเส้นทางหนึ่ง ผลที่ถูกปฏิเสธหรือได้เพียง referral จึงไม่ถูกนับเป็น recursive E2E ที่ผ่าน เราไม่ขยาย ACL เพื่อทำให้เทสต์ผ่าน เพราะนั่นเป็นการเปลี่ยนนโยบายบริการอีกเรื่องหนึ่ง

สิ่งที่ผ่านแล้ว และสิ่งที่ยังไม่ควรอ้าง

ในขอบเขตที่บันทึกไว้ เราตรวจ runtime anchor, signed/bogus controls, UDP/TCP และ validation ด้วย delv จากเส้นทาง client ที่เข้าถึงได้ พร้อมเทียบ authoritative baseline ก่อนและหลังเปลี่ยน แต่การเขียน managed-key state ลง disk ไม่ใช่การทดสอบว่า state จะคงอยู่หลัง restart

สำหรับ B บันทึกติดตามยังแยกงาน restart persistence, observation หลังเปลี่ยน และ client coverage ของ view ที่เหลือออกไว้ บทความนี้ไม่ได้ตรวจยืนยันว่ารายการเหล่านั้นเสร็จในภายหลัง และไม่รับรองสถานะปัจจุบันของ B ส่วน A มีผลตรวจจริงวันที่ 22 ตุลาคมแล้ว แต่การอ่านประวัติ log ครอบคลุมช่วงตั้งแต่รอบเดิมยังไม่ครบ จึงไม่อ้างว่าปลอดข้อผิดพลาดตลอดช่วงนั้น

ก่อนเปลี่ยน production ควรกำหนด baseline ของชื่อที่บริการพึ่งพา สำรอง config/state พร้อมตรวจ checksum ขออนุมัติและเตรียมเกณฑ์หยุดกับ rollback ให้ชัด การ rollback กลับไปปิด validation อาจช่วยคืนการตอบชื่อ แต่ลดการป้องกัน DNSSEC จึงต้องถือเป็นการตัดสินใจด้านความเสี่ยง ไม่ใช่ผลสำเร็จด้านความปลอดภัย และไม่ควรลบหรือ reset managed keys โดยไม่มีการทบทวนสถานะกับแผนกู้คืน

สรุปชวนใช้

เริ่มตรวจจากคำถามเล็ก ๆ สามข้อ: ชื่อที่ลงนามถูกต้องผ่านหรือไม่ ข้อมูลที่ลายเซ็นผิดถูกปฏิเสธหรือไม่ และผลนั้นตรงกับ config กับ runtime ของ view ที่ client ใช้จริงหรือไม่ จากนั้นค่อยขยายไปสู่ persistence และความครอบคลุมของเส้นทางบริการ

สองเครื่องให้บทเรียนคนละด้าน: A แสดงว่าความพร้อมก่อน rollover ต้องตามด้วยผลจากข้อมูลที่ลงนามด้วยกุญแจใหม่ ส่วน B แสดงว่าการเปิด validation ต้องมี bootstrap anchor และการตรวจผลที่พร้อมรองรับ การแยก “ตอบได้” “ตรวจแล้ว” และ “ตรวจครบขอบเขต” ทำให้เราไม่เอาความสำเร็จของเครื่องหนึ่งไปเติมช่องว่างของอีกเครื่อง

แหล่งอ้างอิง

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