Resolver รุ่นเก่าไม่รู้จัก Root KSK-2024
จากการตรวจพบ จนถึงการแก้ไขอย่างปลอดภัย

1. สรุปสั้น

• อาการ: resolver ที่ปิด DNSSEC validation ตอบ DNS ได้ปกติ แต่ไม่ปฏิเสธข้อมูลที่ลายเซ็นผิด เมื่อมีการเปิด dnssec-validation auto บน BIND รุ่น 9.16 ทั้ง view กลับ SERVFAIL ทั่วไป
• สาเหตุราก: ไฟล์ bootstrap root key ของ BIND หายไป ทำให้ BIND ใช้ key ที่ฝังในโปรแกรม ซึ่งมีเฉพาะ KSK-2017 (key tag 20326) แต่ root ลงนามด้วย KSK-2024 (key tag 38696) แล้ว
• ทางเลือกที่ดูเหมือนง่ายแต่ไม่แก้: อัปเดตแพ็กเกจ dns-root-data หรืออัปเกรด BIND ภายใน distribution รุ่นเก่า
• วิธีแก้ที่เลือก: วางไฟล์ bind.keys ที่มี initial-ds 38696 (ตรวจเทียบ IANA แล้ว) และเปิด validation ด้วย change ขนาดเล็ก พร้อมสำรองข้อมูลและ rollback
• ผล: ทุก view ยอมรับ 38696 และ validation ทำงานจริง ส่วน persistence หลัง restart และการสังเกต 24 ชั่วโมงยังเป็นงานติดตาม

2. ภูมิหลัง: Root KSK rollover

IANA กำหนดให้ KSK-2024 (38696) เริ่มลงนาม DNSKEY RRset ของ root แทน KSK-2017 (20326) ในวันที่ 11 ตุลาคม 2026 โดย key ใหม่ถูกเผยแพร่ล่วงหน้าตั้งแต่ 11 มกราคม 2025 ผู้ดูแล validating resolver ต้องมั่นใจว่า resolver เชื่อถือ key ใหม่ ไม่ใช่เพียงเห็น key ในคำตอบ

3. วัตถุประสงค์และเป้าหมายของการแก้ไข

วัตถุประสงค์

• ให้ resolver เชื่อถือ KSK-2024 (38696) ในทุก view ที่ให้บริการ และเปิด validation กลับมาอย่างต่อเนื่อง
• ได้ trust anchor ที่ตรวจสอบที่มาได้ ไม่ใช่ key ที่คัดลอกจากแชตหรือคำนวณเองโดยไม่มีการเทียบ
• เปลี่ยนแปลงน้อยที่สุด กลับคืนได้ และอธิบายผลได้ด้วยหลักฐาน

เกณฑ์สำเร็จ

• Runtime แสดง 38696 ; managed ทุก view ไม่ใช่ initializing
• Root DNSKEY ตอบพร้อม AD และ signer 38696; โดเมนปกติ validate ผ่าน
• โดเมนที่ลายเซ็นผิดได้ SERVFAIL และตอบได้เมื่อใช้ +cd
• ข้อมูล authoritative และโดเมนภายในไม่ถดถอยเมื่อเทียบกับ baseline
• State คงอยู่หลัง restart และไม่มี validation error ผิดปกติในช่วงสังเกต

สิ่งที่ไม่ใช่เป้าหมาย

• ไม่ขยาย ACL หรือเปิด recursion กว้างเพื่อให้การทดสอบผ่าน
• ไม่ลบหรือ reset managed-key database แบบลองผิดลองถูก
• ไม่ flush cache เพื่อเร่งผลทดสอบ
• ไม่ปนงานอัปเกรด OS หรือ BIND เข้ากับ change นี้

4. ลำดับเหตุการณ์ (ใช้ลำดับ ไม่ระบุเวลาจริง)

5. ข้อจำกัด

5.1 ข้อจำกัดของเครื่องที่ใช้ตรวจ

• เครื่องตรวจเป็น macOS ซึ่งมี delv 9.10.6 มากับระบบ ไม่มี crypto support จึงไม่โหลด trust anchor และตรวจ DNSSEC ไม่ได้
• dig ตัวเก่าให้ AD flag ได้แค่ตามที่ resolver รายงาน ไม่ได้ตรวจลายเซ็นเอง
• เครื่องตรวจอยู่ใน client network กลุ่มเดียว จึงเห็นได้เพียง view เดียว

