DNSSEC กับ DoH/DoT ต่างกันอย่างไร แต่ละตัวป้องกัน DNS เรื่องไหน

เกือบทุก connection เริ่มต้นด้วยการ lookup DNS แต่ DNS มักเป็นสิ่งสุดท้ายที่ทีมนึกถึงตอนวางระบบ monitor แล้วยังมีชื่อย่อเต็มไปหมด ทั้ง DNSSEC, DoT, DoH, DoQ, protective DNS ซึ่งคนสับสนกันบ่อย ส่วนหนึ่งเพราะฟังดูเหมือนทำงานเดียวกัน ความจริงไม่ใช่ แต่ละตัวแก้ปัญหาคนละเรื่อง และการรู้ว่าตัวไหนแก้อะไร จะบอกเราได้ว่าจริง ๆ แล้วเราป้องกันอะไรอยู่บ้างครับ

โพสต์นี้เรียงเป็นคำถามที่ผมมักถามตัวเอง (และถูกถาม) เกี่ยวกับ DNS ทุกคำตอบมีลิงก์ไปยังมาตรฐานหรือแนวทางต้นทาง เผื่อใครอยากอ่านต่อครับ

Q: DNS แบบเดิม ๆ มีอะไรผิดพลาดได้บ้าง?

DNS แบบดั้งเดิมออกแบบมาในยุคที่อินเทอร์เน็ตเป็นมิตรกว่านี้ query ปกติวิ่งผ่าน UDP หรือ TCP ไปที่ server port 53 โดยไม่เข้ารหัสและไม่มีลายเซ็น สิ่งเดียวที่ผูกคำตอบเข้ากับคำถามคือ identifier ขนาด 16 bit ที่ฝั่งผู้ถามเป็นคนสุ่ม (ในทางปฏิบัติมี source port ช่วยอีกแรง) การออกแบบแบบนี้ทิ้งปัญหาใหญ่ไว้สี่ข้อครับ

• Spoofing และ cache poisoning ถ้าผู้โจมตีเดา ID และ port ได้ แล้วส่งคำตอบปลอมไปถึงก่อนคำตอบจริง caching resolver อาจเก็บคำตอบปลอมไว้ แล้วแจกให้ทุกคนที่ถามหลังจากนั้น บันทึกของ CERT/CC ปี พ.ศ. 2551 VU#800113 อธิบายว่า resolver ที่ใช้ transaction ID อ่อนหรือใช้ source port คงที่เสี่ยงกับการโจมตีแบบนี้ การสุ่ม source port เพิ่มความสุ่มให้ผู้โจมตีต้องเดาอีกราว 16 bit ส่วน vendor statement ของ ISC ที่อ้างในบันทึกเดียวกันระบุว่า DNSSEC เป็นทางเดียวที่แก้การโจมตีแบบนี้ได้เต็มที่
• Snooping ใครก็ตามที่อยู่บนเส้นทางอ่านชื่อโดเมนที่เรา lookup ได้ เป็นปัญหาความเป็นส่วนตัวของผู้ใช้ และเป็นข้อมูล recon ชั้นดีสำหรับผู้โจมตี
• Tampering ระหว่างทาง อุปกรณ์ตรงกลางแก้คำตอบได้ บางครั้งตั้งใจทำเพื่อ filtering บางครั้งเป็นผู้โจมตี
• ใช้เป็นช่องทางลับ DNS ได้รับอนุญาตให้ออกจากแทบทุกเครือข่าย ผู้โจมตีจึงใช้มันขนข้อมูล รายละเอียดอยู่ด้านล่าง

วิธีแยกให้ชัด: poisoning กับ tampering เป็นปัญหา integrity, snooping เป็นปัญหา confidentiality ส่วน tunnelling เป็นปัญหา detection คำตอบถัดไปแต่ละข้อจะว่าด้วยแต่ละเรื่องครับ

Q: DNSSEC ป้องกันอะไร และไม่ได้ป้องกันอะไร?

DNSSEC เพิ่มลายเซ็นให้ข้อมูล DNS ตาม RFC 4033 มันให้สามอย่าง คือ data origin authentication, data integrity และ authenticated denial of existence (พิสูจน์ได้ว่าชื่อนั้นไม่มีอยู่จริง) โดยเพิ่ม record ใหม่สี่ชนิด ได้แก่ RRSIG (ลายเซ็น), DNSKEY (public key), DS (hash ของ key ของ zone ลูก ซึ่งเผยแพร่ใน zone แม่) และ NSEC (สำหรับคำตอบ "ไม่มีชื่อนี้" ที่มีลายเซ็น)

