DNS over HTTPS: คืออะไร และช่วยปกป้องการสืบค้นข้อมูลของคุณได้อย่างไร

คู่มืออัลฟ่า » Informática » DNS over HTTPS: คืออะไร และช่วยปกป้องการสืบค้นข้อมูลของคุณได้อย่างไร

เมื่อคุณพิมพ์ที่อยู่เว็บ จะมีส่วนประกอบที่ทำงานอยู่เบื้องหลังเพื่อให้แน่ใจว่าคุณเข้าถึงเว็บไซต์ที่ถูกต้อง นั่นคือ ระบบชื่อโดเมน (DNS) DNS จะแปลงชื่อที่จำง่ายให้เป็นที่อยู่ IPที่คอมพิวเตอร์เข้าใจได้ มันสะดวกสบายก็จริง แต่เป็นเวลาหลายปีที่มันทำงานโดยมีช่องโหว่ที่สำคัญ นั่นคือ การสอบถามเหล่านี้เดินทางโดยไม่มีการเข้ารหัส นี่คือเหตุผลที่ DNS over HTTPS หรือที่รู้จักกันในชื่อ DoH จึงได้รับความนิยมอย่างมาก เพราะเป็นชั้นการป้องกันเพิ่มเติมที่ทำให้ผู้ให้บริการอินเทอร์เน็ตของคุณติดตามได้ยากขึ้นว่าคุณเยี่ยมชมโดเมนใดบ้าง

สิ่งสำคัญคือต้องชี้แจงให้ชัดเจนตั้งแต่เริ่มต้น: DoH ช่วยเพิ่มความเป็นส่วนตัวของการสืบค้น DNS แต่ไม่ใช่ VPN และไม่ได้เปลี่ยนการเชื่อมต่อทั้งหมดของคุณให้เป็นอุโมงค์ลับในบทความนี้ เราจะสำรวจว่ามันคืออะไร ทำไมมันถึงได้รับความนิยม วิธีเปิดใช้งานใน Chrome, Edge และ Firefox ข้อดีและข้อเสีย ความแตกต่างจาก DNS over TLS และ VPN และขอบเขตของข้อจำกัดทางเทคนิคและการใช้งานจริง

DNS คืออะไร และเหตุใดระบบแบบดั้งเดิมจึงล้มเหลว?

เซิร์ฟเวอร์ DNS เป็นส่วนประกอบหนึ่งที่แทบไม่มีใครสนใจ แต่กลับเป็นหัวใจสำคัญของการท่องเว็บออนไลน์หน้าที่ของมันคือการเชื่อมโยงชื่อโดเมนกับที่อยู่ IP ของเซิร์ฟเวอร์ที่เกี่ยวข้องเมื่อคุณเข้าชมเว็บไซต์ คอมพิวเตอร์ของคุณไม่เข้าใจตัวอักษร มันต้องการที่อยู่ IP เพื่อรู้ว่าต้องเชื่อมต่อกับเครื่องใด เราเตอร์หลายตัวมาพร้อมกับเซิร์ฟเวอร์ DNS ที่ตั้งค่าไว้แล้วโดยผู้ให้บริการอินเทอร์เน็ต ซึ่งทำให้กระบวนการสะดวกขึ้น แต่ก็ทิ้งร่องรอยให้เห็นสำหรับผู้ที่ควบคุมโครงสร้างพื้นฐานนั้นด้วย

ปัญหาพื้นฐานคือการสอบถาม DNS แบบดั้งเดิมนั้นทำในรูปแบบข้อความธรรมดาและไม่มีการป้องกันซึ่งเปิดช่องให้เกิดการดักฟัง การโจมตีแบบคนกลาง และการบิดเบือนการตอบสนอง ผู้ให้บริการอินเทอร์เน็ตสามารถเรียนรู้ได้ว่าคุณสอบถามโดเมนใดและเมื่อใด ผู้โจมตีในเครือข่ายที่ใช้ร่วมกันสามารถพยายามดักจับคำขอและส่งการตอบกลับที่เป็นการหลอกลวงกลับมา เทคนิคนี้เรียกว่าการโจรกรรม DNS และในที่สุดอาจนำคุณไปสู่หน้าเว็บปลอม โฆษณาที่ไม่พึงประสงค์ หรือเว็บไซต์ที่ออกแบบมาเพื่อขโมยข้อมูล รัฐบาลและผู้ให้บริการอินเทอร์เน็ตได้ใช้ประโยชน์จากจุดอ่อนเหล่านี้ในอดีตเพื่อบังคับใช้การเซ็นเซอร์ บล็อกโดเมน หรือแสดงโฆษณาเพิ่มเติม

• การฟังแบบไม่ตั้งใจ: มีคนคอยสังเกตคำค้นหาและวิเคราะห์ว่าคุณใช้บริการหรือเว็บไซต์ใดเป็นประจำ
• คนกลาง: การสื่อสารถูกดักฟัง และการตอบกลับถูกดัดแปลงเพื่อปลอมตัวเป็นเซิร์ฟเวอร์
• การบล็อกและการกรอง: ระบบนี้จะป้องกันการระบุโดเมนบางโดเมน เพื่อควบคุมการเข้าถึงเนื้อหา

DNS ผ่าน HTTPS: เข้ารหัสคำขอเพื่อไม่ให้ใครเห็น

DNS over HTTPS หรือ DoH คือโซลูชันที่ใช้ประโยชน์จากโปรโตคอล HTTPS ในการส่งคำขอและคำตอบ DNS ในรูปแบบเข้ารหัสแทนที่จะส่งคำขอ DNS แบบเปิดเผย อุปกรณ์จะห่อหุ้มคำขอนั้นไว้ภายในการเชื่อมต่อที่ปลอดภัย โดยทั่วไปจะใช้พอร์ต 443 ซึ่งเป็นพอร์ตเดียวกับที่เว็บไซต์ที่ปลอดภัยใช้ วิธีนี้จะปกป้องทั้งคำขอและคำตอบ ป้องกันไม่ให้ผู้สังเกตการณ์ภายนอกอ่านข้อมูลได้โดยง่าย