5.2 ข้อจำกัดของ resolver เป้าหมาย

• BIND สาย 9.16 ซึ่ง ISC ประกาศ end-of-life แล้ว และ distribution รุ่นนั้นมีแพ็กเกจ BIND ใหม่สุดเพียง 9.18.30
• BIND 9.16.x และ 9.18.30 ที่ ISC ปล่อย ไม่มี key 38696 ใน bind.keys และในตัวโปรแกรม ISC เพิ่ม initial-ds 38696 ตั้งแต่ 9.18.39 / 9.20.x
• ไฟล์ bind.keys เป็น conffile ของแพ็กเกจ และถูกลบไปก่อนหน้า
• มีสอง view ที่ใช้ ACL ร่วมกัน ทำให้บาง view ไม่มี client ที่ได้รับอนุญาต recursion ให้ทดสอบ

5.3 ข้อจำกัดของการทดสอบ

• การทดสอบ sentinel ใช้ได้ต่อเมื่อ resolver รองรับ RFC 8509 เท่านั้น
• Root DNSKEY ที่ cache อยู่อาจยังมีลายเซ็นจาก key เดิม จึงยังไม่เห็นการรับข้อมูลชุดใหม่จนกว่า cache จะหมดอายุ
• การ reload หรือ restart ระหว่างตรวจจะทำให้ผลการสังเกตเปลี่ยน จึงต้องแยกการตรวจแบบอ่านอย่างเดียวออกจากการเปลี่ยนแปลง

6. Workaround ในการตรวจสอบ

6.1 เครื่องมือ delv: ตรวจ DNSSEC บนฝั่ง client

delv (DNS lookup and validation utility) เป็นเครื่องมือของ ISC BIND สำหรับดึงคำตอบ DNS และตรวจลายเซ็นบนเครื่องที่รันคำสั่ง โดยขอ DNSKEY และ DS เพื่อสร้างห่วงโซ่จาก root ถึงโดเมน ไม่เพียงเชื่อ AD flag ที่ resolver ส่งมา

ติดตั้งและตรวจเครื่องมือ

# Ubuntu/Debian: ตัว delv อยู่ในแพ็กเกจ bind9-dnsutils
sudo apt-get install bind9-dnsutils
command -v delv
delv -v

# macOS: ติดตั้ง BIND tools จาก Homebrew ไม่ต้องเปิดบริการ DNS
brew install bind
"$(brew --prefix bind)/bin/delv" -v

# เลือก BIND tools สำหรับ shell ปัจจุบัน โดยไม่แทนที่ binary ของระบบ
export PATH="$(brew --prefix bind)/bin:$PATH"
command -v delv
delv -v

ตรวจแพ็กเกจที่ผู้ผลิตรองรับสำหรับ OS ของคุณก่อนติดตั้ง; การติดตั้งอาจอัปเดต dependencies หากจะบันทึก PATH ลงไฟล์ shell ให้สำรองและตรวจ checksum ก่อนแก้ ไม่ต้องเปิดบริการ named เพียงเพื่อใช้เครื่องมือ client

คำสั่งใช้งาน

# แทน RESOLVER_IP ด้วย resolver จริง และรันจากเครือข่ายที่ ACL อนุญาต
delv @RESOLVER_IP iana.org. A
delv @RESOLVER_IP +rtrace iana.org. A     # แสดง query ที่ใช้ประกอบการตรวจ
delv @RESOLVER_IP +vtrace iana.org. A     # แสดงขั้นตอน validation
delv @RESOLVER_IP +tcp iana.org. A        # ทดสอบ transport TCP
delv @RESOLVER_IP . DNSKEY                # ตรวจ root DNSKEY
delv @RESOLVER_IP dnssec-failed.org. A    # ข้อมูลที่ลายเซ็นผิดควรถูกปฏิเสธ

ถ้าไม่ระบุ @RESOLVER_IP เครื่องมือจะเลือก resolver จาก configuration ของเครื่องตรวจ จึงต้องระบุ endpoint ให้ชัดเจนเมื่อตรวจระบบเป้าหมาย อย่านำ options ของ dig เช่น +time, +tries หรือ +cd มาใช้กับ delv โดยไม่ตรวจคู่มือรุ่นนั้น

อ่านผลและแยกสาเหตุ

