DNS ความเป็นส่วนตัวคืออะไร และทำไม ISP ยังมองเห็นเรา
DNS ความเป็นส่วนตัวคือแนวทางการตั้งค่าและเข้ารหัสการค้นหาโดเมน (เช่น DoH/DoT) เพื่อไม่ให้บุคคลที่สามมองเห็นชื่อโฮสต์ที่เราค้นหาผ่านเครือข่าย โดยหวังลดการเก็บข้อมูลการท่องเว็บของผู้ให้บริการอินเทอร์เน็ตและบริการภายนอก แต่แม้จะเข้ารหัสระดับ DNS แล้ว การเชื่อมต่อเว็บสมัยใหม่ยังเปิดเผยข้อมูลอื่นระหว่างขั้นตอน TLS handshake ทำให้ ISP ยังคงอ่านค่าเมตาดาตาบางอย่างและสร้างภาพรวมพฤติกรรมการใช้งานอินเทอร์เน็ตของเราได้อยู่ดี.
ปัญหาหลักคือ DNS แบบดั้งเดิมส่งคำถามออกไปแบบไม่เข้ารหัส ทำให้เมื่อหลุดออกจากเครือข่ายบ้านแล้ว ISP หรือใครก็ตามบนเส้นทางสามารถเห็นทุกโฮสต์ที่เราค้นหาได้. DoH และ DoT ถูกออกแบบมาเพื่อแก้จุดนี้ โดยลบข้อความ DNS แบบไม่เข้ารหัสออกจากสมการ. ทว่าหลายคนตีความเกินขอบเขตว่ามันคือ “กำแพงสุดท้าย” ของความปลอดภัย ISP ทั้งที่ความจริงมันไม่เคยถูกออกแบบมาเพื่อซ่อนการท่องเว็บทั้งหมด.
เข้ารหัส DNS บ้านช่วยอะไรได้บ้าง และข้อจำกัดที่ต้องยอมรับ
เมื่อใช้บริการเข้ารหัส DNS บ้านอย่าง DNS-over-HTTPS เราเตอร์หรือเซิร์ฟเวอร์ DNS ภายในบ้านจะส่งคำถามไปยังตัวแก้ DNS ผ่านช่องทาง HTTPS ที่เข้ารหัสแล้ว. นั่นหมายความว่าใครดักฟังระหว่างทางจะไม่เห็นชื่อโฮสต์ที่เราค้นหาผ่าน DNS อีกต่อไป และผู้เขียนหนึ่งรายสรุปไว้อย่างชัดเจนว่า “Encrypted DNS was doing exactly what it was supposed to do — removing plaintext DNS queries from the equation. It was never meant to provide complete browsing privacy.”. ประโยคนี้ตอกย้ำว่าการคาดหวังให้ DoH/DoT ปิดบังทุกอย่างนั้นผิดจุดอุปกรณ์.
ช่องโหว่สำคัญอยู่ที่หนึ่งฟิลด์ใน TLS handshake ที่ไม่มีใครเข้ารหัสโดยค่าเริ่มต้น นั่นคือ SNI หรือชื่อโดเมนปลายทางที่เบราว์เซอร์ประกาศให้เซิร์ฟเวอร์รู้เมื่อเริ่มเชื่อมต่อ HTTPS. ต่อให้ DNS เข้ารหัสตั้งแต่ต้นจนจบ โฮสต์ที่ถูกแก้แล้วก็ยังโผล่มาใน handshake ทำให้ใครอย่าง ISP สามารถเห็นโดเมนปลายทางเพียงแค่สังเกตการเชื่อมต่อ. นี่คือเหตุผลว่าทำไมแค่เปลี่ยนเป็น DNS เข้ารหัสบนเราเตอร์ ไม่ได้เท่ากับเราหลุดพ้นจากการเฝ้าดูของผู้ให้บริการอินเทอร์เน็ต.
เลือกตัวแก้ DNS ให้เหมาะ: ความเป็นส่วนตัว vs ความเร็ว
การตั้งค่า DNS เราเตอร์ให้ดีไม่ใช่แค่เรื่องเข้ารหัส แต่คือการเลือกตัวแก้ DNS ที่บาลานซ์ระหว่าง DNS ความเป็นส่วนตัวและประสิทธิภาพของเครือข่ายบ้านด้วย. มีกรณีศึกษาที่นำ NextDNS มาทดสอบเทียบกับ Control D ผ่าน DNS-over-HTTPS บนเครื่อง Debian VM เดียวกัน ใช้รายการโดเมนยอดนิยม 1,000 รายการจาก Tranco และส่งคำถามซ้ำ ๆ ภายใต้เงื่อนไขเดียวกัน. ผลคือ Control D ตอบกลับได้เร็วกว่า แต่ชนะด้วยปัญหาด้านความเชื่อถือที่ผู้ทดสอบ “ไม่แน่ใจว่ามองข้ามได้หรือไม่” ขณะที่ NextDNS ดูจะนิ่งกว่าในชุดทดสอบเดียวกัน.
| Spec | NextDNS | Control D |
|---|---|---|
| สมรรถนะโดยรวมบนเครือข่ายที่ทดสอบ | มีความเร็วดีและมีความเชื่อถือสูงกว่า | ตอบกลับเร็วที่สุดบนเครือข่ายทดสอบ แต่มีปัญหาความเชื่อถือ |
| ฟีเจอร์ด้าน DNS ความเป็นส่วนตัว | มีตัวกรองโฆษณา ตัวติดตาม มัลแวร์ และฟิชชิง พร้อมการตั้งค่าละเอียด | มีโหมดส่วนตัวและตัวกรองคล้ายกัน แต่ต้องชั่งน้ำหนักกับประเด็นเสถียรภาพ |
| ความเหมาะสมกับเครือข่ายบ้าน | ดีสำหรับผู้ใช้ที่ต้องการทั้งเข้ารหัส DNS บ้านและตัวกรองเนื้อหาแบบละเอียด | ดีสำหรับผู้ใช้ที่ให้ความสำคัญกับความเร็ว DNS เป็นหลักและยอมรับความเสี่ยงบางส่วน |
เสริมเกราะด้วย DNS แบบโฮสต์เองและกฎบล็อกสแกม
ถ้าคุณต้องการควบคุม DNS ความเป็นส่วนตัวขั้นสูง การโฮสต์ตัวแก้ DNS เองในบ้านคือแนวทางที่น่าสนใจ. มีการเล่าประสบการณ์เดินทางผ่าน Pi-hole เพื่อบล็อกโฆษณาทั้งเครือข่าย จากนั้นเพิ่ม dnscrypt-proxy เพื่อใช้ DNS-over-HTTPS ก่อนจะย้ายไปใช้ AdGuard Home เพื่อลดความซับซ้อน และทดลอง Technitium เพื่อ resolution แบบ recursive แบบเนทีฟ แล้วสุดท้ายกลับมา AdGuard Home พร้อม Unbound หรือ Quad9 DoH. รูปแบบนี้สะท้อนว่าผู้ใช้จริงสามารถผสมบริการ self-hosted กับตัวแก้ DNS ภายนอกที่เข้ารหัส เพื่อสร้างสแต็ก DNS บ้านที่สอดคล้องกับความต้องการของตัวเองมากกว่าการใช้ค่าเริ่มต้นของเราเตอร์.
บนฝั่งบริการคลาวด์ NextDNS มีฟีเจอร์ด้านความปลอดภัย ISP ที่ช่วยลดโอกาสเจอสแกมอย่างน่าสนใจ. ภายใต้แท็บ Security มีตัวเลือก “Block Newly Registered Domains” ซึ่งเมื่อเปิดแล้วจะบล็อกทุกโดเมนที่จดทะเบียนอายุต่ำกว่า 30 วัน. ฟีเจอร์นี้ทำงานตามข้อเท็จจริงว่าซอฟต์แวร์ฟิชชิงส่วนใหญ่ใช้โดเมนใหม่เอี่ยมที่ยังไม่ติดลิสต์แบล็กลิสต์ เพื่อหลบการกรอง. การบล็อกโดเมนใหม่ทั้งหมดตั้งแต่ระดับ DNS ทำให้ลิงก์ฟิชชิงจำนวนมากถูกตัดวงจรก่อนหน้าเว็บจะโหลดเลย. นี่คือตัวอย่างชัด ๆ ว่ากฎ DNS ที่ตั้งใจออกแบบเพื่อป้องกันสแกมมีพลังมากกว่าการพึ่งพารายชื่อโดเมนที่ “รู้จักแล้ว” เพียงอย่างเดียว.
จาก ECH ถึงการตั้งค่า DNS เราเตอร์อย่างมีสติ
เมื่อรู้ข้อจำกัดของเข้ารหัส DNS บ้านแล้ว คำถามต่อมาคือเราปิดช่องว่าง TLS handshake อย่างไร. คำตอบหนึ่งคือ Encrypted Client Hello (ECH) ซึ่งเดิมเรียก Encrypted SNI ถูกออกแบบมาเพื่อเข้ารหัสส่วน SNI ใน Client Hello. ด้านไคลเอนต์ค่อนข้างพร้อม เพราะเบราว์เซอร์ส่วนใหญ่ไม่ว่าจะเป็น Safari, Firefox หรือ Chrome (รวม Chromium) รองรับโปรโตคอลนี้แล้ว. ปัญหาคือฝั่งเซิร์ฟเวอร์และโครงสร้างพื้นฐานยังตามไม่ทัน มีการค้นพบว่าในช่วงหนึ่งมีเพียงผู้ให้บริการรายใหญ่รายเดียวที่ใช้งาน ECH ในระดับจริงจัง. สุดท้ายสถานะของ ECH กลายเป็นว่าเบราว์เซอร์รองรับเป็นวงกว้าง แต่ DNS provider, CDN/web server และตัวเว็บไซต์เองต้องร่วมกันรองรับด้วยจึงจะปิดช่องว่างได้เต็มที่.
บทสรุปคือ การตั้งค่า DNS เราเตอร์ไม่ควรถูกมองว่าเป็นเวทมนตร์ที่ทำให้เราล่องหนต่อความปลอดภัย ISP. แทนที่จะไล่ฟีเจอร์เข้ารหัสแบบไม่คิด ให้เริ่มจากการรู้ว่า ISP ยังเห็นแพทเทิร์นการเชื่อมต่อ แม้จะไม่เห็นคำถาม DNS โดยตรง. จากนั้นเลือกตัวแก้ DNS ที่บาลานซ์ระหว่างความเร็วกับความเชื่อถือ เช่นชั่งใจระหว่าง NextDNS ที่นิ่งกว่าและ Control D ที่เร็วกว่า. เสริมด้วย self-hosted DNS และกฎบล็อกสแกมอย่าง Block Newly Registered Domains ของ NextDNS. และท้ายที่สุด เปิดใช้ ECH บนเบราว์เซอร์และเลือก DNS provider ที่รองรับ เมื่อมีตัวเลือก. การผสมทุกชั้นนี้ต่างหากคือแนวทางป้องกันที่ซื่อสัตย์ต่อความจริงของเทคโนโลยี มากกว่าความเชื่อแบบ “เข้ารหัสแล้วปลอดภัยแน่”.