เพื่อให้การทำงานนี้เป็นไปได้เซิร์ฟเวอร์ DNS ที่ถูกเรียกใช้งานจะต้องรองรับ Domain-based DNS (DoH ) ด้วย การเปิดใช้งานตัวเลือกในเบราว์เซอร์อย่างเดียวไม่เพียงพอ ตัวแก้ไขที่เลือกจะต้องเป็นไปตามมาตรฐานนี้ ข้อกำหนดนี้มีการพัฒนาอย่างต่อเนื่องและยังคงถือว่าเป็นเทคโนโลยีที่กำลังพัฒนาอยู่ แม้ว่าตั้งแต่ปี 2018 บริษัทต่างๆ เช่น Google และ Mozilla Foundation ได้ทดสอบและบูรณาการเทคโนโลยีนี้แล้วก็ตาม นอกเหนือจากความเป็นส่วนตัวที่ดีขึ้นแล้ว การทดสอบยังบ่งชี้ว่า DoH สามารถลดความหน่วงและทำให้การเรียกใช้งานเร็วขึ้น เนื่องจากไม่จำเป็นต้องแก้ไขโดเมนทั้งหมดเสมอไป แต่จะใช้เฉพาะส่วนที่จำเป็นขั้นต่ำเท่านั้น

ข้อดีของ DoH: ความเป็นส่วนตัวมากขึ้น การถูกแทรกแซงน้อยลง และประสิทธิภาพที่ดีขึ้น

ข้อได้เปรียบที่เห็นได้ชัดที่สุดคือเรื่องความปลอดภัยเนื่องจากข้อมูลถูกส่งแบบเข้ารหัส การดักฟังหรือแก้ไขคำขอ DNS จึงทำได้ยากขึ้นมากซึ่งทำให้การโจมตีแบบคนกลาง (man-in-the-middle) ทำได้ยากขึ้น ลดความเสี่ยงบนเครือข่าย Wi-Fi สาธารณะ และป้องกันไม่ให้ผู้ให้บริการในพื้นที่เห็นได้อย่างชัดเจนว่าคุณกำลังขอโดเมนใด เนื่องจากทราฟฟิก DoH ใช้พอร์ต 443 จึงกลมกลืนกับการเชื่อมต่อ HTTPS อื่นๆ และยากที่จะแยกแยะออกจากการเข้าชมเว็บปกติ

นอกจากนี้ยังมีเหตุผลด้านประสิทธิภาพด้วย DoH สามารถลดความหน่วงและเพิ่มความเร็วในการสื่อสาร DNS ได้เนื่องจากมีการเปลี่ยนแปลงวิธีการแก้ไขชื่อโดเมนและการใช้แคชให้ดียิ่งขึ้น ตัวอย่างเช่น เมธอด GET ของ API บางตัวได้รับการออกแบบให้แคชได้อย่างมีประสิทธิภาพมากขึ้น ในทางปฏิบัติ สิ่งนี้อาจส่งผลให้การท่องเว็บเร็วขึ้นเล็กน้อย แม้ว่าจะไม่ใช่วิธีแก้ปัญหาแบบวิเศษ และการปรับปรุงก็ไม่ได้เห็นได้ชัดเจนเสมอไป ยิ่งไปกว่านั้น เนื่องจากมีการใช้งานในเบราว์เซอร์ ผู้ใช้จึงไม่ต้องรอให้ผู้ให้บริการอินเทอร์เน็ตเปิดใช้งาน

ข้อเสียและข้อถกเถียง: เมื่อการเข้ารหัสทำให้ชีวิตยุ่งยากขึ้น

ไม่ใช่ทุกคนที่มองว่าการเข้ารหัสแบบโดเมน (DoH) เป็นสิ่งที่ดีการเข้ารหัสแบบเดียวกันที่ปกป้องผู้ใช้ก็ทำให้การตรวจสอบเครือข่ายทำได้ยากขึ้นเช่นกันโปรแกรมควบคุมการใช้งานของเด็กหลายโปรแกรมอาศัยการตรวจสอบการสืบค้น DNS เพื่อระบุว่าเด็ก ๆ พยายามเข้าถึงเว็บไซต์ใดบ้าง แต่ด้วย DoH งานนี้จะซับซ้อนมากขึ้นและอาจเป็นไปไม่ได้เลย สถานการณ์ที่คล้ายกันนี้เกิดขึ้นกับผู้ดูแลระบบเครือข่ายขององค์กร ซึ่งสูญเสียความสามารถในการมองเห็นโดเมนที่ถูกสืบค้นและไม่สามารถบังคับใช้กฎบางอย่างได้ง่ายเหมือนเดิม

ผู้ให้บริการอินเทอร์เน็ตยังสูญเสียความสามารถในการตรวจสอบการเข้าถึงและบล็อกโดเมนเฉพาะตามคำสั่งของสถาบัน ซึ่งก่อให้เกิดการถกเถียงที่สมเหตุสมผลบางคนมองว่าเป็นชัยชนะสำหรับความเป็นส่วนตัว ในขณะที่บางคนมองว่าเป็นปัญหาด้านการควบคุมและการจัดการในกรณีของ DoT นั้น ยังถูกวิพากษ์วิจารณ์ว่าใช้พอร์ตที่สามารถระบุได้เอง ซึ่งทำให้สามารถระบุการสอบถาม DNS ได้แม้จะไม่ทราบแน่ชัดว่ากำลังถามอะไรอยู่ DoH หลีกเลี่ยงสัญญาณที่ชัดเจนนี้โดยการปลอมตัวอยู่ภายในทราฟฟิก HTTPS แต่ในทางกลับกัน ผู้ดูแลระบบเครือข่ายจะมีเครื่องมือในการจัดการการสื่อสารน้อยลง

วิธีเปิดใช้งาน DoH ใน Chrome, Edge และ Firefox