ความน่าเชื่อถือต่อกันเป็นโซ่ resolver เริ่มจาก trust anchor ที่มีอยู่แล้ว ซึ่งส่วนใหญ่คือ key ของ root zone แม่รับรอง key ของ zone ลูกด้วย DS record และแต่ละ zone เซ็น record ของตัวเอง RFC 4033 เขียนโซ่นี้ไว้ว่า DNSKEY -> [DS -> DNSKEY]* -> RRset

                                                                
                                            ┌──────────────────┐
                                           ·│●ROOT .           │
                                         ·· └──────────────────┘
                                       ··                       
              ┌────────────────┐     ··                         
              │    RESOLVER    │   ··                           
┌───────┐     │                │ ··         ┌──────────────────┐
│  STUB │?────│ example.     NS│············│●TLD .example     │
└───────┘     │ org.         NS│ ··         └──────────────────┘
              │                │   ··                           
              └────────────────┘     ··                         
                                       ··                       
                                         ·· ┌──────────────────┐
                                           ·│●AUTH site.example│
                                            └──────────────────┘
                                                                
                                                                
                                                                

ส่วนที่คนสับสนคือสิ่งที่ DNSSEC ไม่ได้ทำ RFC 4033 เขียนไว้ตรง ๆ ว่า DNSSEC ไม่ได้ออกแบบมาเพื่อ confidentiality และ ไม่ได้ป้องกัน denial of service คำตอบที่มีลายเซ็นทุกอันยังวิ่งผ่านเครือข่ายเป็น clear text อยู่ดี NIST SP 800-81r3 (มีนาคม พ.ศ. 2569) ก็ยืนยันว่า DNSSEC ป้องกัน integrity แต่ไม่ได้ให้ confidentiality หรือ privacy ใด ๆ

ยังมีช่องโหว่อีกจุดที่สำคัญในองค์กร คือ hop สุดท้าย โน้ตบุ๊กส่วนใหญ่ใช้ stub resolver ที่ไม่ validate เอง และ RFC 4033 ชี้ว่า stub แบบนี้ต้องฝากชีวิตไว้กับ recursive resolver และเส้นทางไปถึงมัน resolver ตั้ง bit AD (Authenticated Data) เพื่อบอกว่า "ฉัน validate แล้ว" ได้ แต่ stub จะเชื่อ bit นี้ได้ก็ต่อเมื่อเชื่อทั้งตัว resolver และเส้นทาง stub ที่ไม่เชื่อทั้งสองอย่างตั้ง bit CD แล้วตรวจลายเซ็นเองได้ครับ

สรุปบรรทัดเดียว: DNSSEC ตอบคำถามว่า "record นี้ใช่ที่เจ้าของ zone เผยแพร่หรือเปล่า" แต่ไม่ได้ตอบว่า "ใครเห็น query ของเราบ้าง"

Q: DoT กับ DoH ต่างกันอย่างไร เข้ารหัสอะไร ใช้ port ไหน และทำไมทีม security ถึงรู้สึกสองจิตสองใจ?

ทั้งคู่ป้องกัน hop ระหว่าง client (stub) กับ recursive resolver จากการดักฟังและการแก้ไข ต่างกันที่วิธีเดินทาง

รายละเอียดจาก RFC ที่ควรรู้:

• DoT server ต้อง listen ที่ TCP 853 เป็นค่าตั้งต้น จะใช้ port อื่นก็ได้ถ้าตกลงกันทั้งสองฝั่ง แต่ RFC 7858 ระบุว่า ห้ามเป็น port 53 RFC นี้ครอบคลุมเฉพาะ traffic จาก stub ไป recursive และยอมรับว่าขนาดและจังหวะเวลาของ message ยังรั่วข้อมูลให้ traffic analysis ได้
• profile แบบ "opportunistic" ของ DoT ให้ privacy เฉพาะตอนที่ไม่มี active attacker บนเส้นทาง ส่วน profile ที่เข้มกว่าจะ pin key ของ server
• DoH ส่ง DNS message ปกติด้วย media type application/dns-message จะใส่ใน body ของ POST หรือ encode เป็น base64url ใน parameter dns ของ GET ก็ได้ (RFC 8484) RFC ระบุเป้าหมายสองข้อ คือกันไม่ให้อุปกรณ์บนเส้นทางเข้ามายุ่งกับ DNS และให้ web application ใช้ DNS ผ่าน browser API ได้อย่างปลอดภัย

