Log Resolver DNS vs Log Koneksi VPN: Apa yang Disimpan Masing-masing
Resolver mencatat nama yang diminta dijawabnya; VPN mencatat peristiwa terowongan dari implementasinya sendiri. Satu kebijakan penyimpanan tidak mencakup yang lain.
Log resolver DNS dan log koneksi VPN keduanya catatan jaringan, keduanya berguna, dan tidak dapat dipertukarkan. Resolver menerima nama yang diminta dijawabnya. Titik akhir VPN menangani koneksi terowongan dan mencatat apa pun yang dipilih implementasinya untuk dicatat tentangnya. Keduanya bisa berada di gedung yang sama, dioperasikan tim yang sama, dan tercakup pemberitahuan privasi yang sama, namun tetap menggambarkan peristiwa berbeda dengan pengenal berbeda dan penyimpanan berbeda. Membaca yang satu seolah-olah yang lain adalah cara penyelidikan melenceng.
Dua log, dua peristiwa
Entri resolver menjawab pertanyaan tentang penamaan: klien ini meminta nama ini pada waktu ini, dan jawabannya adalah ini. Entri VPN menjawab pertanyaan tentang konektivitas: peer ini membangun atau kehilangan terowongan, diberi alamat ini, dan mentransfer kira-kira sebanyak ini data sebelum menghilang. Keduanya bukan catatan tentang apa yang dilakukan pengguna di dalam sesi HTTPS, dan keduanya tidak menggantikan yang lain.
Perbedaan ini punya konsekuensi praktis bagi janji. Pernyataan bahwa penyedia VPN tidak mencatat aktivitas terowongan tidak mengatakan apa pun tentang resolver yang diberikannya, dan kebijakan penyimpanan resolver tidak mengatakan apa pun tentang siapa yang terhubung ke terowongan. Setiap klaim milik operatornya sendiri dan sistemnya sendiri.
Ikuti kueri sebelum membaca salah satu log
Kueri mencapai resolver hanya jika jalurnya benar-benar menanyakannya. Aplikasi dapat memakai resolver sistem operasi, menjalankan klien DNS terenkripsinya sendiri, atau membaca jawaban dari cache dan tidak pernah mengirim apa pun. Jadi log resolver yang tidak menunjukkan apa pun bukan bukti bahwa suatu nama tidak pernah dipakai; itu bukti bahwa resolver ini tidak ditanyai.
resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager
Perintah terakhir itu membaca jurnal resolver lokal itu sendiri, yang tidak sama dengan log server hulu. Jika kueri Anda keluar melalui DNS over HTTPS ke penyedia, stub lokal bisa tidak menunjukkan apa pun sementara penyedia memiliki catatan lengkap, dan penyedia adalah operator lain dengan kebijakan lain.
Apa yang dapat dan tidak dapat ditunjukkan setiap catatan
| 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 |
Menggabungkannya adalah pekerjaan sebenarnya, dan menggabungkannya tidak selalu mungkin. Resolver yang mencatat alamat klien dapat dibandingkan dengan VPN yang menetapkan alamat dari kumpulan yang diketahui, dan perbandingan itu menghasilkan kaitan yang masuk akal antara nama yang ditanyakan dan terowongan, yang tetap merupakan kaitan antara dua catatan, bukan catatan tentang seseorang.
DNS terenkripsi mengubah transportasi, bukan visibilitas di titik akhir. Resolver tetap menerima pertanyaan yang dijawabnya, sebagaimana RFC 8484 perjelas, dan penyimpanan di resolver itu adalah keputusan kebijakan, bukan sifat protokol.
Di mana DNS terpisah dan cache mengaburkan cerita
Beberapa resolver adalah hal normal. Rancangan DNS terpisah mengirim nama internal ke server internal dan sisanya ke server publik, sehingga satu penyelidikan dapat melibatkan dua log yang tidak pernah dimaksudkan untuk digabungkan dan dua pengaturan penyimpanan yang tidak pernah dimaksudkan untuk dibandingkan. Melihat kueri di keduanya adalah bukti rancangan itu bekerja, bukan bukti kebocoran.
Cache memotong ke arah lain. Nama populer dapat dijawab dari cache selama berjam-jam, sehingga catatan resolver menunjukkan kueri pertama lalu tidak ada apa-apa, sementara aplikasi pengguna terus dengan senang memecahkan nama yang sama. Tidak adanya entri setelah waktu tertentu bukan berarti tidak ada yang memakai nama itu setelah waktu tersebut.
Lalu lintas latar adalah distorsi ketiga. Ponsel yang memecahkan nama telemetri saat boot, peramban yang memecahkan domain saran pencarian, dan pembaru yang melapor setiap jam semuanya muncul di log resolver bersama nama yang benar-benar Anda pedulikan. Volume dalam log itu bukan perhatian, dan menghitung kueri bukan menghitung kunjungan. Log resolver adalah catatan pertanyaan, dan pertanyaan murah dibuat.
Ajukan pertanyaan penyimpanan secara terpisah
Untuk setiap sistem, ajukan tiga pertanyaan: siapa yang mengumpulkan, apa yang dikumpulkan, dan berapa lama itu disimpan. Lalu tanyakan siapa yang boleh membacanya dan dengan proses apa. Pembahasan RFC 8484 tentang DNS over HTTPS adalah pengingat baik bahwa transportasi terenkripsi tidak menghapus titik akhir, dan dokumentasi operator itu sendiri adalah satu-satunya pernyataan tepercaya tentang apa yang disimpan titik akhir tersebut.
Ketika klaim tentang privasi dibuat tentang “VPN”, pecahlah menjadi komponen sebelum menerimanya: operator terowongan, resolver yang diberikan terowongan, resolver hulu mana pun yang dicapai kueri itu, dan aplikasi di perangkat. Masing-masing punya jawabannya sendiri, dan klaim yang akurat untuk satu rutin diulang seolah-olah mencakup keempatnya.
Untuk pemecahan masalah, gunakan pembagian yang sama. Tanyakan aplikasi mana yang membuat kueri dan resolver mana yang menjawabnya, lalu lihat log yang benar-benar memiliki peristiwa itu. Menebak dari log lain menghemat satu menit dan memakan satu sore.