การเปิดใช้งานระบบชื่อโดเมน (DNS) ในเบราว์เซอร์สมัยใหม่มักทำได้ง่าย โดยเฉพาะอย่างยิ่งหากใช้ Chromium หรือ Firefox เป็นพื้นฐานตัวเลือกนี้มีอยู่ แม้ว่าในบางกรณีอาจซ่อนอยู่ในเมนูการตั้งค่าขั้นสูงก่อนที่จะเปลี่ยนแปลงอะไรก็ตาม สิ่งสำคัญคือต้องเข้าใจว่าเบราว์เซอร์จะปกป้องเฉพาะการค้นหาของตัวเองเท่านั้น แอปพลิเคชันอื่นๆ บนอุปกรณ์อาจยังคงใช้ระบบ DNS ที่แตกต่างกันหากไม่ได้กำหนดค่าไว้ในระดับระบบด้วย

Google Chrome

ใน Chrome วิธีที่รวดเร็วคือการพิมพ์ chrome://flags/#dns-over-https ในแถบที่อยู่ นั่นจะนำคุณไปยังส่วน "Flags" ของ Chrome หรือฟีเจอร์ทดลองโดยตรงคุณจะเห็นตัวเลือกที่ชื่อว่า "การค้นหา DNS ที่ปลอดภัย" ถูกเลือกไว้ ให้คลิกที่เมนูแบบเลื่อนลงที่เขียนว่า "ค่าเริ่มต้น" แล้วเลือก "เปิดใช้งาน" จากนั้นคุณจะต้องรีสตาร์ทเบราว์เซอร์เพื่อให้การเปลี่ยนแปลงมีผล

Microsoft Edge

ใน Edge ที่ใช้ Chromium เป็นพื้นฐาน กระบวนการนี้แทบจะเหมือนกันทุกประการ เปิดเบราว์เซอร์ของคุณแล้วพิมพ์ edge://flags/#dns-over-https ในแถบค้นหาคุณจะเข้าไปที่เมนู Flags ของ Edge และตัวเลือก Secure DNS lookups จะปรากฏขึ้นมา เปลี่ยนค่าเริ่มต้นเป็น Enabled แล้วรีสตาร์ทเบราว์เซอร์เมื่อได้รับแจ้ง

Mozilla Firefox

ใน Firefox คุณไม่จำเป็นต้องไปที่ Flags คลิกปุ่มเมนูที่มุมบนขวาแล้วเลือก Optionsในส่วน General เลื่อนลงไปด้านล่างแล้วคลิก Network Settings ในหน้าต่างที่เปิดขึ้น ให้ติ๊กช่องถัดจาก Enable DNS over HTTPS จากนั้นคุณสามารถเลือกผู้ให้บริการเช่น Cloudflare และ NextDNS เพื่อทำการเข้ารหัสผ่าน HTTPS ได้

DNS over TLS (DoT): อีกหนึ่งเส้นทางการเข้ารหัส

DNS over TLS หรือ DoT เป็นอีกวิธีหนึ่งในการปกป้องการสืบค้น DNS แทนที่จะใช้ HTTPS DoT ใช้ TLS ผ่านการเชื่อมต่อ TCP และพอร์ตมาตรฐาน 853 TLS เป็นพื้นฐานด้านความปลอดภัยเดียวกันกับ HTTPS ดังนั้นแนวคิดจึงคล้ายกัน คือการสร้างอุโมงค์เข้ารหัสที่เฉพาะผู้เข้าร่วมสองฝ่ายเท่านั้นที่สามารถถอดรหัสและประมวลผลข้อมูลได้ วิธีนี้ทำให้การโจมตีแบบ Man-in-the-Middle ทำได้ยากขึ้น และป้องกันไม่ให้บุคคลที่สามอ่านหรือแก้ไขการสืบค้นได้

DotT มีข้อดีหลายประการ โดยเฉพาะเมื่อเทียบกับ DNS แบบดั้งเดิม ซึ่งไม่มีมาตรการรักษาความปลอดภัยใดๆการเข้ารหัสช่วยป้องกันอาชญากรไซเบอร์จากการดักฟังคำขอ และยังช่วยขัดขวางมาตรการเซ็นเซอร์บางอย่างได้อีกด้วยอย่างไรก็ตาม จำเป็นต้องมีความเข้ากันได้ทั้งจากฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ ผู้ให้บริการหลายรายมีเซิร์ฟเวอร์ที่ใช้งานร่วมกันได้ แต่การใช้งานบนเดสก์ท็อปหรือแล็ปท็อปมักต้องติดตั้งซอฟต์แวร์เพิ่มเติม ในขณะที่บน Android รุ่นใหม่ๆ อย่างน้อยตั้งแต่ Android 9 เป็นต้นไปนั้นได้มีการรวมไว้แล้ว สำหรับ Windows และ Linux ก็มีโซลูชันอยู่เช่นกัน แต่ก็ไม่ได้ราบรื่นอย่างที่หลายคนต้องการเสมอไป

ในบรรดาข้อเสีย ผู้เชี่ยวชาญด้านการปกป้องข้อมูลหลายคนวิจารณ์ DoT ว่าใช้พอร์ตเดียวที่สามารถระบุได้ในขณะที่ไม่สามารถรู้ได้ว่ากำลังเข้าถึงเว็บไซต์ใด แต่ก็สามารถตรวจจับการรับส่งข้อมูล DNS ได้สำหรับผู้ดูแลระบบเครือข่ายบางคน นี่เป็นประโยชน์เพราะช่วยให้พวกเขาสามารถมองเห็นภาพรวมของสิ่งที่เกิดขึ้นได้ แต่สำหรับคนอื่นๆ มันเป็นสัญญาณที่พวกเขาต้องการซ่อนไว้ นอกจากนี้ DoT ยังไม่แพร่หลายเท่า DNS แบบดั้งเดิม และการนำไปใช้ในฝั่งเซิร์ฟเวอร์ยังจำกัด มีความกังวลว่าบริษัทเพียงไม่กี่แห่งจะรวมศูนย์การสอบถาม DNS มากขึ้นเรื่อยๆ ซึ่งอาจสร้างการผูกขาดในระดับนานาชาติได้

DoH กับ DoT: สองวิธีในการปกป้องสิ่งเดียวกัน

