การทดสอบ DNS รั่ว: ชื่อรีโซลเวอร์ไม่ใช่เส้นทาง

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

ตัดสินว่าคุณต้องการอะไรก่อนอ่านผลลัพธ์

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

การทดสอบที่ทำก่อนกำหนดนโยบายไม่ได้วัดอะไรเลย มันให้ชื่อรีโซลเวอร์โดยไม่มีจุดอ้างอิง

ชื่อรีโซลเวอร์ไม่ได้พิสูจน์ทั้งเส้นทางและผู้รับ

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

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

resolvectl status
resolvectl query example.com
dig +short example.com

split DNS ทำให้รีโซลเวอร์หลายตัวถูกต้อง

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

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

เปลี่ยนผลลัพธ์ให้เป็นการสอบสวน

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

ทำซ้ำหลังเชื่อมต่อใหม่หากอาการปรากฏตอนนั้น เพราะนโยบายที่ใช้ตอนเชื่อมต่ออาจสูญหายภายหลัง ใช้เอกสารของไคลเอนต์สำหรับข้อยกเว้น DNS ภายในแทนการเดาการตั้งค่า

แก้ความไม่ตรงกันที่พบ: ตัวเลือกเบราว์เซอร์ การตั้งค่า DNS ของ VPN หรือกฎ split DNS หากคำถามต้องหยุดเมื่ออุโมงค์ล้มเหลว kill switch เป็นการตั้งค่าแยก และการกำหนดค่า DNS เพียงอย่างเดียวไม่ให้สิ่งนั้น ข้อกำหนด RFC 8484 มีประโยชน์เมื่อต้องอธิบายว่ารีโซลเวอร์เข้ารหัสซ่อนอะไรและไม่ซ่อนอะไร