แล้วทำไมถึงรู้สึกสองจิตสองใจ? เพราะ "อุปกรณ์บนเส้นทาง" ที่ DoH ออกแบบมาให้หลบ อาจเป็น security stack ขององค์กรเราเอง ถ้า browser หรือแอปส่ง DoH ตรงไปที่ public resolver ผ่าน 443 resolver ขององค์กรจะไม่เห็น query นั้นเลย ทั้ง filtering, logging และ alerting ถูกข้ามไปโดยไม่มีใครรู้ตัว NIST SP 800-81r3 พูดถึงเรื่องนี้ตรง ๆ ว่าองค์กรอาจต้องตั้งค่าแอปอย่าง browser เพื่อไม่ให้ข้าม local resolver ที่เป็นจุดควบคุมและจุดเก็บ log

ทางแก้ไม่ใช่การต่อต้าน encryption แต่คือ เป็นเจ้าของ endpoint ที่เข้ารหัสเอง คือรัน (หรือใช้บริการ) resolver ที่รองรับ DoT หรือ DoH ชี้อุปกรณ์ที่องค์กรดูแลไปที่มันผ่าน policy แล้ว block resolver อื่นที่ขอบเครือข่าย Firefox ยังมีการเช็ก canary domain ด้วย: มันจะ lookup use-application-dns.net ผ่าน resolver ของระบบปฏิบัติการ ถ้าได้คำตอบเป็น error เช่น NXDOMAIN หรือ SERVFAIL หรือไม่มี A หรือ AAAA record เลย Firefox จะถือเป็นสัญญาณให้ปิด DoH กรณีนี้ใช้เฉพาะเมื่อ DoH เปิดไว้เป็นค่าตั้งต้น ไม่ใช่เมื่อผู้ใช้เปิดเอง (Mozilla) ให้มองสิ่งนี้เป็นสัญญาณที่ช่วยได้ ไม่ใช่ control เพราะผู้ใช้ที่เปิด DoH เองไม่ได้รับผลจากมันครับ

Q: ผู้โจมตีใช้ DNS เป็นช่องทางได้อย่างไร?

MITRE ATT&CK เรียกเทคนิคนี้ว่า T1071.004, Application Layer Protocol: DNS แนวคิดเรียบง่าย malware encode ข้อมูลลงในชื่อที่มัน lookup เช่น <encoded-chunk>.t.example query วิ่งผ่าน resolver ของเราตามปกติ ไปจนถึง authoritative server ของผู้โจมตีที่ดูแล t.example server นั้น decode label แล้วซ่อนคำตอบกลับมาในคำตอบ DNS ซึ่งมักเป็น TXT หรือ A record

┌──────┐                   │                    ┌──────────────┐
│ HOST │───────────────────│────────────────────│ NS t.example │
└──────┘                   │                    └──────────────┘
                           ●                                    
                      resolver                                  
                                                                
query log (TXT)                                                 
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
reassembled: ▌                                                  
                                                                

MITRE อธิบายเหตุผลที่วิธีนี้ได้ผล: DNS พบได้ทั่วไปมาก บางเครือข่ายอนุญาต DNS ก่อนอุปกรณ์จะ authenticate เสร็จ ใน packet มี field และ header ให้ซ่อนข้อมูลมากมาย และ traffic ก็กลืนไปกับ lookup ปกติ ข้อจำกัดขนาดใน RFC 1035 (label ละไม่เกิน 63 octet ชื่อเต็มไม่เกิน 255 octet) ทำให้แต่ละ query ขนข้อมูลได้แค่ชิ้นเล็ก ๆ tunnel จึงปรากฏเป็น query จำนวนมาก ไม่ใช่ไม่กี่อันที่ใหญ่ ตัวอย่างใน ATT&CK มีทั้ง Cobalt Strike ที่ห่อ C2 protocol ไว้ใน DNS ได้ และ SUNBURST ที่ใช้ DNS ทำ C2 โดยเลียนแบบ traffic ของ SolarWinds API

pattern ที่แนวทาง detection ของ MITRE ชี้ไว้ ก็คือสิ่งที่เห็นในแอนิเมชันครับ