ความแตกต่างหลักระหว่าง DoH และ DoT อยู่ที่พอร์ตและวิธีการปลอมแปลงการรับส่งข้อมูลDoT ใช้พอร์ตเฉพาะของตัวเองคือ 853 ในขณะที่ DoH ใช้พอร์ต 443 และกลมกลืนไปกับการเชื่อมต่อ HTTPS ปกติความแตกต่างเล็กน้อยนี้ได้ก่อให้เกิดการถกเถียงกันอย่างมาก จากมุมมองด้านความเป็นส่วนตัว การที่ไม่สามารถแยกแยะการสอบถาม DNS ออกจากการรับส่งข้อมูลอื่นๆ ได้ถือเป็นข้อดี: หากไม่ได้รับการระบุตัวตน ก็จะไม่สามารถถูกดัดแปลงได้ง่าย อย่างไรก็ตาม จากมุมมองด้านการจัดการเครือข่าย การควบคุมจะหายไป และการใช้มาตรการรักษาความปลอดภัยหรือการกรองข้อมูลจะทำได้ยากขึ้น

โดยหลักแล้ว มีแนวคิดอยู่สองอย่างIETF ซึ่งเป็นกลุ่มที่พัฒนามาตรฐานอินเทอร์เน็ตหลายอย่าง สนับสนุน DoTในขณะที่ Google และมูลนิธิ Mozilla สนับสนุน DoH อย่างแข็งขัน เทคโนโลยีทั้งสองนี้ไม่ได้ขัดแย้งกัน แต่เป็นตัวแทนของวิธีการทำความเข้าใจความเป็นส่วนตัว การมองเห็นเครือข่าย และบทบาทของตัวกลางที่แตกต่างกัน การเลือกใช้ระหว่างสองเทคโนโลยีนี้ขึ้นอยู่กับว่าอะไรที่ต้องได้รับการปกป้อง และใครต้องจัดการเครือข่าย

DoH เทียบกับ VPN: DoH ปกป้องเฉพาะคำถาม ไม่ใช่การเดินทางทั้งหมด

DoH และ VPN มักถูกกล่าวถึงในบทสนทนาเกี่ยวกับการปกป้องความเป็นส่วนตัว แต่ทั้งสองอย่างไม่ได้ทำหน้าที่เหมือนกันDoH ปกป้องเฉพาะชื่อที่ใช้ในการค้นหา ในขณะที่ VPN ปกป้องเส้นทางที่ข้อมูลของคุณเดินทางวิธีที่ง่ายที่สุดที่จะเข้าใจเรื่องนี้คือ ลองนึกภาพว่า DoH ใส่คำถามสำคัญไว้ในซองปิดผนึก ในขณะที่ VPN ทำให้การเดินทางทั้งหมดผ่านอุโมงค์ส่วนตัวก่อนที่จะกลับสู่ถนนสาธารณะ ทั้งสองอย่างสามารถช่วยเพิ่มความเป็นส่วนตัวได้ แต่มีเพียงอย่างเดียวเท่านั้นที่ออกแบบมาเพื่อปกป้องการรับส่งข้อมูลของโทรศัพท์ แท็บเล็ต และคอมพิวเตอร์อย่างครอบคลุม

DNS ทำอะไรก่อนที่เว็บไซต์จะโหลดเสร็จ?

ก่อนที่เบราว์เซอร์ของคุณจะโหลดเว็บไซต์ได้ อุปกรณ์ของคุณจำเป็นต้องทราบตำแหน่งที่ตั้งDNS ทำงานเหมือนสมุดโทรศัพท์ โดยแปลงชื่อเว็บไซต์เป็นที่อยู่ IP กระบวนการนี้เกิดขึ้นตลอดเวลา ไม่ว่าจะเป็นเมื่อคุณเปิดหน้าเว็บ เปิดแอป อัปเดตอีเมล หรือเล่นวิดีโอ ส่วนใหญ่แล้วจะเกิดขึ้นโดยที่คุณไม่รู้ตัว ซึ่งเป็นเรื่องดีในแง่ของความสะดวกสบาย แต่ก็ทำให้มองข้ามปัญหาด้านความเป็นส่วนตัวได้ง่ายเช่นกัน การสอบถาม DNS แบบดั้งเดิมไม่ได้เข้ารหัส ดังนั้นผู้ให้บริการอินเทอร์เน็ต นายจ้าง โรงเรียน Wi-Fi ของร้านกาแฟ หรือเครือข่ายโรงแรม อาจเห็นโดเมนที่อุปกรณ์ของคุณพยายามเข้าถึง พวกเขาจะไม่เห็นเนื้อหาทั้งหมดของหน้า HTTPS แต่พวกเขาจะเห็นภาพรวมกิจกรรมของคุณได้ค่อนข้างชัดเจน

การตรวจสอบ DNS ไม่ได้เปิดเผยทุกหน้าเว็บที่คุณเคยดูหรือทุกสิ่งที่คุณพิมพ์ลงในแบบฟอร์ม แต่รายการโดเมนสามารถเปิดเผยพฤติกรรม ความสนใจ เครื่องมือในการทำงาน การวิจัยด้านสุขภาพ หรือบริการทางการเงินได้นั่นเป็นเหตุผลที่ DNS ที่เข้ารหัสกลายเป็นคุณสมบัติความเป็นส่วนตัวที่มีประโยชน์ มันไม่ได้เปิดเผยทุกอย่าง แต่ก็เปิดเผยมากกว่าที่หลายคนคิด

DoH ปกปิดอะไร และเปิดเผยอะไรบ้าง?

DoH ส่งคำขอ DNS ผ่าน HTTPS ซึ่งเป็นโปรโตคอลเข้ารหัสเดียวกันกับที่เว็บไซต์ที่ปลอดภัยใช้คำขอจะออกจากอุปกรณ์ของคุณในรูปแบบเข้ารหัสและส่งไปยังตัวแก้ไขที่รองรับมาตรฐานนี้บน Wi-Fi สาธารณะ วิธีนี้จะทำให้ผู้ให้บริการเครือข่ายอ่านคำขอของคุณโดยไม่ได้ตั้งใจได้ยาก หากผู้ให้บริการอินเทอร์เน็ตของคุณจัดการ DNS การเปลี่ยนไปใช้ตัวแก้ไข DoH จะช่วยป้องกันไม่ให้พวกเขาเห็นคำขอเหล่านี้ในแบบปกติ นอกจากนี้ หากเครือข่ายใดทำการเปลี่ยนแปลงผลลัพธ์การแก้ไขชื่อ การเข้ารหัส DNS จะช่วยลดการเปลี่ยนแปลงบางรูปแบบได้

