บันทึกของตัวแก้ไข DNS กับบันทึกการเชื่อมต่อ VPN: แต่ละอย่างเก็บอะไร
ตัวแก้ไขบันทึกชื่อที่ถูกขอให้ตอบ ส่วน VPN บันทึกเหตุการณ์ของอุโมงค์จากการใช้งานของตัวเอง นโยบายการเก็บรักษาหนึ่งไม่ได้ครอบคลุมอีกอันหนึ่ง
บันทึกของตัวแก้ไข DNS และบันทึกการเชื่อมต่อ VPN ต่างก็เป็นบันทึกเครือข่าย ทั้งคู่มีประโยชน์และใช้แทนกันไม่ได้ ตัวแก้ไขได้รับชื่อที่ถูกขอให้ตอบ จุดปลายทางของ VPN จัดการการเชื่อมต่ออุโมงค์และบันทึกสิ่งที่การใช้งานของมันเลือกจะบันทึกเกี่ยวกับสิ่งเหล่านั้น ทั้งสองอาจอยู่ในอาคารเดียวกัน ถูกดำเนินการโดยทีมเดียวกัน และอยู่ภายใต้ประกาศความเป็นส่วนตัวเดียวกัน แต่ก็ยังอธิบายเหตุการณ์ที่แตกต่างกันด้วยตัวระบุที่แตกต่างกันและการเก็บรักษาที่แตกต่างกัน การอ่านอันหนึ่งราวกับว่ามันเป็นอีกอันคือวิธีที่การสอบสวนออกนอกลู่
สองบันทึก สองเหตุการณ์
รายการในตัวแก้ไขตอบคำถามเกี่ยวกับการตั้งชื่อ: ไคลเอนต์นี้ขอชื่อนี้ในเวลานี้ และคำตอบคือสิ่งนี้ รายการใน VPN ตอบคำถามเกี่ยวกับการเชื่อมต่อ: เพียร์นี้สร้างหรือสูญเสียอุโมงค์ ได้รับที่อยู่นี้ และถ่ายโอนข้อมูลประมาณเท่านี้ก่อนจะหายไป ทั้งสองไม่ใช่บันทึกสิ่งที่ผู้ใช้ทำภายในเซสชัน HTTPS และไม่มีอันใดแทนที่อีกอัน
ความแตกต่างนี้มีผลในทางปฏิบัติต่อคำสัญญา ข้อความที่ว่าผู้ให้บริการ VPN ไม่บันทึกกิจกรรมของอุโมงค์ไม่ได้บอกอะไรเกี่ยวกับตัวแก้ไขที่มันแจกจ่าย และนโยบายการเก็บรักษาของตัวแก้ไขก็ไม่ได้บอกอะไรเกี่ยวกับใครที่เชื่อมต่อกับอุโมงค์ แต่ละข้อกล่าวอ้างเป็นของผู้ดำเนินการและระบบของตัวเอง
ติดตามคำถามก่อนอ่านบันทึกใดๆ
คำถามจะไปถึงตัวแก้ไขก็ต่อเมื่อเส้นทางถามมันจริงๆ แอปพลิเคชันอาจใช้ตัวแก้ไขของระบบปฏิบัติการ รันไคลเอนต์ DNS ที่เข้ารหัสของตัวเอง หรืออ่านคำตอบที่แคชไว้และไม่ส่งอะไรเลย ดังนั้นบันทึกของตัวแก้ไขที่ไม่แสดงอะไรจึงไม่ใช่หลักฐานว่าชื่อไม่เคยถูกใช้ แต่เป็นหลักฐานว่าตัวแก้ไขนี้ไม่ถูกถาม
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerคำสั่งสุดท้ายนั้นอ่านบันทึกของตัวแก้ไขภายในเอง ซึ่งไม่เหมือนกับบันทึกของเซิร์ฟเวอร์ต้นทาง หากคำถามของคุณออกผ่าน DNS over HTTPS ไปยังผู้ให้บริการ สตับภายในอาจไม่แสดงอะไรในขณะที่ผู้ให้บริการมีบันทึกที่สมบูรณ์ และผู้ให้บริการเป็นผู้ดำเนินการอีกรายที่มีนโยบายต่างกัน
แต่ละบันทึกแสดงอะไรได้และแสดงอะไรไม่ได้
| Record | Typically shows | Does not show |
|---|---|---|
| Resolver log | Queried name, client address, time, response | Which page was fetched, or what the tunnel did |
| VPN connection log | Peer identity, assigned address, connect and disconnect times, volume | Which name the application asked for |
| Application or proxy log | Requests, status codes, sometimes full URLs | Resolved addresses for every dependency |
การเชื่อมโยงทั้งสองเข้าด้วยกันคืองานจริง และการเชื่อมโยงไม่ใช่เรื่องที่เป็นไปได้เสมอ ตัวแก้ไขที่บันทึกที่อยู่ของไคลเอนต์สามารถนำไปเปรียบเทียบกับ VPN ที่จัดสรรที่อยู่จากพูลที่รู้จัก และการเปรียบเทียบนั้นสร้างความเชื่อมโยงที่เป็นไปได้ระหว่างชื่อที่ถูกถามกับอุโมงค์ ซึ่งยังคงเป็นความเชื่อมโยงระหว่างสองบันทึกไม่ใช่บันทึกของบุคคล
DNS ที่เข้ารหัสเปลี่ยนการขนส่ง ไม่ใช่การมองเห็นที่จุดปลายทาง ตัวแก้ไขยังคงได้รับคำถามที่มันตอบ ตามที่ RFC 8484 ทำให้ชัดเจน และการเก็บรักษาที่ตัวแก้ไขนั้นเป็นการตัดสินใจเชิงนโยบายไม่ใช่คุณสมบัติของโปรโตคอล
ที่ซึ่ง DNS แยกส่วนและแคชทำให้เรื่องสับสน
ตัวแก้ไขหลายตัวเป็นเรื่องปกติ การออกแบบ DNS แยกส่วนส่งชื่อภายในไปยังเซิร์ฟเวอร์ภายในและส่งอย่างอื่นไปยังเซิร์ฟเวอร์สาธารณะ ดังนั้นการสอบสวนครั้งเดียวอาจเกี่ยวข้องกับบันทึกสองฉบับที่ไม่เคยถูกออกแบบให้รวมกันและตั้งค่าการเก็บรักษาสองชุดที่ไม่เคยถูกออกแบบให้เปรียบเทียบกัน การเห็นคำถามในทั้งสองเป็นหลักฐานว่าการออกแบบทำงาน ไม่ใช่หลักฐานของการรั่วไหล
แคชตัดไปในทิศทางตรงกันข้าม ชื่อยอดนิยมอาจได้รับคำตอบจากแคชเป็นชั่วโมงๆ ดังนั้นบันทึกของตัวแก้ไขจึงแสดงคำถามแรกแล้วไม่แสดงอะไรอีก ขณะที่แอปพลิเคชันของผู้ใช้ยังคงแก้ชื่อเดิมอย่างมีความสุข การไม่มีรายการหลังจากเวลาหนึ่งไม่ได้หมายความว่าไม่มีใครใช้ชื่อนั้นหลังจากเวลานั้น
ทราฟฟิกเบื้องหลังคือความเบี่ยงเบนที่สาม โทรศัพท์ที่แก้ชื่อเทเลเมทรีเมื่อบูต เบราว์เซอร์ที่แก้โดเมนคำแนะนำการค้นหา และตัวอัปเดตที่ติดต่อทุกชั่วโมง ล้วนปรากฏในบันทึกของตัวแก้ไขข้างชื่อที่คุณสนใจจริง ปริมาณในบันทึกนั้นไม่ใช่ความสนใจ และการนับคำถามไม่ใช่การนับการเข้าชม บันทึกของตัวแก้ไขคือบันทึกของคำถาม และคำถามนั้นสร้างได้ถูก
ถามคำถามเกี่ยวกับการเก็บรักษาแยกกัน
สำหรับแต่ละระบบ ให้ถามสามคำถาม: ใครเก็บ เก็บอะไร และเก็บไว้นานเท่าใด จากนั้นถามว่าใครอ่านได้และภายใต้กระบวนการใด การอภิปรายใน RFC 8484 เกี่ยวกับ DNS over HTTPS เป็นเครื่องเตือนใจที่ดีว่าการขนส่งที่เข้ารหัสไม่ได้ลบจุดปลายทาง และเอกสารของผู้ดำเนินการเองคือข้อความเดียวที่เชื่อถือได้เกี่ยวกับสิ่งที่จุดปลายทางนั้นเก็บ
เมื่อมีการกล่าวอ้างเกี่ยวกับความเป็นส่วนตัวเกี่ยวกับ “VPN” ให้แยกเป็นองค์ประกอบก่อนยอมรับ: ผู้ดำเนินการอุโมงค์ ตัวแก้ไขที่อุโมงค์แจกจ่าย ตัวแก้ไขต้นทางใดๆ ที่คำถามเหล่านั้นไปถึง และแอปพลิเคชันบนอุปกรณ์ แต่ละอย่างมีคำตอบของตัวเอง และข้อกล่าวอ้างที่ถูกต้องสำหรับอย่างหนึ่งมักถูกกล่าวซ้ำราวกับว่าครอบคลุมทั้งสี่
สำหรับการแก้ปัญหา ให้ใช้การแบ่งเดียวกัน ถามว่าแอปพลิเคชันใดสร้างคำถามและตัวแก้ไขใดตอบ แล้วดูบันทึกที่เป็นเจ้าของเหตุการณ์นั้นจริงๆ การเดาจากบันทึกอื่นประหยัดหนึ่งนาทีและทำให้เสียเวลาหนึ่งบ่าย