DNS บน TLS พร้อม VPN: ส่วนใดได้รับการป้องกัน

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

การตรวจสอบสี่ข้อเป็นตัวตัดสินว่าการจัดวางที่คุณมีคือสิ่งที่คุณคิดว่าคุณมีหรือไม่

การตรวจสอบ 1: การเข้ารหัสครอบคลุมอะไร

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

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

การตรวจสอบ 2: แบบสอบถามไปเส้นทางไหน

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

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

การตรวจสอบ 3: ชื่อภายใน

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

เก็บ resolver ภายในไว้สำหรับคำต่อท้ายภายใน และเข้ารหัสช่วงนั้นหากนโยบายกำหนด แทนที่จะแทนที่ด้วยผู้ให้บริการสาธารณะ

การตรวจสอบ 4: พฤติกรรมเมื่อล้มเหลว

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

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

เชื่อใบรับรอง ไม่ใช่คำตอบ

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

คำตอบจาก resolver ที่คุณพิสูจน์ตัวตนไม่ได้เป็นข้อกล่าวอ้าง ไม่ใช่ผลลัพธ์

สิ่งนี้ยังไม่ได้อธิบายอะไร

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

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