DoH ซ่อนเฉพาะคำค้นหา ไม่ใช่การสนทนาทั้งหมดอาจป้องกันไม่ให้ผู้สังเกตการณ์บางคนเห็นการค้นหาโดเมนได้อย่างชัดเจน แต่ไม่ได้เปลี่ยนการเชื่อมต่ออินเทอร์เน็ตทั้งหมดของคุณให้เป็นอุโมงค์เข้ารหัสเมื่ออุปกรณ์ทราบที่อยู่ IP แล้ว การเชื่อมต่อที่เหลือจะดำเนินไปตามเส้นทางปกติ เว้นแต่เครื่องมือความเป็นส่วนตัวอื่นจะเปลี่ยนเส้นทางนั้น DoH ไม่ได้ซ่อนที่อยู่ IP จริงของคุณจากเว็บไซต์ แอป หรือบริการที่คุณเชื่อมต่อ และไม่ได้ทำให้คุณดูเหมือนอยู่ในเมืองหรือประเทศอื่น หากคุณเข้าสู่ระบบบัญชี บริการนั้นจะรู้ว่าเป็นคุณ หากเบราว์เซอร์มีคุกกี้ เซสชันที่บันทึกไว้ ตัวระบุโฆษณา หรือลายนิ้วมือที่จดจำได้ DoH ก็จะไม่ลบสัญญาณเหล่านั้น

นอกจากนี้ ยังไม่สามารถปกป้องทุกแอปพลิเคชันได้ เว้นแต่จะมีการกำหนดค่าในระดับระบบ และแอปพลิเคชันนั้นต้องเคารพการตั้งค่าดังกล่าว เบราว์เซอร์หนึ่งอาจใช้ DNS ที่ปลอดภัย ในขณะที่แอปพลิเคชันอื่นบนอุปกรณ์เดียวกันอาจใช้เส้นทาง DNS ที่แตกต่างกันแอปบางแอปจัดการเครือข่ายของตนเองและไม่สอดคล้องกับการตั้งค่าของระบบหรือเบราว์เซอร์เสมอไป ดังนั้น DoH จึงอาจสร้างความเข้าใจผิดว่าได้รับการปกป้องอย่างสมบูรณ์: มันช่วยปรับปรุงความเป็นส่วนตัวของการสืบค้น DNS แต่ไม่ได้ปกป้องการถ่ายโอนไฟล์ การรับส่งข้อความ การโทรวิดีโอ การเชื่อมต่อเกม การซิงค์ข้อมูลในพื้นหลัง หรือแอปพลิเคชันสตรีมมิ่งในแบบที่ VPN ทำได้

VPN ปกป้องอะไรได้บ้าง และอะไรที่มันซ่อนไม่ได้?

VPN ช่วยปกป้องส่วนต่างๆ ของการเดินทางของคุณมันสร้างอุโมงค์เข้ารหัสระหว่างอุปกรณ์ของคุณกับเซิร์ฟเวอร์ VPN โดยกำหนดเส้นทางการรับส่งข้อมูลอินเทอร์เน็ตของคุณผ่านเซิร์ฟเวอร์นั้นผู้ให้บริการอินเทอร์เน็ตหรือเครือข่าย Wi-Fi ในพื้นที่ของคุณจะเห็นการเชื่อมต่อที่เข้ารหัสไปยังเซิร์ฟเวอร์ VPN ไม่ใช่การมองเห็นเว็บไซต์และบริการทุกแห่งที่คุณเชื่อมต่ออย่างชัดเจน นอกจากนี้ VPN ยังเปลี่ยนที่อยู่ IP สาธารณะที่เว็บไซต์และแอปเห็น แทนที่จะเป็นที่อยู่ IP ของผู้ให้บริการเครือข่ายมือถือหรือบ้านของคุณ ปลายทางจะเห็นที่อยู่ IP ของเซิร์ฟเวอร์ VPN ซึ่งสามารถลดการติดตามตามตำแหน่ง ช่วยให้คุณหลีกเลี่ยงโปรไฟล์ของผู้ให้บริการอินเทอร์เน็ตบางราย และทำให้การใช้ Wi-Fi สาธารณะปลอดภัยยิ่งขึ้น

VPN ที่ครอบคลุมสามารถปกป้องเบราว์เซอร์ แอปสตรีมมิ่ง ไคลเอนต์อีเมล เครื่องมือสำรองข้อมูลบนคลาวด์ แอปส่งข้อความ เกม และบริการพื้นหลังได้นอกจากนี้ยังสามารถส่งคำขอ DNS ผ่านอุโมงค์เข้ารหัสได้เมื่อตั้งค่าอย่างถูกต้องซึ่งเป็นเหตุผลที่ดีที่จะทำการทดสอบการรั่วไหลของ DNS อย่างไรก็ตาม VPN ไม่ใช่เวทมนตร์ หากคุณเข้าสู่ระบบเครือข่ายสังคม บัญชีอีเมล บริการสตรีมมิ่ง หรือร้านค้าออนไลน์ บริการเหล่านั้นก็ยังคงรู้ว่าคุณเป็นใคร มันอาจซ่อนที่อยู่ IP ดั้งเดิมของคุณได้ แต่ไม่ได้ทำให้การเข้าสู่ระบบของคุณเป็นนิรนาม เช่นเดียวกับสิ่งที่คุณส่งโดยตรง: ชื่อ ที่อยู่อีเมล รายละเอียดการชำระเงิน ที่อยู่จัดส่ง รูปภาพ หรือข้อความของคุณ

คุกกี้และการระบุตัวตนเบราว์เซอร์ยังคงมีความสำคัญ แอปต่างๆ สามารถสร้างปัญหาที่คล้ายกันได้ผ่านตัวระบุโฆษณา สิทธิ์การเข้าถึง การเข้าถึงตำแหน่ง การสแกนบลูทูธ ชื่อ Wi-Fi ใกล้เคียง และเครื่องมือสแกนมัลแวร์เป็นอุปสรรคสำคัญอีกอย่างหนึ่ง เพราะสามารถดักจับข้อมูลได้ก่อนที่ข้อมูลจะเข้าถึงอุโมงค์ VPN ด้วยซ้ำ กล่าวโดยสรุป VPN ซ่อนและเข้ารหัสกิจกรรมจำนวนมาก แต่ไม่ได้ปกปิดร่องรอยดิจิทัลทั้งหมด