• subdomain ยาวและดูเหมือนถูก encode
• query ปริมาณสูงผิดปกติจาก client เครื่องเดียว
• DNS query จาก process ที่ปกติไม่ query (script, interpreter)
• query ไปยัง infrastructure ที่รู้ว่าอันตราย

mitigation ที่ MITRE ระบุก็ใช้งานได้จริง: filter DNS request ไปยังโดเมนที่ไม่รู้จัก ไม่น่าเชื่อถือ หรือรู้ว่าอันตราย และ resolve DNS ผ่าน server ภายในหรือ proxy ขององค์กร ซึ่ง MITRE ระบุว่าอาจขัดขวางการซ่อนข้อมูลใน DNS packet ได้ (M1037) รวมถึงใช้ network IPS signature สำหรับ malware เฉพาะตัว (M1031)

Q: Protective DNS คืออะไร และช่วยได้อย่างไร?

Protective DNS คือ resolver ที่ใช้ security policy กับการ lookup โดยตรง NIST SP 800-81r3 อธิบายว่ามันจะไม่ยอม resolve ชื่อที่รู้ว่าใช้ทำ phishing หรือเป็น command and control ของ malware โดยมักตอบเป็น NXDOMAIN แทน และ log ความพยายามนั้นไว้เป็นสัญญาณว่าอาจมีเครื่องติดเชื้อ สร้างได้จาก DNS firewall หรือ Response Policy Zone (RPZ) บน server ขององค์กรเอง จากบริการ secure resolver บน cloud หรือผสมกัน NIST ยังบอกว่า protective DNS ที่ดีควรวิเคราะห์ทุก record type รวม MX, SOA และ TXT ไม่ใช่แค่ A record

ตำแหน่งที่วางมีผลต่อสิ่งที่เราเห็น NIST ชี้ว่า RPZ ที่วางใกล้ client ทำให้ระบุได้ง่ายว่าเครื่องไหนถาม ส่วนที่วางใกล้อินเทอร์เน็ตจะรวมศูนย์ได้ดีกว่าแต่เสีย visibility ระดับ client ไปบ้าง บริการ cloud scale ได้ดี แต่แลกกับ confidentiality บางส่วนและระบุต้นทาง query ได้ยากขึ้น

รัฐบาลสหรัฐฯ ใช้แนวทางนี้ในระดับประเทศ Protective DNS Resolver ของ CISA เปิดใช้ในปี พ.ศ. 2565 แทน E3A บริการนี้ตอบสนองข้อกำหนดของรัฐสภาสำหรับหน่วยงานฝ่ายบริหารพลเรือนของรัฐบาลกลาง และเปิดให้องค์กร critical infrastructure ใช้ได้แบบจำกัดผ่านโครงการนำร่อง เมื่อ query ตรงกับ threat intelligence indicator บริการจะ block, redirect หรือ sinkhole คำตอบได้ แล้วแจ้งเตือนทั้งหน่วยงานและ CISA

แต่ protective DNS ก็ไม่ได้จับได้ทุกอย่าง มันเห็นเฉพาะ query ที่มาถึงมันจริง ๆ ซึ่งวนกลับไปที่ปัญหา DoH bypass และเป็นเหตุผลที่คำตอบข้อถัดไปสำคัญครับ

Q: ควร log และตั้ง alert อะไร ทั้งที่ resolver และที่ firewall?

เริ่มที่ resolver เพราะมันรู้ชื่อโดเมน แนวทางของ NIST ใน SP 800-81r3 ค่อนข้างเป็นรูปธรรมครับ

• เก็บ DNS log ทั้งปัจจุบัน และ ย้อนหลัง แล้ว correlate กับ log อื่น
• log ทุกอย่างมีต้นทุนสูง ใช้ format ที่ประหยัด (เช่น dnstap) หรือ log แบบเลือกเก็บได้ แต่ ต้อง log query และ response ของโดเมนที่ protective DNS จัดว่าอันตรายเสมอ
• ตัดรายการของโดเมนที่รู้ว่าปลอดภัย (เช่น zone ที่องค์กรดูแลเองและมีจุด monitor อื่นอยู่แล้ว) ออกก่อนส่งเข้า SIEM เพื่อลดต้นทุนได้ แต่ควรเก็บ log ฉบับเต็มไว้ทำ forensics
• เก็บ ประวัติ DHCP lease เพื่อให้ไล่ IP ใน DNS log กลับไปหาอุปกรณ์ ณ เวลานั้นได้
• ส่ง log ของ protective DNS เข้า SIEM หรือ log platform เพื่อให้ alert มาถึงเร็ว

