DNS ที่เข้ารหัสโดยไม่มี VPN ซ่อนคำถาม ไม่ใช่ที่อยู่ของคุณ
DNS ที่เข้ารหัสปกป้องการแลกเปลี่ยนหนึ่งครั้งกับรีโซลเวอร์หนึ่งตัว ไม่ได้ซ่อนที่อยู่ของคุณและไม่ได้ทำให้รีโซลเวอร์มองไม่เห็น ดังนั้นกำหนดเป้าหมายก่อนอ่านการทดสอบการรั่วไหล
การทดสอบการรั่วไหลของ DNS ที่แสดงเครือข่ายบ้านของคุณไม่ใช่หลักฐานว่า DNS ที่เข้ารหัสล้มเหลว และไม่ใช่หลักฐานว่ามีอะไรทำงาน การทดสอบตอบคำถามเดียว: คำถามนี้ไปถึงรีโซลเวอร์ใดจากเครือข่ายนี้ การที่มันเป็นปัญหาหรือไม่ขึ้นอยู่กับว่าคุณกำลังปกป้องอะไรและจากใคร
เขียนเป้าหมายก่อนเรียกใช้การทดสอบใด ๆ
ขั้นตอนที่ 1: ตั้งชื่อการปกป้องที่คุณต้องการจริง ๆ
เป้าหมายสามข้อปนกัน คุณอาจต้องการให้ผู้สังเกตบนเส้นทางหยุดอ่านคำถาม คุณอาจต้องการให้รีโซลเวอร์บางตัวหยุดรับคำถามเหล่านั้นคุณอาจต้องการให้เว็บไซต์ที่คุณเยี่ยมชมหยุดเห็นที่อยู่บ้านของคุณ. DNS ที่เข้ารหัสให้บริการเป้าหมายแรก เปลี่ยนว่าใครทำให้เป้าหมายที่สองสำเร็จ และไม่ทำอะไรเลยกับเป้าหมายที่สาม
VPN ให้บริการเป้าหมายที่สาม และขึ้นอยู่กับผู้ให้บริการก็ให้บริการเป้าหมายแรกด้วย ทั้งสองเครื่องมือไม่มีอันใดเป็นเซตใหญ่ของอีกอัน
ขั้นตอนที่ 2: เลือกรีโซลเวอร์และตรวจสอบตัวตนของมัน
DNS over TLS ห่อคำถามไว้ในเซสชัน TLS กับรีโซลเวอร์ และ DNS over HTTPS ห่อไว้ในคำขอ HTTP; RFC 7858 และ RFC 8484 อธิบายทั้งสองวิธี และไม่จำเป็นต้องใช้อุโมงค์ สิ่งที่สำคัญในทางปฏิบัติคือใบรับรองต้องถูกตรวจสอบกับชื่อที่คุณกำหนดไว้ เพราะเซสชันที่เข้ารหัสกับฝ่ายผิดนั้นแย่กว่าข้อความธรรมดากับฝ่ายที่ถูก หมายความว่าต้องใช้โหมดเข้มงวดในที่ที่แพลตฟอร์มมีให้ ไม่ใช่โหมดฉวยโอกาสที่ถอยกลับเมื่อการตรวจสอบล้มเหลว ตรวจสอบเซสชันโดยตรงก่อนเชื่อการตั้งค่า:openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.
การจับมือควรระบุชื่อรีโซลเวอร์ที่คุณกำหนดไว้และคืนห่วงโซ่ที่คุณตรวจสอบได้
ขั้นตอนที่ 3: ตัดสินพฤติกรรมเมื่อล้มเหลว
ทุกการใช้งานมีนโยบายสำหรับรีโซลเวอร์ที่เข้ารหัสซึ่งเข้าถึงไม่ได้ และนโยบายนั้นคือการตัดสินใจด้านความเป็นส่วนตัว โหมดเข้มงวดทำให้การค้นหาล้มเหลว ซึ่งมองเห็นได้และน่ารำคาญ โหมดฉวยโอกาสลองใหม่ด้วยข้อความธรรมดา ซึ่งมองไม่เห็นและทำลายวัตถุประสงค์ในวันที่สำคัญที่สุด เลือกอย่างตั้งใจ แล้วบันทึกทางเลือกไว้ข้างข้อกำหนด
บน systemd-resolved นั่นหมายถึงDNSOverTLS=yesแทนopportunistic; บน Android หมายถึงโหมดชื่อโฮสต์ของ Private DNS แทนโหมดอัตโนมัติ
ตรวจสอบว่าอะไรมีผลจริงด้วยresolvectl status | grep -i -A1 "dns over tls"เพราะไฟล์ drop-in ที่ไม่เคยโหลดใหม่จะไม่เปลี่ยนอะไรเลย
ขั้นตอนที่ 4: ตรวจสอบว่าแอปพลิเคชันทำตามรีโซลเวอร์ของระบบ
เบราว์เซอร์ที่มีการตั้งค่า DNS ที่ปลอดภัยของตัวเองข้ามการกำหนดค่าของระบบทั้งหมด และรันไทม์คอนเทนเนอร์ที่มีรีโซลเวอร์ฝังอยู่หรือรันไทม์ภาษาที่อ่านรายการที่เขียนตายตัวก็เช่นกัน จะทำให้พวกมันทำตามระบบหรือกำหนดค่าให้ชัดเจนแล้วบันทึกไว้ จากนั้นดูพฤติกรรมการถอยกลับของแต่ละตัว เพราะไม่ใช่ทั้งหมดที่จะล้มเหลวแบบปิด ทะเบียนในทางปฏิบัติสั้น: เบราว์เซอร์ รันไทม์คอนเทนเนอร์ และไคลเอนต์ VPN ใด ๆ ที่คุณเรียกใช้ด้วย
ชื่อส่วนตัวขององค์กรยังคงอยู่ในรีโซลเวอร์ภายในที่ได้รับอนุมัติ การส่งชื่อเหล่านั้นไปยังบริการสาธารณะเพื่อให้การทดสอบดูเรียบร้อยเป็นการสร้างปัญหาอื่นโดยเจตนา
ขั้นตอนที่ 5: อ่านการทดสอบการรั่วไหลเทียบกับข้อกำหนด
การทดสอบที่รายงานรีโซลเวอร์ที่ไม่คาดคิดเป็นเพียงเบาะแส ไม่ใช่คำตัดสิน. มันอาจสังเกตรีโซลเวอร์ที่เข้ารหัสที่คุณตั้งใจ การตั้งค่าเฉพาะแอป หรือการถอยกลับไปใช้ข้อความธรรมดาที่คุณไม่รู้ เปรียบเทียบรีโซลเวอร์ที่รายงานกับสิ่งที่ขั้นตอนที่ 2 กำหนดไว้ และเปรียบเทียบผลลัพธ์กับเป้าหมายจากขั้นตอนที่ 1
หากเป้าหมายคือการเก็บคำถามให้ห่างจากเครือข่ายท้องถิ่น การทดสอบที่แสดงรีโซลเวอร์ปกติของคุณคือสิ่งที่พบจริง หากเป้าหมายคือการไม่ระบุตัวตนขณะท่องเว็บ ไม่มีการตั้งค่า DNS ใดที่จะให้สิ่งนั้นได้
เขียนบรรทัดการยอมรับในภาษาของเป้าหมาย: การค้นหาเหล่านี้ใช้รีโซลเวอร์ที่ตรวจสอบแล้วนี้ภายใต้เงื่อนไขเหล่านี้ สิ่งใดที่กว้างกว่านี้คือข้ออ้างที่คุณทดสอบไม่ได้