DoH และ VPN สามารถใช้งานพร้อมกันได้

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

ปัญหาเกิดขึ้นเมื่อเบราว์เซอร์ใช้การตั้งค่า Domain Authority (DoH) ของตัวเอง ในขณะที่ VPN พยายามจัดการ DNS ในระดับระบบอาจไม่มีอะไรเสียหาย แต่ความสับสนอาจเกิดขึ้นได้คุณอาจคิดว่าการสอบถามทั้งหมดผ่าน VPN แต่ในความเป็นจริง เบราว์เซอร์กำลังส่งบางส่วนไปยังตัวแก้ไข DNS อื่นด้วยตัวเอง นี่คือจุดที่การทดสอบการรั่วไหลของ DNS มีประโยชน์ หากหลังจากเชื่อมต่อกับ VPN แล้ว คุณเห็นเซิร์ฟเวอร์ DNS ของผู้ให้บริการอินเทอร์เน็ตของคุณ แสดงว่ามีบางอย่างทำงานผิดปกติ หากคุณเห็นเซิร์ฟเวอร์ที่เกี่ยวข้องกับ VPN แสดงว่าการตั้งค่ามีแนวโน้มที่จะทำงานได้อย่างถูกต้อง

เมื่อใดที่ DoH เพียงพอ และเมื่อใดที่ควรใช้ VPN?

DoH อาจเพียงพอแล้วเมื่อความกังวลหลักของคุณคือความเป็นส่วนตัวขั้นพื้นฐานของการสืบค้น DNS ในเบราว์เซอร์ของคุณบนเครือข่ายบ้านที่เชื่อถือได้ การเปิดใช้งาน Secure DNS จะช่วยลดการเปิดเผยข้อมูลแบบข้อความธรรมดาโดยไม่จำเป็นต้องเปลี่ยนตำแหน่งที่ตั้งหรือรักษาความปลอดภัยแอปพลิเคชันทั้งหมดของคุณนอกจากนี้ยังเป็นประโยชน์ในเครือข่ายที่การกรองหรือการจัดการ DNS เป็นเรื่องที่น่ากังวล เนื่องจาก1การส่งผ่าน HTTPS ทำให้การตรวจสอบหรือแก้ไขทำได้ยากขึ้น นี่ไม่ได้หมายความว่าจะหลีกเลี่ยงข้อจำกัดทั้งหมดหรือป้องกันการเซ็นเซอร์ได้ แต่เป็นการปรับปรุงที่สำคัญกว่า DNS ที่ไม่ได้เข้ารหัส ยิ่งไปกว่านั้น มันมีน้ำหนักเบา: คุณไม่จำเป็นต้องเลือกเซิร์ฟเวอร์ VPN หรือเปลี่ยนแปลงเส้นทางการกำหนดเส้นทางของคุณอย่างมาก และโดยทั่วไปคุณจะไม่สังเกตเห็นผลกระทบอย่างมีนัยสำคัญต่อความเร็ว

การใช้ VPN นั้นเหมาะสมที่สุดเมื่อคุณต้องการการปกป้องทั้งอุปกรณ์ ไม่ใช่แค่การค้นหา DNS เท่านั้นซึ่งรวมถึงสนามบิน โรงแรม โรงเรียน พื้นที่ทำงานร่วมกัน ร้านกาแฟ และที่พักให้เช่าในเครือข่ายที่ใช้ร่วมกัน คุณไม่รู้ว่าใครควบคุมเราเตอร์ ใครเชื่อมต่ออยู่บ้าง หรือมีใครพยายามดักฟังข้อมูลหรือไม่ VPN ยังช่วยได้เมื่อคุณไม่ต้องการให้ผู้ให้บริการอินเทอร์เน็ตของคุณสร้างโปรไฟล์รูปแบบการท่องเว็บของคุณ แม้ว่า HTTPS จะปกป้องเนื้อหาของหน้าเว็บ แต่ข้อมูลเมตาของเครือข่ายก็ยังสามารถเปิดเผยรูปแบบที่เป็นประโยชน์ได้ การเดินทางเป็นอีกตัวอย่างที่ชัดเจน: VPN สามารถทำให้การเชื่อมต่อของคุณเสถียรมากขึ้น ปกป้องคุณในเครือข่ายที่ไม่คุ้นเคย และทำให้เว็บไซต์เห็นตำแหน่งของเซิร์ฟเวอร์ VPN แทนที่จะเป็นการเชื่อมต่อในพื้นที่ชั่วคราวของคุณ

รายละเอียดทางเทคนิคของ Google Public DNS DoH API

Google Public DNS มี API DoH สองแบบที่แตกต่างกันแบบแรกออกแบบมาสำหรับ RFC 8484 และรองรับคำขอ GET และ POST ที่ https://dns.google/dns-query ส่วนอีกแบบเป็น API JSON ที่รองรับเฉพาะคำขอ GET ที่ https://dns.google/resolveนอกจากนี้ยังมีเว็บอินเทอร์เฟซที่ https://dns.google/ ที่แสดงผลลัพธ์ JSON ในเบราว์เซอร์ แต่ไม่ได้ใช้งาน API อย่างเต็มรูปแบบ อินเทอร์เฟซนี้ไม่ควรสับสนกับ URL ของ API หรือกับ https://dns.google/query บริการนี้ไม่รองรับ URL HTTP ที่ไม่ปลอดภัย และ DoH ยังได้รับการสนับสนุนโดยบริการ DNS64 สาธารณะของ Google ด้วยเช่นกัน แม้ว่าในกรณีนั้นจะรองรับเฉพาะ IPv6 เท่านั้น เอกสารการขนส่งที่ปลอดภัยของ Google มีตัวอย่าง curl และรายละเอียดเกี่ยวกับ TLS, DoT และ DoH