ยกตัวอย่าง Windows Server: DNS analytic log ไม่ได้เปิดเป็นค่าตั้งต้น เมื่อเปิดแล้ว event 257 จะบันทึกทุก response ที่สำเร็จ พร้อม field อย่าง destination, QNAME, QTYPE, RCODE และ AD flag Microsoft ระบุว่าผลต่อ performance จะเห็นเฉพาะตอน query rate สูง คือราว 5% ที่ 100,000 queries ต่อวินาที และไม่เห็นผลชัดเจนที่ 50,000 หรือต่ำกว่า (Microsoft Learn)

ที่ firewall สิ่งที่มีประโยชน์ที่สุดคือ policy ที่ทำให้ log ของ resolver ครบถ้วน:

inside                        ║                         internet
┌──────────┐                  ║                 ┌──────────────┐
│ RESOLVER●│─[dns]────────────║─────────────────│  public DNS  │
└──────────┘                  ║                 └──────────────┘
                              ║                                 
                              ║                                 
                              ║   edge rules                    
                              ║   1 allow RESOLVER  53,853      
                              ║   2 drop  any       53,853 log  
┌──────────┐                  ║                                 
│   HOST   │──────────────────║                                 
└──────────┘                  ║                                 
                              ║                                 
                            edge FW                             
log: ▌                                                          
                                                                

1. อนุญาต DNS ขาออก (UDP/TCP 53), DoT (TCP 853) และ DoQ (UDP 853) เฉพาะจาก resolver ขององค์กร ส่วนจากเครื่องอื่นให้ drop และ log
2. มอง DoH ไปยัง resolver ที่เราไม่ได้ดูแลเป็นเรื่องของ policy block DoH endpoint สาธารณะที่รู้จักกันดีเท่าที่ platform ระบุได้ และบังคับใช้ resolver ขององค์กรบนอุปกรณ์ที่ดูแลอยู่
3. alert เมื่อเครื่องภายในคุย DNS กับอินเทอร์เน็ตโดยตรง ถ้าไม่ใช่ตั้งค่าผิด ก็คือมีบางอย่างตั้งใจเลี่ยง resolver ของเราครับ

แล้วก็มี alert ที่มักคุ้มค่าครับ

• NXDOMAIN พุ่งขึ้นจากเครื่องเดียว (โดเมนที่ถูกสุ่มสร้าง หรือแอปที่พัง)
• subdomain ไม่ซ้ำจำนวนมากใต้ parent domain เดียว โดยเฉพาะถ้า label ยาวหรือเป็น TXT query
• lookup โดเมนที่ protective DNS ติดธงไว้
• DNSSEC validation ล้มเหลวกับ zone ที่เราพึ่งพา (ถ้าไม่ใช่การโจมตี ก็คือลายเซ็นพังที่กำลังจะกลายเป็น outage)

สรุปสั้น ๆ

ไม่มีตัวไหนแทนกันได้ DNSSEC ที่ไม่มี encryption ยังรั่ว encryption ที่ไม่มี validation ยังส่งคำตอบปลอมมาได้ และทั้งสองอย่างไม่ช่วยอะไรถ้า log ของเราไม่เคยเห็น query นั้นเลยครับ

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

• RFC 1035: Domain Names, Implementation and Specification (IETF)
• CERT/CC VU#800113: Multiple DNS implementations vulnerable to cache poisoning
• RFC 4033: DNS Security Introduction and Requirements (IETF)
• RFC 7858: DNS over Transport Layer Security (IETF)
• RFC 8484: DNS Queries over HTTPS (IETF)
• RFC 9250: DNS over Dedicated QUIC Connections (IETF)
• RFC 9156: DNS Query Name Minimisation to Improve Privacy (IETF)
• NIST SP 800-81r3: Secure Domain Name System (DNS) Deployment Guide (หน้าเอกสาร)
• NIST SP 800-81r3 (PDF)
• MITRE ATT&CK T1071.004: Application Layer Protocol: DNS
• CISA: Protective Domain Name System (DNS) Resolver
• Mozilla: Canary domain use-application-dns.net
• Microsoft Learn: DNS logging and diagnostics in Windows Server