Trust anchor ของ delv แยกจาก managed-key database ของ server และไม่ได้ทำ RFC 5011 maintenance เอง หากต้องใช้ -a ANCHOR_FILE ต้องรับไฟล์จากแหล่งที่เชื่อถือและตรวจรูปแบบให้ตรงรุ่น ห้ามตั้ง anchor จาก DNSKEY ที่เพียงดึงได้โดยยังไม่พิสูจน์ที่มา

6.2 Workaround และขอบเขตการยืนยัน

# ตรวจจาก client (RESOLVER_IP คือ resolver ที่ต้องการทดสอบ)
dig @RESOLVER_IP . DNSKEY +dnssec +tcp
dig @RESOLVER_IP isc.org A +dnssec
dig @RESOLVER_IP dnssec-failed.org A +dnssec        # คาด SERVFAIL ถ้า validation ทำงาน
dig @RESOLVER_IP dnssec-failed.org A +dnssec +cd    # คาด NOERROR (ข้ามการตรวจเพื่อเทียบ)
delv @RESOLVER_IP +rtrace iana.org. A              # ต้องเป็น "fully validated"

# ตรวจบนเซิร์ฟเวอร์ BIND ที่มีสิทธิ์ (ทุก view ที่ให้บริการ)
sudo rndc secroots -          # ต้องมี ./RSASHA256/38696 ; managed
sudo rndc managed-keys status

7. สาเหตุราก

1. BIND 9.16 อ่าน bootstrap root key จาก /etc/bind/bind.keys เมื่อเปิด dnssec-validation auto
2. ไม่พบไฟล์ log จึงแจ้ง unable to open ... using built-in keys และ BIND ใช้ key ที่ฝังในโปรแกรมซึ่งมีเฉพาะ 20326
3. Root zone ลงนาม DNSKEY RRset ด้วย 38696 แล้ว จึงตรวจด้วย key ที่มีอยู่ไม่ผ่าน ระบบจึงถือว่า trust chain พัง
4. เพราะ managed-key zone ของแต่ละ view ว่างเปล่า BIND จึงไม่เริ่ม RFC 5011 hold-down และอยู่ในสถานะ initializing

8. ทางเลือกที่พิจารณา

9. ขั้นตอน change (แบบทั่วไป)

9.1 พิสูจน์ข้อมูล trust anchor ก่อนใช้

1. ดาวน์โหลด root-anchors.xml, root-anchors.p7s และ icannbundle.pem จาก IANA
2. ตรวจลายเซ็น: openssl cms -verify -binary -inform DER -in root-anchors.p7s -content root-anchors.xml -CAfile icannbundle.pem -purpose any -out /dev/null
3. เทียบ DS digest ของ 38696 ใน XML (SHA-256: 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16) กับ initial-ds ในไฟล์ที่จะวาง
4. คำนวณ DS จาก root DNSKEY สดด้วย dnssec-dsfromkey -2 เพื่อยืนยันว่าตรงกับ IANA
5. ให้ named-checkconf ของรุ่นปลายทางอ่านไฟล์ได้

9.2 ตรวจก่อนเริ่ม (หยุดถ้าข้อใดไม่ผ่าน)

• ยืนยันรุ่น BIND และ path ที่ named -V ระบุสำหรับ root key
• จำนวน KEYDATA ในไฟล์ *.mkeys ของ ทุก view ต้องเป็น 0 — BIND จึงจะเชื่อถือ key จาก bootstrap ได้ทันทีโดยข้าม hold-down 30 วัน ถ้าไม่เป็นศูนย์ให้หยุดและประเมินใหม่ ห้ามลบไฟล์เพื่อไปต่อ
• เวลาเครื่อง synchronized และ upstream ส่ง root DNSKEY พร้อม RRSIG ของ 38696
• มีช่องทางให้ผู้ใช้ใช้ resolver สำรองที่ตรวจแล้วว่ารองรับ split DNS

9.3 สำรองพร้อมตรวจ checksum