วิธีการ HTTP ที่ใช้งานได้

เมธอด GET สามารถลดความหน่วงได้เนื่องจากมีการแคชข้อมูลได้อย่างมีประสิทธิภาพมากกว่าคำขอ GET ตามมาตรฐาน RFC 8484 ต้องมีพารามิเตอร์ `?dns=` พร้อมข้อความ DNS ที่เข้ารหัส Base64Urlและเป็นเมธอดเดียวที่รองรับโดย JSON API เมธอด POST ก็มีเฉพาะใน RFC 8484 เช่นกัน และใช้ข้อความ DNS แบบไบนารีที่มี `application/dns-message` ทั้งในส่วนเนื้อหาของคำขอและการตอบกลับ เมธอด HEAD ปัจจุบันยังไม่รองรับและจะส่งคืนข้อผิดพลาด 400 Bad Request ส่วนเมธอดอื่นๆ จะส่งคืนข้อผิดพลาด 501 Not Implemented

รหัสสถานะและข้อผิดพลาด

API จะส่งคืนรหัส HTTP หลายรหัสที่ควรทราบรหัส 200 OK แสดงว่าการแยกวิเคราะห์ HTTP และการสื่อสารกับตัวแก้ไข DNS ประสบความสำเร็จเนื้อหาการตอบกลับอาจเป็นข้อมูลไบนารีของการตอบสนอง DNS หรือ JSON ขึ้นอยู่กับปลายทาง ส่วนหัว Accept และพารามิเตอร์ GET หมายเหตุ: ข้อผิดพลาด HTTP อาจเป็นความล้มเหลวของ DNS เช่นกัน ดังนั้นจึงควรตรวจสอบรหัสการตอบสนอง DNS เช่น ฟิลด์ "Status" ของ JSON เพื่อหาข้อผิดพลาด เช่น SERVFAIL, FORMERR, REFUSED หรือ NOTIMP

• 301 ย้ายถาวรแล้ว: ไคลเอ็นต์ต้องลองส่งคำขออีกครั้งที่ URL ที่ระบุใน Location หากคำขอเดิมเป็น POST ไคลเอ็นต์ควรลองส่งซ้ำด้วย GET เฉพาะในกรณีที่ URL ใหม่ระบุพารามิเตอร์ DNS เท่านั้น มิเช่นนั้นจะต้องส่งซ้ำด้วย POST รหัสสถานะ 302, 307 และ 308 อาจปรากฏขึ้น และไคลเอ็นต์ DoH ต้องจัดการกับทั้งสี่รหัสนี้ รหัสสถานะ 301 และ 308 แบบถาวรสามารถแคชได้ไม่จำกัด คำขอ POST ที่ได้รับรหัสสถานะ 307 หรือ 308 จะต้องลองส่งซ้ำด้วย POST เสมอ
• 400 คำขอไม่ถูกต้อง: ปัญหาในการแยกวิเคราะห์พารามิเตอร์ GET หรือข้อความคำขอ DNS ที่ไม่ถูกต้อง ข้อความ DNS ที่ไม่ถูกต้องส่วนใหญ่จะได้รับรหัส 200 OK พร้อม FORMERR แต่ข้อผิดพลาด HTTP จะเกิดขึ้นสำหรับข้อความที่ไม่สามารถอ่านได้โดยไม่มีส่วนคำถาม มีรหัส QR ที่ระบุการตอบกลับ หรือมีรหัสที่รวมกันอย่างไม่สมเหตุสมผล
• 413 ขนาดไฟล์ข้อมูลใหญ่เกินไป: เนื้อหาของคำขอ POST ตามมาตรฐาน RFC 8484 มีขนาดเกินขนาดข้อความสูงสุด 512 ไบต์
• 414 URI ยาวเกินไป: ส่วนหัวของคำขอ GET มีขนาดใหญ่เกินไป หรือพารามิเตอร์ DNS มีขนาดเกิน 512 ไบต์
• 415 ประเภทสื่อที่ไม่รองรับ: ส่วนเนื้อหาของคำขอ POST ไม่มีส่วนหัวประเภทเนื้อหา application/dns-message
• 429 คำขอมากเกินไป: มีการส่งคำขอมากเกินไปในช่วงเวลาที่กำหนด ลูกค้าต้องรอจนกว่าจะถึงเวลาที่ระบุไว้ในส่วนหัว Retry-After
• ข้อผิดพลาด 500 เซิร์ฟเวอร์ภายใน: เกิดข้อผิดพลาดภายในระบบบริการของกระทรวงสาธารณสุข
• 501 ยังไม่ได้ดำเนินการ: มีการใช้งานเฉพาะเมธอด GET และ POST เท่านั้น ส่วนเมธอดอื่นๆ จะส่งคืนข้อผิดพลาดนี้
• 502 Bad Gateway: บริการ DoH ไม่สามารถสื่อสารกับตัวแก้ไข DNS สาธารณะของ Google ได้ การลองใช้ที่อยู่ IP อื่นอาจช่วยได้ แต่แผนสำรองที่มีประสิทธิภาพมากกว่าคือการลองใช้บริการ DoH อื่น หรือเปลี่ยนไปใช้ DNS แบบดั้งเดิมโดยใช้ UDP หรือ TCP ที่ 8.8.8.8

แนวปฏิบัติที่ดีที่สุดสำหรับความเป็นส่วนตัวและประสิทธิภาพ

นักพัฒนาแอปพลิเคชัน DoH ควรจำกัดการใช้ส่วนหัว HTTP ส่วนหัวต่างๆ เช่น Cookie, User-Agent และ Accept-Language สามารถเปิดเผยข้อมูลเกี่ยวกับการใช้งานฝั่งไคลเอ็นต์และนำไปสู่การเปิดเผยตัวตนได้ขอแนะนำให้ส่งเฉพาะส่วนหัวที่จำเป็นสำหรับ DoH เท่านั้น ได้แก่ Host, Content-Type (สำหรับคำขอ POST) และ Accept หากจำเป็น ส่วนหัว User-Agent ควรมีอยู่ในเวอร์ชันสำหรับการพัฒนาหรือทดสอบ นอกจากนี้ยังแนะนำให้ใช้ตัวเลือกการเติมข้อมูล EDNS เพื่อย่อคำขอให้มีความยาวที่เหมาะสมและทำให้การวิเคราะห์การรับส่งข้อมูลทำได้ยากขึ้น การเติมข้อมูล HTTP/2 เป็นไปได้ แต่แตกต่างจากการเติมข้อมูล EDNS ตรงที่ไม่สร้างการเติมข้อมูลในคำตอบของเซิร์ฟเวอร์ DoH

