
ระบบ DNS ที่ทำหน้าที่แปลงชื่อโดเมนเป็น IP address นั้นถูกออกแบบมาตั้งแต่ยุคแรกของอินเทอร์เน็ต โดยไม่ได้คำนึงถึงความปลอดภัยมากนัก ส่งผลให้เกิดช่องโหว่ที่เรียกว่า DNS Cache Poisoning และ DNS Hijacking ซึ่ง DNSSEC ถูกพัฒนาขึ้นมาเพื่อแก้ปัญหาเหล่านี้โดยตรง
DNSSEC คืออะไร
DNSSEC (Domain Name System Security Extensions) คือชุดส่วนขยายของโปรโตคอล DNS ที่เพิ่มการตรวจสอบความถูกต้องด้วย Digital Signature ทุก DNS Response ที่ส่งออกมาจะมีลายเซ็นดิจิทัลแนบมาด้วย ทำให้ Resolver สามารถตรวจสอบได้ว่าข้อมูล DNS ที่ได้รับนั้นมาจากแหล่งที่ถูกต้องและไม่ถูกดัดแปลงระหว่างทาง
DNSSEC ไม่ได้เข้ารหัสข้อมูล DNS (DNS ยังคงส่งเป็น plain text) แต่เพิ่มกลไกการ "ยืนยันตัวตน" และ "ตรวจสอบความสมบูรณ์" เพื่อให้แน่ใจว่าคำตอบที่ได้รับมาจาก authoritative name server จริง ไม่ใช่ผู้ไม่หวังดีที่แทรกกลาง
ภัยคุกคามที่ DNSSEC ป้องกัน
DNS Cache Poisoning
ผู้ไม่หวังดีส่ง DNS Response ปลอมเข้าไปในแคชของ Recursive Resolver ทำให้ผู้ใช้ที่ query ชื่อโดเมนนั้นได้รับ IP address ปลอม และถูกพาไปยังเว็บไซต์หลอกลวงโดยไม่รู้ตัว
DNS Hijacking
ผู้ไม่หวังดีเข้าควบคุม DNS Server หรือแก้ไข DNS Records ของโดเมน เพื่อเปลี่ยนเส้นทางทราฟฟิกไปยังเซิร์ฟเวอร์ที่ตัวเองควบคุม ซึ่งอาจนำไปสู่การขโมยข้อมูล login หรือแพร่กระจาย malware
Man-in-the-Middle DNS Attack
ผู้ไม่หวังดีดักจับและแก้ไข DNS Response ระหว่างทางก่อนถึงผู้ใช้ DNSSEC ป้องกันสิ่งนี้ได้เพราะ Signature จะไม่ตรงกันหากมีการแก้ไขใดๆ
DNSSEC ทำงานอย่างไร
DNSSEC ใช้ระบบ Public Key Cryptography สร้าง Chain of Trust ตั้งแต่ Root Zone ลงมาถึงโดเมนของคุณ ประกอบด้วย Record ประเภทใหม่หลายอย่าง:
- DNSKEY — เก็บ Public Key ของ Zone สำหรับตรวจสอบลายเซ็น
- RRSIG — ลายเซ็นดิจิทัลของแต่ละ Resource Record Set
- DS (Delegation Signer) — Hash ของ DNSKEY ที่เก็บใน Parent Zone เพื่อสร้าง Chain of Trust
- NSEC/NSEC3 — ยืนยันว่าโดเมนหรือ Record ที่ถามถึงนั้น "ไม่มีอยู่จริง" (Authenticated Denial of Existence)
กระบวนการตรวจสอบ
- Resolver รับ DNS Response พร้อม RRSIG
- Resolver ดึง DNSKEY ของ Zone นั้นมาตรวจสอบ RRSIG
- Resolver ตรวจสอบ DNSKEY กับ DS Record ใน Parent Zone
- ทำซ้ำขึ้นไปจนถึง Root Zone ที่ Trust Anchor
- ถ้า Chain of Trust สมบูรณ์ → ยืนยันว่า DNS Response ถูกต้อง
Chain of Trust ทำงานอย่างไร — เจาะลึก DS, DNSKEY และ RRSIG
หัวใจของ DNSSEC คือ Chain of Trust ที่เชื่อมความเชื่อถือจาก Root Zone ลงมาทีละชั้นจนถึงโดเมนของคุณ แต่ละชั้น (Zone) จะเซ็นข้อมูลของตัวเองด้วย Private Key และเก็บ Public Key ไว้ใน DNSKEY Record ขณะที่ Parent Zone จะเก็บเพียง Hash ของ DNSKEY (คือ DS Record) เพื่อ "รับรอง" Child Zone อีกที กลไกนี้ทำให้ Resolver ไม่จำเป็นต้องเชื่อใจ Name Server ตัวใดตัวหนึ่งโดยตรง แต่เชื่อใจ "ลายเซ็นที่ไล่ขึ้นไปถึง Root" ซึ่งเป็น Trust Anchor ที่ฝังมากับ Resolver ทุกตัว
ภายในแต่ละ Zone จะมี Key อยู่ 2 ประเภทที่ทำหน้าที่ต่างกัน เพื่อให้การหมุน Key ทำได้ยืดหยุ่นโดยไม่ต้องแจ้ง Parent ทุกครั้ง:
- KSK (Key Signing Key) — Key ที่ใช้เซ็น DNSKEY RRset เท่านั้น เป็น Key ที่ DS Record ใน Parent ชี้มาหา จึงหมุนได้ยากกว่าเพราะต้องอัปเดต DS ที่ Registrar ด้วย
- ZSK (Zone Signing Key) — Key ที่ใช้เซ็น Record อื่นๆ ทั้งหมดใน Zone (A, MX, TXT ฯลฯ) หมุนได้บ่อยและง่ายเพราะไม่กระทบ DS ที่ Parent
เมื่อ Resolver ได้รับคำตอบ มันจะไล่ตรวจสอบลำดับนี้: ใช้ DNSKEY (ZSK) ตรวจ RRSIG ของ Record ที่ขอ → ใช้ KSK ตรวจ DNSKEY RRset → นำ Hash ของ KSK ไปเทียบกับ DS Record ที่ Parent → ตรวจ RRSIG ของ DS ด้วย Key ของ Parent ไล่ขึ้นไปเรื่อยๆ จนถึง Root Zone หากมีจุดใดจุดหนึ่ง Hash หรือ Signature ไม่ตรง Resolver จะตอบกลับเป็น SERVFAIL แทนที่จะส่งคำตอบที่อาจถูกปลอมแปลงให้ผู้ใช้
เกร็ดสำคัญ: DS Record ที่ Parent Zone เป็นเพียง "Hash" ของ DNSKEY ไม่ใช่ Key เต็ม จึงมีขนาดเล็กและปลอดภัยต่อการเผยแพร่ ค่าใน DS ประกอบด้วย 4 ส่วน: Key Tag, Algorithm, Digest Type และ Digest (ค่า Hash) — ทั้งหมดนี้คือสิ่งที่ต้องนำไปใส่ที่ Registrar
วิธีเปิดใช้งาน DNSSEC สำหรับโดเมน
การเปิด DNSSEC ต้องทำ 2 ฝั่งพร้อมกัน คือฝั่ง Authoritative Name Server (ที่เก็บ Zone file) และฝั่ง Registrar (ที่จดโดเมน):
ขั้นตอนที่ 1 — Sign Zone บน Name Server
หากใช้ Name Server ของ AsiaGB หรือ Cloudflare ระบบจะจัดการ Zone Signing ให้อัตโนมัติ คุณเพียงเปิดใช้งาน DNSSEC ในหน้าตั้งค่าของ Name Server แล้วระบบจะสร้าง DNSKEY และ RRSIG ให้
ขั้นตอนที่ 2 — ส่ง DS Record ไปยัง Registrar
หลัง Zone ถูก Sign แล้ว คุณจะได้ DS Record (หรือ Key Tag, Algorithm, Digest Type, Digest) ต้องนำค่าเหล่านี้ไปใส่ในหน้าจัดการโดเมนของ Registrar เพื่อให้ Parent Zone ลิงก์ Chain of Trust เข้ามา DS Record จะมีหน้าตาประมาณนี้:
example.com. 3600 IN DS 12345 13 2 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE...
ความหมายของแต่ละค่าในตารางนี้คือสิ่งที่ฟอร์มของ Registrar ส่วนใหญ่จะให้คุณกรอก:
| ฟิลด์ | ตัวอย่างค่า | ความหมาย |
|---|---|---|
| Key Tag | 12345 | เลขระบุ KSK ที่ใช้ (ดูจาก DNSKEY) |
| Algorithm | 13 (ECDSA P-256) | อัลกอริทึมเข้ารหัส (8=RSA/SHA-256, 13=ECDSA แนะนำ) |
| Digest Type | 2 (SHA-256) | วิธี Hash DNSKEY (ใช้ 2 = SHA-256) |
| Digest | 49FD46E6... | ค่า Hash ของ DNSKEY (KSK) |
สำหรับโดเมน .co.th และ .in.th การส่ง DS Record อาจต้องทำผ่านทีมงานหรือฟอร์มของผู้ดูแล (Registry) ขณะที่โดเมน .com สามารถใส่ DS Record ได้เองจากหน้าจัดการโดเมนของ AsiaGB โดยตรง หลังส่ง DS แล้วจะใช้เวลา Propagate ตาม TTL ของ Parent Zone (มักไม่กี่ชั่วโมง)
ตรวจสอบ DNSSEC ด้วย dig และ DNSViz
หลังเปิด DNSSEC แล้ว ควรตรวจสอบให้แน่ใจว่า Chain of Trust สมบูรณ์ก่อนถือว่าเสร็จ วิธีที่เร็วที่สุดคือใช้คำสั่ง dig บนเครื่องของคุณ:
# ตรวจว่า Zone มี RRSIG (ถูก Sign) แล้วหรือยัง
dig example.com A +dnssec +multiline
# ตรวจ DS Record ที่ Parent Zone เก็บไว้
dig example.com DS +short
# ตรวจ DNSKEY (KSK + ZSK) ของ Zone
dig example.com DNSKEY +short
# ใช้ +cd (checking disabled) เทียบกับปกติ ดูว่า Resolver validate ผ่านไหม
dig example.com A
หากการ Validate สำเร็จ คำตอบจาก dig จะมี Flag ad (Authenticated Data) อยู่ในส่วน HEADER เช่น flags: qr rd ra ad; หากไม่มี ad หรือได้ status: SERVFAIL แสดงว่า Chain of Trust ยังไม่สมบูรณ์ (มักเป็นเพราะ DS ที่ Registrar ยังไม่ Propagate หรือใส่ค่าผิด)
นอกจาก dig แล้ว เครื่องมือแบบ Visual ช่วยให้เห็นภาพรวมได้ชัดกว่า:
- dnsviz.net — วาดแผนผัง Chain of Trust จาก Root ลงมาถึงโดเมน พร้อมไฮไลต์จุดที่ผิดพลาดเป็นสีแดง
- MXToolbox DNSKEY/DNSSEC Checker — ตรวจ DNSKEY และ DS แบบรวดเร็ว
- Verisign DNSSEC Debugger — แสดงสถานะแต่ละขั้นของการ Validate
ข้อควรระวัง: หากมีการเปลี่ยน Name Server โดยไม่อัปเดต DS Record ที่ Registrar ด้วย DNSSEC จะทำให้โดเมนไม่สามารถ Resolve ได้สำหรับ Resolver ที่รองรับ DNSSEC ส่งผลให้เว็บไซต์และอีเมลล่ม ต้องแน่ใจว่าอัปเดต DS Record ทุกครั้งที่เปลี่ยน Name Server
ข้อควรระวัง — Key Rollover และการย้าย DNS ที่ทำให้ DNSSEC พัง
DNSSEC เป็นดาบสองคม: ถ้าตั้งค่าถูกต้องจะปลอดภัยมาก แต่ถ้าจัดการ Key หรือย้าย DNS ผิดวิธี จะทำให้โดเมน "หาย" จากอินเทอร์เน็ตทันทีสำหรับ Resolver ที่ Validate (เช่น Google 8.8.8.8 และ Cloudflare 1.1.1.1) ปัญหาที่พบบ่อยที่สุดมีดังนี้:
1. ย้าย DNS Provider โดยไม่ถอด DS ก่อน
นี่คือสาเหตุอันดับหนึ่งที่ทำให้โดเมนล่ม เมื่อย้ายจาก DNS Provider เดิมไปเจ้าใหม่ Provider ใหม่จะสร้าง KSK ของตัวเอง ทำให้ DS Record เก่าที่ Registrar ไม่ตรงกับ DNSKEY ชุดใหม่ → Chain of Trust ขาด → SERVFAIL วิธีที่ถูกต้องคือ ถอด DS Record ออกที่ Registrar ก่อน รอ TTL หมดอายุ (ปิด DNSSEC ชั่วคราว) แล้วค่อยย้าย DNS เสร็จแล้วจึงเปิด DNSSEC ใหม่และใส่ DS ชุดใหม่
2. Key Rollover (การหมุน Key)
Key ควรถูกหมุนเป็นระยะเพื่อความปลอดภัย แต่ต้องทำแบบ "ทับซ้อน" (overlap) ไม่ใช่เปลี่ยนทันที — สำหรับ ZSK ใช้วิธี Pre-Publish (ประกาศ ZSK ใหม่ล่วงหน้าก่อนเริ่มใช้เซ็น) ส่วน KSK ใช้วิธี Double-Signature (เซ็นด้วยทั้ง KSK เก่าและใหม่พร้อมกัน แล้วอัปเดต DS ที่ Parent ให้มีทั้งสองค่า ก่อนถอดอันเก่า) หากเปลี่ยน Key ทันทีโดยไม่เผื่อเวลา TTL ผู้ใช้ที่ยัง Cache Key เก่าจะ Validate ไม่ผ่าน
3. นาฬิกาเครื่องไม่ตรง (Clock Skew)
RRSIG ทุกตัวมีช่วงเวลา Inception และ Expiration หากเซิร์ฟเวอร์หรือ Resolver มีเวลาเพี้ยน หรือ Signature หมดอายุเพราะลืม Re-sign Zone อัตโนมัติ ลายเซ็นจะถือว่าไม่ถูกต้องทันที ระบบ DNS อัตโนมัติ (เช่นของ AsiaGB หรือ Cloudflare) จะ Re-sign ให้เองก่อนหมดอายุ จึงเลี่ยงปัญหานี้ได้
กฎทอง: "อย่าแตะ DS Record ที่ Registrar เว้นแต่จำเป็น" และ "ปิด DNSSEC ก่อนย้าย DNS ทุกครั้ง" — สองข้อนี้ป้องกันการล่มจาก DNSSEC ได้เกือบทั้งหมด
ข้อดีและข้อจำกัดของ DNSSEC
ข้อดี
- ป้องกัน DNS Cache Poisoning และ Hijacking ได้อย่างมีประสิทธิภาพ
- เพิ่มความน่าเชื่อถือในสายตาของผู้ใช้ที่ใช้ DNS Resolver รองรับ DNSSEC
- เป็นรากฐานของ DANE (DNS-based Authentication of Named Entities) สำหรับ TLS
ข้อจำกัด
- DNSSEC ไม่ได้เข้ารหัส DNS Traffic (ต้องใช้ DNS over HTTPS หรือ DNS over TLS เพิ่มเติม)
- Response ขนาดใหญ่ขึ้นเนื่องจากมี Signature แนบมา
- ต้องบริหารจัดการ Key Rotation อย่างระมัดระวัง
- ไม่ใช่ทุก Registrar ที่รองรับ DNSSEC
คำถามที่พบบ่อยเกี่ยวกับ DNSSEC
DNSSEC เข้ารหัสข้อมูล DNS หรือไม่
ไม่ DNSSEC ไม่ได้เข้ารหัส DNS — คำถามและคำตอบ DNS ยังคงส่งเป็น Plain Text ใครดักจับระหว่างทางก็ยังเห็นว่าคุณ Query โดเมนอะไร DNSSEC ทำเพียง "ยืนยันตัวตน" และ "ตรวจความถูกต้อง" เท่านั้น หากต้องการความเป็นส่วนตัวของ DNS ต้องใช้ DNS over HTTPS (DoH) หรือ DNS over TLS (DoT) เพิ่มเติม ซึ่งทำงานคนละชั้นกับ DNSSEC และใช้ร่วมกันได้
เปิด DNSSEC แล้วเว็บจะช้าลงไหม
แทบไม่มีผลที่ผู้ใช้รู้สึกได้ ผลกระทบเดียวคือ DNS Response มีขนาดใหญ่ขึ้นเล็กน้อยเพราะมี Signature แนบมา และ Resolver ต้องทำการ Validate เพิ่ม ซึ่งใช้เวลาระดับมิลลิวินาที สำหรับเว็บไซต์ทั่วไปถือว่าไม่กระทบความเร็วการโหลดหน้าเว็บ
ถ้า Registrar ไม่รองรับ DNSSEC ต้องทำอย่างไร
หาก Registrar ปัจจุบันไม่มีช่องให้ใส่ DS Record คุณจะเปิด DNSSEC ไม่ได้แม้ DNS Provider จะ Sign Zone ให้แล้ว ทางออกคือย้ายโดเมนไปยัง Registrar ที่รองรับ เช่น AsiaGB ที่รองรับการตั้งค่า DS Record สำหรับ .com .co.th และ .in.th
โดเมนที่เปิด DNSSEC แล้ว ย้ายโฮสต์/เว็บเซิร์ฟเวอร์ได้ปกติไหม
ได้ปกติ การย้าย "เว็บเซิร์ฟเวอร์" (เปลี่ยน A/AAAA Record ชี้ไป IP ใหม่) ไม่กระทบ DNSSEC ตราบใดที่ยังใช้ DNS Provider เดิม เพราะ Record ใหม่จะถูก Sign ด้วย Key ชุดเดิมอัตโนมัติ DNSSEC จะมีปัญหาก็ต่อเมื่อคุณเปลี่ยน "DNS Provider / Name Server" โดยไม่อัปเดต DS เท่านั้น
จดโดเมนที่รองรับ DNSSEC
AsiaGB รองรับการตั้งค่า DS Record สำหรับโดเมน .com .co.th และ .in.th พร้อม DNS Management ครบครัน จดโดเมน .com เพียง 500 บาท/ปี
จดโดเมนที่ AsiaGB