DNS çözümleyici günlükleri ile VPN bağlantı günlükleri: her biri neyi tutar

Bir DNS çözümleyici günlüğü ile bir VPN bağlantı günlüğü ikisi de ağ kayıtlarıdır, ikisi de yararlıdır ve birbirinin yerine geçmez. Çözümleyici, yanıtlaması istenen adları alır. VPN uç noktası tünel bağlantılarını yönetir ve uygulamasının bunlar hakkında kaydetmeyi seçtiği şeyi kaydeder. Aynı binada bulunabilir, aynı ekip tarafından işletilebilir ve aynı gizlilik bildirimi kapsamına girebilirler; yine de farklı tanımlayıcılara ve farklı saklamaya sahip farklı olayları tanımlarlar. Birini diğeriymiş gibi okumak, soruşturmaların rayından çıkma biçimidir.

İki günlük, iki olay

Çözümleyicideki bir kayıt adlandırmayla ilgili bir soruyu yanıtlar: bu istemci bu adı bu anda istedi ve yanıt buydu. VPN'deki bir kayıt bağlantılılıkla ilgili bir soruyu yanıtlar: bu eş bir tünel kurdu veya kaybetti, bu adres atandı ve kaybolmadan önce yaklaşık bu kadar veri aktardı. İkisi de kullanıcının bir HTTPS oturumu içinde ne yaptığının kaydı değildir ve hiçbiri diğerinin yerini tutmaz.

Bu ayrımın vaatler açısından pratik bir sonucu var. Bir VPN sağlayıcısının tünel etkinliğini kaydetmediği ifadesi, sunduğu çözümleyici hakkında hiçbir şey söylemez ve bir çözümleyicinin saklama ilkesi, tünele kimin bağlandığı hakkında hiçbir şey söylemez. Her iddia kendi işletmecisine ve kendi sistemine aittir.

Herhangi bir günlüğü okumadan önce sorguyu izleyin

Bir sorgu bir çözümleyiciye ancak yol gerçekten ona sorarsa ulaşır. Bir uygulama işletim sisteminin çözümleyicisini kullanabilir, kendi şifreli DNS istemcisini çalıştırabilir veya önbellekteki bir yanıtı okuyup hiçbir şey göndermeyebilir. Dolayısıyla hiçbir şey göstermeyen bir çözümleyici günlüğü, bir adın hiç kullanılmadığının kanıtı değildir; bu çözümleyiciye sorulmadığının kanıtıdır.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Son komut yerel çözümleyicinin kendi günlüğünü okur; bu, üst akış sunucusunun günlüğüyle aynı şey değildir. Sorgularınız DNS over HTTPS üzerinden bir sağlayıcıya çıkıyorsa, yerel stub hiçbir şey göstermeyebilirken sağlayıcıda tam kayıt olabilir ve sağlayıcı farklı ilkeye sahip başka bir işletmecidir.

Her kaydın neyi gösterip neyi gösteremeyeceği

Bunları birleştirmek asıl iştir ve birleştirmek her zaman mümkün değildir. İstemci adreslerini kaydeden bir çözümleyici, adresleri bilinen bir havuzdan atayan bir VPN ile karşılaştırılabilir ve bu karşılaştırma, sorgulanan bir ad ile bir tünel arasında makul bir bağlantı üretir; bu bağlantı iki kayıt arasındaki bir bağ olarak kalır, bir kişinin kaydı değildir.

Şifreli DNS taşımayı değiştirir, uç noktadaki görünürlüğü değil. Çözümleyici yanıtladığı soruyu hâlâ alır; RFC 8484 bunu açıkça gösterir ve o çözümleyicideki saklama protokolün özelliği değil, ilke kararıdır.

Bölünmüş DNS ve önbelleklerin hikâyeyi karıştırdığı yer

Birden çok çözümleyici normaldir. Bölünmüş DNS tasarımı iç adları iç sunucuya, geri kalan her şeyi genel bir sunucuya gönderir; böylece tek bir soruşturma, hiçbir zaman birleştirilmek üzere tasarlanmamış iki günlüğü ve hiçbir zaman karşılaştırılmak üzere tasarlanmamış iki saklama ayarını içerebilir. Her ikisinde de sorguları görmek, tasarımın çalıştığının kanıtıdır, sızıntının kanıtı değil.

Önbellekler diğer yönde keser. Popüler bir ad saatlerce önbellekten yanıtlanabilir; bu yüzden çözümleyicinin kaydı ilk sorguyu gösterir ve ardından hiçbir şey göstermez, oysa kullanıcının uygulaması aynı adı keyifle çözmeye devam eder. Belirli bir zamandan sonra kayıt olmaması, o zamandan sonra kimsenin adı kullanmadığı anlamına gelmez.

Arka plan trafiği üçüncü çarpıtmadır. Açılışta bir telemetri adını çözen telefon, bir arama önerisi alan adını çözen tarayıcı ve her saat başı bağlanan güncelleyici, hepsi bir çözümleyici günlüğünde gerçekten önemsediğiniz adın yanında görünür. O günlükteki hacim dikkat değildir ve sorguları saymak ziyaretleri saymak değildir. Çözümleyici günlüğü soruların kaydıdır ve soruları üretmek ucuzdur.

Saklama sorularını ayrı ayrı sorun

Her sistem için üç soru sorun: kim topluyor, ne toplanıyor ve ne kadar süre saklanıyor. Ardından bunu kimin okuyabileceğini ve hangi süreçle okuyabileceğini sorun. RFC 8484'ün DNS over HTTPS tartışması, şifreli taşımanın uç noktayı ortadan kaldırmadığına dair iyi bir hatırlatmadır ve işletmecinin kendi belgeleri, o uç noktanın neyi sakladığına dair tek güvenilir ifadedir.

Gizlilikle ilgili bir iddia “VPN” hakkında öne sürüldüğünde, kabul etmeden önce bileşenlere ayırın: tünel işletmecisi, tünelin sunduğu çözümleyici, bu sorguların ulaştığı herhangi bir üst akış çözümleyici ve cihazdaki uygulamalar. Her birinin kendi yanıtı vardır ve birine uyan bir iddia, dördünü de kapsıyormuş gibi rutin olarak tekrarlanır.

Sorun giderme için aynı bölmeyi kullanın. Hangi uygulamanın sorguyu yaptığını ve hangi çözümleyicinin yanıtladığını sorun, ardından o olaya gerçekten sahip olan günlüğe bakın. Diğer günlükten tahmin yürütmek bir dakika kazandırır ve bir öğleden sonraya mal olur.