DNS over TLS กับ VPN ต่างกันอย่างไร

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

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

DNS over TLS ปกป้องอะไร หนึ่งช่วงเท่านั้น

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

DNS over TLS ที่กำหนดใน RFC 7858 ห่อคำถามเดิมไว้ในเซสชัน TLS คำถามเหมือนเดิมทุกประการ เปลี่ยนเพียงบรรจุภัณฑ์ ผลที่ตามมามีสามข้อ

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

DoT จึงปกป้องเนื้อหาของหนึ่งช่วง ไม่ซ่อนคุณจาก resolver ไม่ซ่อนที่อยู่ปลายทาง และไม่แตะทราฟฟิกอื่นนอกจาก DNS ภาพพื้นฐานว่าชื่อถูกแปลงอย่างไรดูได้ที่ DNS ทำงานอย่างไร

หนึ่งการถามด้วย DoT มีขั้นตอนอย่างไร

การถามที่เข้ารหัสหนึ่งครั้งมีลำดับสั้น ๆ

1. อุปกรณ์ของคุณ หรือเราเตอร์ที่ส่งต่อให้ เปิดการเชื่อมต่อ TCP ไปยัง resolver บนพอร์ต 853
2. ทำ TLS handshake โดยใช้ TLS 1.3 ถ้าทั้งสองฝั่งรองรับ resolver แสดงใบรับรอง
3. ถ้าคุณตั้งชื่อโฮสต์ของ resolver ไว้ อุปกรณ์จะตรวจว่าใบรับรองตรงกับชื่อนั้น ถ้าตั้งเป็นที่อยู่ IP อย่างเดียว อาจไม่มีการตรวจชื่อที่เข้มงวด
4. คำถาม DNS ผ่านเซสชันที่เข้ารหัส และคำตอบกลับมาทางเดียวกัน
5. การเชื่อมต่อมักถูกเปิดค้างไว้ใช้ซ้ำ การถามครั้งต่อไปจึงข้าม handshake และเร็วขึ้น

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

โหมด strict และ opportunistic

RFC 7858 อธิบายรูปแบบการใช้สองแบบ และความต่างเปลี่ยนสิ่งที่เกิดเมื่อมีอะไรผิดพลาด

พฤติกรรม	Strict	Opportunistic
ต้องเชื่อมต่อ TLS สำเร็จ	ต้อง	ไม่ต้อง
ตรวจตัวตนของ resolver	ตรวจ ด้วยชื่อโฮสต์	มักไม่ตรวจ
ถ้าพอร์ต 853 ถูกบล็อก	แปลงชื่อไม่ได้	ถอยไปใช้ DNS ธรรมดา
ป้องกันผู้สังเกตแบบเฉย ๆ	ได้	มักได้ ยกเว้นตอนถอย
ป้องกันผู้ปลอมตัวแบบลงมือ	ได้	ไม่น่าเชื่อถือ
ความเสี่ยง	ชื่อแปลงไม่ได้บนเครือข่ายเข้มงวด	ถูกลดระดับเงียบ ๆ จนอาจไม่รู้

ไม่มีแบบไหนดีกว่าในทุกกรณี Strict ให้คำสัญญาที่ชัดและความล้มเหลวที่มองเห็น Opportunistic ให้ความสะดวกและการสูญเสียการป้องกันอย่างเงียบ ๆ เมื่อเครือข่ายแทรกแซง ถ้าเลือก strict ให้เตรียมรับช่วงที่ "อินเทอร์เน็ตเหมือนพัง" บนเครือข่ายโรงแรมและสนามบินบ้าง ถ้าเลือก opportunistic อย่าสันนิษฐานว่าการป้องกันเปิดอยู่เสมอ

VPN ปกป้องอะไรที่ DoT ทำไม่ได้

VPN ต่างจาก DoT สี่ข้อ

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

เครื่องมือทั้งสองไม่ได้เข้ารหัสสิ่งที่คุณอ่านในหน้าเว็บ ซึ่งเป็นหน้าที่ของ HTTPS และทั้งสองไม่ได้ทำให้คุณไม่ระบุตัวตน

ใครเห็นอะไร ทีละจุด

ลองนึกถึงสี่รูปแบบสำหรับการถามชื่อและการเข้าเว็บเดียวกัน การตามเส้นทางแสดงว่าเครื่องมือแต่ละอย่างเปลี่ยนภาพอย่างไร

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

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

ใช้ทั้งสองอย่าง ผลลัพธ์สามแบบ

การรวม DoT กับ VPN ให้ผลได้สามแบบ และมีเพียงการทดสอบเท่านั้นที่บอกได้ว่าคุณเป็นแบบไหน

