Nhật ký trình phân giải DNS và nhật ký kết nối VPN: mỗi loại lưu gì
Trình phân giải ghi lại những tên được yêu cầu trả lời; VPN ghi lại các sự kiện đường hầm từ chính cách triển khai của mình. Một chính sách lưu trữ không bao trùm chính sách kia.
Nhật ký trình phân giải DNS và nhật ký kết nối VPN đều là bản ghi mạng, đều hữu ích và không thể thay thế cho nhau. Trình phân giải nhận những tên được yêu cầu trả lời. Điểm cuối VPN xử lý các kết nối đường hầm và ghi lại những gì cách triển khai của nó chọn ghi về chúng. Chúng có thể ở cùng một tòa nhà, do cùng một nhóm vận hành và nằm trong cùng một thông báo quyền riêng tư, nhưng vẫn mô tả những sự kiện khác nhau với định danh khác nhau và thời hạn lưu khác nhau. Đọc cái này như thể là cái kia chính là cách các cuộc điều tra đi chệch hướng.
Hai nhật ký, hai sự kiện
Một mục trong trình phân giải trả lời câu hỏi về việc đặt tên: máy khách này đã hỏi tên này vào thời điểm này, và câu trả lời là tên đó. Một mục trong VPN trả lời câu hỏi về kết nối: điểm ngang hàng này đã thiết lập hoặc mất một đường hầm, được cấp địa chỉ này và đã truyền khoảng chừng ấy dữ liệu trước khi biến mất. Không cái nào là bản ghi về những gì người dùng làm bên trong một phiên HTTPS, và không cái nào thay thế cái kia.
Sự khác biệt này có hệ quả thực tế đối với các lời hứa. Tuyên bố rằng nhà cung cấp VPN không ghi nhật ký hoạt động đường hầm không nói gì về trình phân giải mà họ cung cấp, và chính sách lưu trữ của trình phân giải không nói gì về ai đã kết nối với đường hầm. Mỗi khẳng định thuộc về nhà vận hành và hệ thống của chính nó.
Theo dõi truy vấn trước khi đọc bất kỳ nhật ký nào
Một truy vấn chỉ đến được trình phân giải nếu đường đi thực sự hỏi nó. Một ứng dụng có thể dùng trình phân giải của hệ điều hành, chạy ứng dụng khách DNS được mã hóa của riêng mình, hoặc đọc một câu trả lời đã lưu trong bộ nhớ đệm và không bao giờ gửi gì cả. Vì vậy một nhật ký trình phân giải không hiển thị gì không phải là bằng chứng rằng một tên chưa bao giờ được dùng; đó là bằng chứng rằng trình phân giải này không được hỏi.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pagerLệnh cuối cùng đó đọc nhật ký của chính trình phân giải cục bộ, không giống với nhật ký của máy chủ thượng nguồn. Nếu các truy vấn của bạn đi ra qua DNS over HTTPS tới một nhà cung cấp, stub cục bộ có thể không hiển thị gì trong khi nhà cung cấp có bản ghi đầy đủ, và nhà cung cấp là một nhà vận hành khác với chính sách khác.
Mỗi bản ghi có thể và không thể hiển thị gì
| 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 |
Liên kết chúng lại là công việc thực sự, và liên kết không phải lúc nào cũng khả thi. Một trình phân giải ghi lại địa chỉ của máy khách có thể được so sánh với một VPN cấp địa chỉ từ một nhóm đã biết, và phép so sánh đó tạo ra một mối liên hệ hợp lý giữa một tên được hỏi và một đường hầm, mà vẫn là mối liên hệ giữa hai bản ghi chứ không phải bản ghi về một con người.
DNS được mã hóa thay đổi phương thức vận chuyển, không thay đổi khả năng nhìn thấy tại điểm cuối. Trình phân giải vẫn nhận câu hỏi mà nó trả lời, như RFC 8484 làm rõ, và việc lưu trữ tại trình phân giải đó là một quyết định chính sách chứ không phải thuộc tính của giao thức.
Nơi DNS chia tách và bộ nhớ đệm làm rối câu chuyện
Nhiều trình phân giải là bình thường. Một thiết kế DNS chia tách gửi các tên nội bộ đến một máy chủ nội bộ và mọi thứ khác đến một máy chủ công cộng, vì vậy một cuộc điều tra có thể liên quan đến hai nhật ký chưa bao giờ được dự định kết hợp và hai thiết lập lưu trữ chưa bao giờ được dự định so sánh. Thấy truy vấn ở cả hai là bằng chứng thiết kế hoạt động, không phải bằng chứng rò rỉ.
Bộ nhớ đệm cắt theo hướng ngược lại. Một tên phổ biến có thể được trả lời từ bộ nhớ đệm trong nhiều giờ, vì vậy bản ghi của trình phân giải hiển thị truy vấn đầu tiên rồi không gì nữa, trong khi ứng dụng của người dùng vẫn vui vẻ phân giải cùng tên đó. Việc không có mục nào sau một thời điểm nhất định không có nghĩa là không ai dùng tên đó sau thời điểm ấy.
Lưu lượng nền là sự méo mó thứ ba. Điện thoại phân giải một tên đo từ xa khi khởi động, trình duyệt phân giải một miền gợi ý tìm kiếm, và trình cập nhật kết nối mỗi giờ đều xuất hiện trong nhật ký trình phân giải bên cạnh cái tên mà bạn thực sự quan tâm. Khối lượng trong nhật ký đó không phải là sự chú ý, và đếm truy vấn không phải là đếm lượt truy cập. Nhật ký trình phân giải là bản ghi các câu hỏi, và câu hỏi thì rẻ để tạo ra.
Hãy hỏi riêng các câu hỏi về lưu trữ
Với mỗi hệ thống, hãy hỏi ba câu: ai thu thập, thu thập cái gì, và giữ trong bao lâu. Sau đó hỏi ai có thể đọc nó và theo quy trình nào. Cuộc thảo luận của RFC 8484 về DNS over HTTPS là lời nhắc tốt rằng phương thức vận chuyển được mã hóa không loại bỏ điểm cuối, và tài liệu của chính nhà vận hành là tuyên bố đáng tin cậy duy nhất về những gì điểm cuối đó lưu giữ.
Khi một khẳng định về quyền riêng tư được đưa ra về “VPN”, hãy chia nó thành các thành phần trước khi chấp nhận: nhà vận hành đường hầm, trình phân giải mà đường hầm cung cấp, bất kỳ trình phân giải thượng nguồn nào mà những truy vấn đó chạm tới, và các ứng dụng trên thiết bị. Mỗi thành phần có câu trả lời riêng, và một khẳng định đúng cho một thành phần thường được lặp lại như thể nó bao trùm cả bốn.
Để khắc phục sự cố, hãy dùng cùng cách chia tách. Hỏi ứng dụng nào đã tạo truy vấn và trình phân giải nào đã trả lời, rồi xem nhật ký thực sự sở hữu sự kiện đó. Đoán từ nhật ký kia tiết kiệm một phút và tốn một buổi chiều.