B=<BACKUP_DIR>   # โฟลเดอร์สิทธิ์ root เท่านั้น
sudo cp -a /etc/bind/named.conf /etc/bind/named.conf.options "$B/"
sudo cp -a <MANAGED_KEYS_DIR>/*.mkeys* "$B/"
sudo sh -c "cd $B && sha256sum * > SHA256SUMS && sha256sum -c SHA256SUMS"
sudo rndc secroots - | sudo tee "$B/secroots-before.txt" >/dev/null

9.4 ดำเนินการ

1. วางไฟล์ bind.keys ที่มี initial-key ของ 20326 และ initial-ds ของ 38696 ตามสิทธิ์ที่ BIND อ่านได้
2. เปลี่ยนเฉพาะ dnssec-validation no; เป็น dnssec-validation auto; แล้วตรวจ named-checkconf
3. Activate ด้วย rndc reconfig (ไม่ restart ในรอบนี้)
4. ตรวจ log ต้องเห็นการอ่าน bind.keys และ DNSKEY ID 38696 is now trusted ในทุก view
5. รัน rndc managed-keys sync เพื่อบันทึก state ลงดิสก์ แล้วตรวจว่า keyzone ของทุก view มี 38696

9.5 Rollback

เงื่อนไข: เห็น could not be verified with current keys หลัง activate, โดเมนปกติหรือโดเมนภายในสำคัญ SERVFAIL, หรือ 38696 ไม่ managed ในบาง view

1. คืน named.conf.options จาก backup ที่ตรวจ checksum แล้ว ตรวจ syntax และ rndc reconfig
2. ตรวจ hash ของไฟล์ที่คืน, runtime และ valid queries ซ้ำ ไม่ถือว่า script สำเร็จเพียงเพราะ exit 0
3. ไม่ลบ bind.keys และไม่ restore หรือ reset managed state ในขั้นนี้

10. ผลที่ได้ และระดับของหลักฐาน

แยกรายงานระหว่าง static check, การทดสอบ runtime จริง และการ rollback ไม่รวมกัน: การ rollback ถูกเตรียมและตรวจ syntax แล้ว แต่ ไม่ได้ถูกใช้และยังไม่ได้ทดสอบกับ production

11. สิ่งที่ยังเปิดอยู่

• ตรวจ persistence หลัง restart ภายใต้ approval — ต้องยืนยันว่า 38696 ยัง managed และไม่เริ่ม state ใหม่
• สังเกต ≥ 24 ชั่วโมง แยกข้อผิดพลาดของโดเมนเฉพาะ, network timeout และ validation failure ของ root; ไม่ใช้จำนวนบรรทัด log เป็นอัตรา SERVFAIL หากไม่มีจำนวน query ทั้งหมด
• กำหนดว่า view ภายนอกต้องให้บริการ recursion หรือไม่ แล้วหา client ที่ได้รับอนุญาตมาทดสอบ โดยไม่ขยาย ACL เพื่อให้ผ่าน
• วางแผนอัปเกรด OS/BIND แยกต่างหาก และเมื่ออัปเกรดต้องจัดการ conffile ด้วย --force-confold พร้อมตรวจว่า 38696 ยังอยู่

12. บทเรียนและ checklist สำหรับผู้ดูแลอื่น

• “Resolve ได้” ไม่เท่ากับ “validate ได้” — ทดสอบด้วยโดเมนที่ลายเซ็นผิดและเทียบ +cd
• ตรวจ named -V และ log ตอนเริ่มระบบว่าไฟล์ bootstrap ถูกอ่านจริงหรือใช้ built-in
• อย่าเชื่อว่าการอัปเกรดแพ็กเกจจะนำ key ใหม่มาให้ ตรวจเนื้อไฟล์จริงของรุ่นที่จะติดตั้ง
• ก่อนเปิด validation บน BIND รุ่นเก่า ให้ตรวจ trust anchor ที่ bootstrap ได้ล่วงหน้า และตรวจทุก view
• ตรวจให้แน่ใจว่าเครื่องมือตรวจมีความสามารถพอ (crypto) ก่อนตีความผล
• เก็บหลักฐานก่อน/หลัง change สำรองด้วย checksum และเตรียม rollback ที่ไม่ลบ state โดยไม่จำเป็น
• ระบุข้อจำกัดของการทดสอบอย่างเปิดเผย แทนการรายงานว่า “ผ่านทั้งหมด”

13. อ้างอิงสาธารณะ

1. IANA — Trust Anchors and Rollovers
2. IANA root-anchors.xml และ ลายเซ็น
3. ISC BIND — คู่มือ delv และ options
4. RFC 5011 — Automated Updates of DNSSEC Trust Anchors
5. RFC 8509 — Root Key Trust Anchor Sentinel
6. ISC — Software Support Policy and Version Numbering
7. dnstest.dev — KSK-2024 readiness test