วิธีการ POST ใน RFC 8484 ควรใช้เฉพาะในแอปพลิเคชันหรือโหมดเบราว์เซอร์ที่คำนึงถึงความเป็นส่วนตัวเท่านั้นการใช้ POST จะลดความจุของแคชและอาจเพิ่มความหน่วง ดังนั้นโดยทั่วไปจึงไม่แนะนำให้ใช้อย่างไรก็ตาม การลดขนาดแคชอาจเป็นสิ่งที่เหมาะสมสำหรับแอปพลิเคชันที่ต้องการป้องกันการโจมตีการซิงโครไนซ์เว็บแอปที่มุ่งเป้าไปที่การค้นหาว่าผู้ใช้ได้เยี่ยมชมโดเมนใดเมื่อเร็ว ๆ นี้ วิธีการใช้ HTTPS ก็มีข้อดีในทางปฏิบัติเช่นกัน: API ของ HTTPS มีให้ใช้งานและได้รับการสนับสนุนอย่างกว้างขวาง ทำให้การใช้งานง่ายขึ้น บริการ HTTPS ช่วยให้เว็บแอปเข้าถึงระเบียน DNS ทุกประเภท หลีกเลี่ยงข้อจำกัดของ API ของเบราว์เซอร์หรือระบบปฏิบัติการที่มักจำกัดอยู่เพียงการค้นหาโฮสต์ไปยังที่อยู่ และไคลเอ็นต์ที่ใช้ HTTPS ผ่าน UDP ด้วย QUIC สามารถหลีกเลี่ยงปัญหาเช่น line-head blocking ที่เกิดขึ้นกับ TCP ได้ หากคุณพบข้อบกพร่องหรือต้องการขอคุณสมบัติใหม่ คุณควรรายงานปัญหาที่เกี่ยวข้องกับ DoH ผ่านช่องทางปกติ

คำถามที่พบบ่อยเกี่ยวกับ DoH และ VPN

หนึ่งในคำถามที่พบบ่อยที่สุดคือ การใช้ DoH (Domain of Host) ในขณะที่ใช้ VPN อยู่แล้วนั้นเหมาะสมหรือไม่เป็นไปได้ แต่โดยทั่วไปแล้ว วิธีที่ได้ผลดีที่สุดคือ ให้ VPN จัดการ DNSและตรวจสอบด้วยการทดสอบการรั่วไหลว่าการสอบถามข้อมูลนั้นผ่านช่องทางที่ถูกต้องหรือไม่ หากเบราว์เซอร์ส่งการสอบถามข้อมูลไปทางหนึ่ง และ VPN ส่งไปอีกทางหนึ่ง คุณอาจเจอกับปัญหาที่ไม่พึงประสงค์ได้

คำถามที่พบบ่อยอีกข้อคือ DoH ป้องกันไม่ให้ผู้ให้บริการอินเทอร์เน็ตของคุณเห็นว่าคุณเข้าชมเว็บไซต์ใดบ้างหรือไม่ DoH ซ่อนการสืบค้น DNS จากผู้สังเกตการณ์หลายราย แต่ไม่ได้ลบข้อมูลเมตาหรือซ่อนที่อยู่ IP ของคุณทั้งหมดผู้ให้บริการอินเทอร์เน็ตของคุณยังคงสามารถเห็นที่อยู่ IP ที่คุณเชื่อมต่อและข้อมูลเครือข่ายอื่นๆ ได้ สำหรับการป้องกันที่ครอบคลุมมากขึ้น คุณจำเป็นต้องใช้ VPN หรือการผสมผสานของเลเยอร์ความเป็นส่วนตัวหลายชั้น

นอกจากนี้ ยังควรพิจารณาด้วยว่า DomainHost (DoH) เพียงพอสำหรับการใช้งาน Wi-Fi สาธารณะหรือไม่มันอาจช่วยป้องกันไม่ให้ผู้ให้บริการเครือข่ายอ่านข้อมูล DNS ของคุณได้ง่ายๆ แต่ก็ไม่ได้ปกป้องการเชื่อมต่อทั้งหมดหรือปริมาณการรับส่งข้อมูลของทุกแอปพลิเคชันในสนามบิน โรงแรม และร้านกาแฟ การใช้ VPN มักจะครอบคลุมมากกว่า โดยเฉพาะอย่างยิ่งหากคุณไม่ทราบว่าใครเป็นผู้ควบคุมเราเตอร์ หรือมีคนอื่นๆ เชื่อมต่ออยู่ด้วย

ระบบชื่อโดเมน (DoH) และ VPN ไม่ใช่คู่แข่งโดยตรง แต่เป็นเครื่องมือที่มีความสามารถแตกต่างกันDoH เข้ารหัสการค้นหาโดเมนและลดความเสี่ยงในส่วนนั้นของกระบวนการ ในขณะที่ VPN เข้ารหัสเส้นทางระหว่างอุปกรณ์ของคุณกับเซิร์ฟเวอร์และเปลี่ยนที่อยู่ IP ที่ปลายทางมองเห็นทั้งสองอย่างไม่ได้ทำให้คุณมองไม่เห็น: บัญชี คุกกี้ ลายนิ้วมือของเบราว์เซอร์ สิทธิ์ของแอป มัลแวร์ และข้อมูลใดๆ ที่คุณแชร์โดยตรงยังคงสามารถระบุตัวตนของคุณได้ แต่ไม่ได้หมายความว่ามันไร้ประโยชน์ เพียงแต่แต่ละอย่างมีบทบาทของมัน DoH ป้องกันการค้นหาที่อยู่ ในขณะที่ VPN ป้องกันเส้นทางที่ข้อมูลของคุณเดินทางได้มากกว่านั้น