DNSSEC กับ VPN: อันไหนซ่อนคำขอ DNS ของคุณ?

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

สามข้ออ้างที่หลอมรวมเป็นหนึ่ง

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

DNSSEC จัดการข้อแรกและไม่พูดอะไรเกี่ยวกับอีกสองข้อ DoT และ DoH จัดการข้อที่สองสำหรับช่วงไปยังตัวแก้ไข ส่วน VPN จัดการข้อที่สามและอาจส่งผลต่อข้อที่สองด้วย แต่เป็นเพียงผลข้างเคียงของปลายทางที่ทราฟฟิกไป

ทราฟฟิกของแอปพลิเคชันเป็นกรณีที่สี่ HTTPS ปกป้องและยืนยันการแลกเปลี่ยนเว็บระหว่างไคลเอนต์กับเว็บไซต์ และไม่มีชั้น DNS ใดแทนที่ได้

การตรวจสอบลายเซ็นทำอะไรได้และทำอะไรไม่ได้

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

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

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

ความลับมาจากไหนจริง ๆ

การขนส่งไปยังตัวแก้ไขที่เข้ารหัสจะห่อการแลกเปลี่ยน DNS ไว้ใน TLS ตัวแก้ไขจึงยังเห็นคำถาม แต่เส้นทางระหว่างคุณกับมันไม่เห็น สิ่งนี้ย้ายความไว้วางใจแทนที่จะลบออก คุณไว้วางใจตัวแก้ไขมากขึ้นและไว้วางใจเครือข่ายท้องถิ่นน้อยลง

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

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

ตรวจสอบการยืนยันและการขนส่งแยกกัน

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

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

dig +dnssec example.com | grep flags
dig +cd example.com | grep status
delv example.com

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

จะทำอย่างไรเมื่อ VPN ทำให้การค้นหาพัง

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

การปิดการตรวจสอบทั้งหมดเป็นก้าวแรกที่ผิด เพราะมันลบกลไกเดียวที่รายงานการแทรกแซงและไม่ได้แก้ไขตัวแก้ไขที่เข้าถึงไม่ได้ ก่อนอื่นให้จำกัดข้อบกพร่อง การแก้ไข การขนส่ง การตรวจสอบ แล้วจึงเป็นนโยบาย เฉพาะอย่างที่สามเป็นของ DNSSEC และเฉพาะอย่างที่สองเป็นของการขนส่งที่เข้ารหัส