VPN'siz şifreli DNS sorguyu saklar, adresinizi değil

Ev ağınızı gösteren bir DNS sızıntı testi, şifreli DNS'in başarısız olduğunun kanıtı değildir ve bir şeyin işe yaradığının da kanıtı değildir. Test tek bir soruya yanıt verir: bu sorgu bu ağdan hangi çözümleyiciye ulaştı. Bunun sorun olup olmadığı neyden ve kimden korunduğunuza bağlıdır.

Herhangi bir testi çalıştırmadan önce hedefi yazın.

Adım 1: gerçekten istediğiniz korumayı adlandırın

Üç hedef birbirine karışır. Yol üzerindeki bir gözlemcinin sorguları okumayı bırakmasını isteyebilirsiniz. Belirli bir çözümleyicinin bunları almayı bırakmasını isteyebilirsiniz. Ziyaret ettiğiniz sitelerin ev adresinizi görmeyi bırakmasını isteyebilirsiniz. Şifreli DNS birincisine hizmet eder, ikincisini kimin karşıladığını değiştirir ve üçüncüsü için hiçbir şey yapmaz.

Bir VPN üçüncüsüne ve sağlayıcıya bağlı olarak birincisine hizmet eder. Araçların hiçbiri diğerinin üst kümesi değildir.

Adım 2: bir çözümleyici seçin ve kimliğini doğrulayın

DNS over TLS sorguyu çözümleyiciyle bir TLS oturumuna sarar, DNS over HTTPS ise bir HTTP isteğine sarar; RFC 7858 ve RFC 8484 ikisini de açıklar ve hiçbiri tünel gerektirmez. İşletim açısından önemli olan, sertifikanın yapılandırdığınız ada karşı doğrulanmasıdır, çünkü yanlış tarafla şifreli bir oturum doğru tarafla düz metinden daha kötüdür. Bu, platformun sunduğu yerde katı mod demektir, doğrulama başarısız olduğunda geri çekilen fırsatçı bir mod değil. Ayarı güvenmeden önce oturumu doğrudan kontrol edin: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.

El sıkışma, yapılandırdığınız çözümleyiciyi adlandırmalı ve doğrulayabileceğiniz bir zincir döndürmelidir.

Adım 3: başarısızlık durumunda davranışa karar verin

Her uygulamanın erişilemeyen şifreli bir çözümleyici için bir politikası vardır ve o politika gizlilik kararıdır. Katı mod aramayı başarısız kılar, bu görünür ve sinir bozucudur. Fırsatçı mod düz metinle yeniden dener, bu görünmez ve tam da önemli olduğu gün amacı boşa çıkarır. Bilinçli seçin, sonra seçimi gereksinimin yanına kaydedin.

systemd-resolved üzerinde fırsatçı mod değil, DNSOverTLS=yes seçilir; diğer değer, opportunistic; Android'de ise otomatik yerine Private DNS ana makine adı modu kullanılır.

Gerçekte neyin yürürlükte olduğunu şununla kontrol edin: resolvectl status | grep -i -A1 "dns over tls", çünkü hiç yeniden yüklenmemiş bir drop-in dosyası hiçbir şeyi değiştirmez.

Adım 4: uygulamaların sistem çözümleyicisini izleyip izlemediğini kontrol edin

Kendi güvenli DNS ayarına sahip bir tarayıcı sistem yapılandırmasını tamamen atlar; gömülü çözümleyicisi olan bir konteyner çalışma zamanı veya sabit kodlu bir listeyi okuyan bir dil çalışma zamanı da aynısını yapar. Ya bunların sistemi izlemesini sağlayın ya da açıkça yapılandırıp bunu kaydedin. Sonra her birinin geri çekilme davranışına bakın, çünkü hepsi kapalı biçimde başarısız olmaz. Envanter pratikte kısadır: tarayıcı, konteyner çalışma zamanı ve ayrıca çalıştırdığınız herhangi bir VPN istemcisi.

Kuruluşun özel adları onaylanmış iç çözümleyicide kalır. Bunları bir test düzenli görünsün diye genel bir hizmete göndermek kasıtlı olarak başka bir sorun yaratır.

Adım 5: sızıntı testini gereksinime göre okuyun

Beklenmeyen bir çözümleyici bildiren test bir ipucudur, hüküm değil. Amaçladığınız şifreli çözümleyiciyi, uygulamaya özgü bir ayarı ya da bilmediğiniz bir düz metin geri çekilmesini gözlemlemiş olabilir. Bildirilen çözümleyiciyi adım 2'nin yapılandırdığıyla karşılaştırın ve sonucu adım 1'deki hedefle karşılaştırın.

Hedef sorguları yerel ağdan uzak tutmaksa, olağan çözümleyicinizi gösteren bir test gerçek bir bulgudur. Hedef gezinirken anonimlikse, hiçbir DNS ayarı bunu asla sağlamazdı.

Kabul satırını hedefin dilinde yazın: bu aramalar bu koşullar altında bu doğrulanmış çözümleyiciyi kullanır. Bundan daha genişi test edemeyeceğiniz bir iddiadır.