1. DNS ผ่านอุโมงค์ แอป VPN ส่งการถามชื่อทั้งหมด รวมถึงเซสชัน DoT ไปในอุโมงค์ เครือข่ายในพื้นที่มองไม่เห็นเลย เป็นกรณีทั่วไปที่ตั้งใจไว้
2. DoT เลี่ยงอุโมงค์ ระบบปฏิบัติการหรือเราเตอร์ที่ตั้ง DoT ไว้ส่งการถามที่เข้ารหัสตรงไปยัง resolver ที่เลือก นอก VPN การถามยังเข้ารหัส ผู้สังเกตเฉย ๆ จึงอ่านชื่อไม่ได้ แต่ resolver ที่คุณตั้งเห็นที่อยู่จริงของคุณ และการทดสอบ DNS leak จะแสดง resolver ที่ไม่คาดคิด ซึ่งไม่เหมือนการรั่วแบบข้อความธรรมดา แต่ก็ไม่ใช่สิ่งที่คุณตั้งใจ DNS Leak คืออะไร อธิบายความต่างนี้
3. DoT ถูกบล็อกในอุโมงค์หรือบนเครือข่าย โหมด strict ล้มเหลวและชื่อแปลงไม่ได้จนกว่าจะเปลี่ยนอะไรบางอย่าง โหมด opportunistic ถอยไปใช้ resolver ของ VPN อย่างเงียบ ๆ ซึ่งยอมรับได้

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

เมื่อใช้ VPN แล้ว DoT ยังมีที่ยืนตรงไหน

ง่ายที่จะคิดว่า VPN ทำให้ DoT ซ้ำซ้อน สำหรับทราฟฟิกในอุโมงค์มักเป็นเช่นนั้น แต่ DoT ยังมีประโยชน์ในบางกรณี

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

ตรวจการตั้งค่าของคุณเอง

การทดสอบสั้น ๆ ใช้เวลาไม่ถึงสิบนาที

1. จดจุดเริ่มต้น ปิด VPN แล้วเปิดหน้าทดสอบ DNS leak จด resolver ที่รายงาน
2. เปิด VPN แล้วทดสอบอีกครั้ง resolver ควรเปลี่ยนเป็นของ VPN หรือ resolver DoT ที่คุณตั้ง และไม่ควรเป็นค่าเริ่มต้นของผู้ให้บริการอินเทอร์เน็ตอีกต่อไป
3. เทียบกับสิ่งที่ตั้งใจ ถ้าคาดว่าจะเป็น resolver ของ VPN แต่เห็น resolver DoT ที่คุณตั้ง แปลว่า DoT เลี่ยงอุโมงค์ ตัดสินใจว่ารับได้ไหมหรือจะเปลี่ยนการตั้งค่า
4. ลองเครือข่ายที่เข้มงวด บนเครือข่ายโรงแรมหรือแขก ดูว่าโหมด strict เกิดอะไรขึ้น ถ้าการถามชื่อล้มเหลว ให้ใช้ข้อมูลมือถือสำหรับช่วงนั้น
5. ทดสอบการเชื่อมต่อใหม่ ตัดการเชื่อมต่อแล้วดูว่าการถามชื่อยังทำงานตามที่คุณคาดไว้

บทความศูนย์ช่วยเหลือ วิธีเช็กว่า VPN ทำงานอยู่ไหม รวมการตรวจอื่นที่ควรทำควบคู่กัน

แก้ปัญหาเมื่อ DoT กับ VPN ไม่ลงรอยกัน

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

สามสถานการณ์สั้น ๆ

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

นักศึกษาบน Wi-Fi มหาวิทยาลัย เธอตั้งแล็ปท็อปเป็น DoT แบบ strict บนเครือข่ายแขกของมหาวิทยาลัย พอร์ต 853 ถูกบล็อกและไม่มีอะไรโหลดเลย เธอสังเกตได้ทันที ใช้ข้อมูลมือถือของตัวเองในช่วงนั้น และคงการตั้งค่า DoT ไว้สำหรับเครือข่ายที่บ้าน

พนักงานทำงานทางไกลในร้านกาแฟ เขาเปิด VPN และรันการทดสอบ leak resolver ที่แสดงคือ DoT ที่เขาเลือก ไม่ใช่ของ VPN เขาตัดสินใจว่ารับได้เพราะเป็น resolver ที่เขาไว้ใจ แต่จดสิ่งที่เห็นไว้เพื่อตรวจอีกครั้งหลังมีการอัปเดต

สรุป

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

หากอยากลองแพ็กเกจ VPN สำหรับใช้ประจำวัน ดูตัวเลือกได้ที่หน้าราคา