Genel DNS çözümleyicisi seçme rehberi

 (evilbit.de)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Genel DNS çözümleyicilerinde yalnızca hız değil, gizlilik, filtreleme, yargı alanı, işletmeci, şifreli aktarım da birlikte değerlendirilmelidir; bu rehber 30 küresel hizmeti gereksinimlere göre karşılaştırır
  • Seçim aracı DoH·DoT·DoQ·DNSCrypt, DNSSEC doğrulaması, IPv6, yargı alanı, işletmeci türü ve EDNS Client Subnet’i katı filtreler olarak kullanır; amaca göre öncelikleri puanlar
  • Tarayıcı tabanlı DoH gecikme testi, mevcut konumunuzdan göreli hızı gösterir; ancak TLS/HTTP ek yükünü içerir ve yalnızca düz metin DNS sunan çözümleyicileri ölçemez
  • Şifreli DNS, aradaki tarafların dinleme ve değiştirme riskini azaltır; ancak seçtiğiniz çözümleyici sağlayıcısı sorgulanan alan adlarını görebildiği için kayıtsız çalışma politikası ve oblivious tasarımlar da dikkate alınmalıdır
  • Pratik seçimde DNSSEC, ECS’nin hız-gizlilik takası, DoQ performansı, DNSCrypt özellikleri, trafik analizi sınırlamaları, standartlara uyum farkları, yargı alanı ve merkezileşme riski birlikte değerlendirilmelidir

Seçim aracının karşılaştırdığı ölçütler

  • Genel DNS çözümleyicileri, kullanıcının önemli gördüğü koşulları işaretleyerek bulmasına olanak veren bir yöntemle karşılaştırılır
  • Katı filtre olarak kullanılan koşullar
    • Şifreli aktarım: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
    • DNSSEC doğrulama desteği
    • IPv6 çözümleyici adresi sunma
    • İşletmecinin yargı alanı
    • İşletmeci türü: kâr amacı gütmeyen·topluluk·kamu yararı, ticari, tümü
    • EDNS Client Subnet(ECS): kullanılmıyor, kullanılıyor, fark etmez
  • Öncelik puanlamasına giren maddeler
    • En yüksek gizlilik ve kayıtsız ya da asgari kayıt
    • Kötü amaçlı yazılım·phishing engelleme
    • Reklam·izleyici engelleme
    • Ebeveyn denetimi ve yetişkin içerik engelleme
    • Yayımlanan DNS yanıtlarını aynen döndüren filtresiz çalışma
    • Hesap üzerinden özelleştirilmiş engelleme listeleri·kurallar
    • Küresel Anycast tabanlı düşük gecikmeli hız
    • Ticari olmayan işletmeci

Mevcut konuma göre DoH hız testi

  • Yerleşik test, tarayıcıdan her bir DoH destekli çözümleyiciye gidiş-dönüş süresini ölçer
  • Yalnızca düz metin DNS destekleyen çözümleyiciler bu yöntemle test edilemez
  • Sonuçlar göreli referans değerlerdir; TLS ve HTTP ek yükünü içerdiği için birden fazla kez çalıştırılması varsayılır
  • Tarayıcı her çözümleyiciye doğrudan sorgu gönderdiğinden kullanıcının IP adresi ilgili çözümleyiciye ifşa olur
  • Test uygulaması, Silviu Stroe’nun açık kaynak DNS Speed Test projesinden fikir almıştır; ancak bağımsız bir uygulamadır ve yalnızca sayfa HTTPS üzerinden sunulduğunda çalışır

Performans ve şifreli aktarım farkları

  • DoH ve DoT gibi şifreli aktarımlar sorgu başına gecikme ekler; ancak toplam sayfa yükleme süresi çoğu durumda düz metin DNS’e yakın olur ve DoH ek yükü de gerçek ortamlarda küçük görünür
  • Kayıplı veya yüksek gecikmeli bağlantılarda düz metin Do53 hâlâ avantajlıdır
  • Performans sağlayıcıya ve bölgeye göre değiştiğinden en hızlı çözümleyici kullanıcının konumuna bağlıdır
  • Şifreli DNS’in büyük ölçekli uçtan uca ölçümlerinde sorguların aktarım sırasında ele geçirilme veya değiştirilme olasılığı düz metin DNS’e göre çok daha düşüktü ve ek yük küçüktü
  • Ancak ilgili araştırmada DoT sağlayıcılarının yaklaşık %25’i geçersiz TLS sertifikası sunduğu için işletim kalitesi iyi bir sağlayıcı seçmek önemlidir

Gizliliğin pratik sınırları

  • Şifreli DNS, sorguları ağ üzerinde gizler; ancak seçilen çözümleyici sağlayıcısı sorguladığınız tüm alan adlarını görebilir
  • Bu bir sorunsa kayıtsız çalışan bir işletmeci seçilmeli veya proxy’nin kimlik ile sorguyu ayırdığı ODoH gibi oblivious tasarımlar düşünülmelidir
  • Cloudflare ve Apple, ODoH dağıtan örneklerdir
  • Şifreli DNS tek başına ziyaret edilen siteleri tamamen gizlemez
    • DoH kullanılsa bile trafik analiziyle ziyaret edilen alan adı yüksek doğrulukla belirlenebilir
    • Standart EDNS padding de bunu tamamen engelleyemez
    • Bu tehdit modeli sizin için geçerliyse yalnızca padding’e güvenmeyip Tor veya oblivious tasarımları birlikte kullanmalısınız

DNSSEC, ECS, yargı alanı

  • Yalnızca DNSSEC doğrulaması yapan çözümleyiciler sahte kayıtlara karşı korur
  • Google, Cloudflare ve Quad9 DNSSEC’i doğrular ve ilk kök anahtar KSK rollover sürecini kullanıcı kesintisi olmadan yönetmiştir
  • Bütünlük önemliyse DNSSEC doğrulaması zorunlu koşul olarak görülmelidir
  • EDNS Client Subnet(ECS) daha iyi coğrafi yönlendirme için IP’nin bir kısmını CDN’e gönderir
    • Google ve OpenDNS daha hassas CDN eşlemesi için ECS gönderir
    • Cloudflare ve standart Quad9 gizlilik için ECS’yi kapatır
  • İşletmecinin yasal konumu, zorla uygulatılabilecek önlemleri ve kayıtları etkiler
  • Az sayıda sağlayıcı, dünya genelindeki recursive DNS trafiğinin büyük bir bölümünü işler
  • ABD NSA, harici çözümleyicilerin dahili DNS filtreleme ve denetimlerini atladığı konusunda uyardığından, kolaylık ile kontrol arasındaki denge değerlendirilmelidir

DoQ ve DNSCrypt

  • 2022’deki DoQ ölçümlerinde DNS-over-QUIC, yanıt süresi açısından hem DoT’yi hem DoH’yi geride bıraktı
  • Ancak QUIC’in adres doğrulama sınırlaması nedeniyle el sıkışmalarının yaklaşık %40’ı yavaşladı
  • İstemci ve çözümleyici ikisi de destekliyorsa DoQ tercih edilecek şifreli seçenek olur
    • Destek örnekleri: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, Çin’in başlıca hizmetleri
  • DNSCrypt, DoH, DoT ve DoQ’dan daha eski bir şifreleme seçeneğidir; sürüm 2 2013’te çıktı
  • DNSCrypt, çözümleyicinin önceden paylaşılan açık anahtarıyla ilk paketten itibaren şifreleme yaptığı için düz metin ana makine adı sorgusu ve sertifika otoritesi bağımlılığı yoktur
  • 2019’daki Anonymized DNS modu istemci IP’sini de gizler
  • Karşılaştırmadaki DNSCrypt sağlayıcıları Quad9, OpenDNS, AdGuard, NextDNS, Control D ve Yandex’tir
  • Güvenilir kullanım rakamları yetersizdir; APNIC Labs gibi büyük ölçekli ölçümler DoH ve DoT’yi izler, ancak DNSCrypt’i izlemez

Çözümleyici uygulama kalitesi ve operasyonel veriler

  • 2023 tarihli Extended DNS Errors araştırmasında büyük çözümleyiciler, tanılama hata raporlamasında test vakalarının %94’ünde tutarsızlık gösterdi
  • Cloudflare bu araştırmada en hassas hata raporlamasını gösterdi
  • Çözümleyiciye göre uygulama kalitesi ve standartlara uyum farkları, sorun giderme ve güvenilirliği etkiler
  • Başvurulabilecek operasyonel·topluluk verileri
    • ICANN Identifier Technology Health Indicators: DNSSEC doğrulayan çözümleyici oranını ve çözümleyici yoğunlaşmasını izler
    • DNS-OARC workshop talks ve past-event archive: şifreli DNS, çözümleyici performansı ve ölçüm konularında işletmeci·araştırmacı sunumları
    • APNIC Labs measurements: ülke bazında DNSSEC doğrulama oranı, genel çözümleyici kullanımı, DoH·DoT benimseme verileri

Küçük ölçekli·topluluk·bölgesel çözümleyiciler

  • Karşılaştırma tablosu dışında hobi, topluluk ve ülkeye özel uzmanlaşmış çözümleyiciler de vardır; kullanmadan önce güncel durum ve politikaları kontrol edilmelidir
  • Avrupa maddeleri European Alternatives üzerinde derlenmiştir
  • Güçlü sansür veya yaptırımların olduğu bölgelerdeki çözümleyiciler, yerel içerik kurallarını uygulayabilir ya da coğrafi engellemeyi aşmak için işletiliyor olabilir; bu nedenle daha dikkatli olunmalıdır
  • Örnek hizmetler
    • DNS4all: tarafsızlık ve performansa önem veren Avrupa merkezli filtresiz çözümleyici
    • BlahDNS: küçük ölçekli bölgesel sunucularda çalışan açık kaynak hobi reklam engelleme projesi, DoH·DoT·DoQ desteği
    • LibreDNS: LibreOps’un topluluk çözümleyicisi, reklam engelleme ve kayıtsız politika, DoH·DoT desteği
    • Dismail.de: gizlilik odaklı Alman topluluk çözümleyicisi, kayıtsız, DoH·DoT desteği
    • IIJ Public DNS: Internet Initiative Japan’ın herkese açık DoH·DoT çözümleyicisi, çocukların cinsel istismarıyla ilgili alan adlarını engeller
    • DNS for Family: yetişkin içerik, kumar, kötü amaçlı yazılım, reklam·izleyici ve güvenli aramayı içeren aile filtrelemeli DoH
  • Kaçınılması gereken eski veya durdurulmuş hizmetler olarak Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu ve Norton ConnectSafe belirtilir

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Bu tür listeleri ya da yeni hizmet duyurularını her gördüğümde pek heyecanlanmıyorum; Hacker News'te de şaşırtıcı biçimde benzer tepkiler çok gibi görünüyor.
    Yaklaşık 25 yıldır kendi proxy DNS hizmetimi işletiyorum; üç yazılım paketini altı işletim sisteminde denedim. Filtre sekmesindeki maddelerin hepsini kendiniz yapabilirsiniz ve ben de fiilen yapıyorum.
    Bu listede ilginç olan şey seçeneklerin kendisi değil, ortaya koyduğu noktalar. Örneğin “Çin” olarak işaretlenen maddelerin tamamında “Çin düzenlemeleri altında işletiliyor” deniyor; 2026'da bu yalnızca Çin maddeleri için değil, benim kıtamdaki kullanıcılar için de önem taşıyan bir unsur.
    “Danimarka'da 1 kişi tarafından işletiliyor” ifadesi bus factor açısından ilginç bir bilgi veriyor, ama diğer maddeler bundan bahsetmiyor diye onların daha iyi olduğunu varsayamayız. DNS.Watch'ın arkasında kimin olduğuna dair bilgi, Thomas Steen Rasmussen hakkında bilinenden çok daha az; son yıllarda en az bir kez çökmüş gibi göründüğünden bu makul bir endişe.
    Quad101'in kullanılabilir bölge sınırlaması var gibi görünüyor; Gcore'un bir yapay zeka şirketi olması gibi, bu listede yer almayan ama kullanıcılar için önemli olabilecek pek çok unsur da var.

    • “Danimarka'da 1 kişi tarafından işletiliyor” ifadesi, bus factor'dan çok kurumsal gözetim açısından daha ilginç.
      Operasyona birden fazla kişi dahil olduğunda birbirlerini denetlerler; DNS resolver'ın seçici loglama yapması ya da sonuçlara müdahale etmesi gibi garip bir şey görülürse bunu gündeme getirebilirler. Her şeyi tek kişi işletiyorsa o kişiyi durduracak kimse yoktur.
      “O kişi ilkeli biri, asla böyle bir şey yapmaz” diye düşünebilirsiniz; ancak kolluk kuvvetlerinin baskısı güçlü olabilir.
    • Yaklaşık 2 yıl önce kendi resolver'ımı kurdum; sorunsuz çalışıyor. Hiç sorun yaşamadım.

  • ISS'nin resmi DNS'ini kullanırsanız, ISS'nin handoff noktasından CDN'e ya da yurt dışı trunk'a kadar mümkün olan en kısa yolu elde edebilirsiniz. Yani ISS yapısını bilmeyen genel amaçlı DNS kullanmayın demek istiyorum.
    ISS: Cloudflare'a 1 ms
    Cloudflare: Cloudflare'a 10 ms
    Ancak bu tavsiye, iyi gizlilik yasaları olan ve devlet gözetimi bulunmayan ülkeler için geçerli. Yani ABD için değil.

    • Sansürsüz DNS'e ihtiyacınız varsa bu yöntem iyi değil.
    • Pratikte reklam sunucularını engelleyen DNS kullanmak, genel performansı büyük olasılıkla daha iyi hale getirir.
    • Böyle ülkeler hâlâ gerçekten var mı bilmiyorum. Ayrıca bu yalnızca gizlilik meselesi değil; neredeyse her ülke kullanıcıların erişmesini istemediği yerlere erişmelerini engellemeye çalışıyor ve çoğu zaman bunu, ISS'nin varsayılan DNS'inin sizi aslında açmak istediğiniz site yerine bir uyarı sayfasına yönlendirmesi gibi kaba bir yöntemle yapıyor.
      Bu yüzden 8.8.8.8 gibi bir DNS'e geçmek gizliliği mutlaka artırmasa bile, tarama deneyimini iyileştirmenin ilk büyük adımı oluyor.
    • Cloudflare'ın iyi bilindiği üzere anycast kullandığı düşünülürse, nereden gelirseniz gelin DNS yanıtı aynıdır. Verilen sayıların DNS'ten kaynaklandığını söylemek zor.
      Aksine Cloudflare, kendi hizmetleri için özyinelemeli sorgulamayı kısaltabildiğinden ad çözümleme aşamasında daha hızlı olabilir; gerekirse konum tabanlı yönlendirme için eDNS client subnet de kullanılabilir.
    • DNS'i değiştirmek gizlilik üzerinde neredeyse hiç etkili değildir. Çünkü DNS sorguları ve SNI hâlâ okunabilir.

  • Halka açık Wi-Fi'de DNS resolver'ları birlikte kullanma konusunda tavsiyeye ihtiyacım var.
    Birçok halka açık Wi-Fi, kullanım şartları onay ekranına yönlendirebilmek için kendi DNS'ini kullanmanızı gerektiriyor; hatta 30–60 dakikada bir yeniden onay isteyebiliyor.
    Sorun çıktığında internetin durduğunu fark ediyorsunuz, google.com'a ping atıp zaman aşımını bekliyorsunuz, ISS sorunu mu diye tahmin yürütüyorsunuz; sonra Wi-Fi oturumunun süresi dolmuş olabileceğini anlıyor, DNS'i değiştirip önbelleği temizliyor, TLS olmayan bir domaine giriyor, geçidi onaylıyor ve DNS'i tekrar eski haline getiriyorsunuz.
    Bunu yöneten bir şey mutlaka olmalı.

    • macOS'ta /etc/resolver ile çözülebilir belki.
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      Üniversite içi siteler yalnızca ağın ad sunucusuyla çözümlendiğinde bu yöntemi kullanmıştım. macOS'in captive portal algılama için kullandığı URL'ye de uygulanabilir diye düşündüm; bir dahaki sefere kafeye gittiğimde kontrol etmem gerekecek.
    • macOS ve iOS'te her zaman kullanılacak DNS sunucusunu belirleyen bir profil oluşturabilirsiniz. Diğer Wi-Fi ağlarında ve mobil veride de uygulanır.
      https://doh.lvv.me/
      Bunu yıllardır kullanıyorum ve halka açık hotspot'larda hiç sorun yaşamadım.
    • Adres çubuğuna doğrudan IP adresini yazmanız yeterli. Genellikle 80 numaralı port trafiğinin tamamını araya girip yakalıyorlar.
    • Bu tür şeyleri işletim sisteminin captive portal desteğinin bir parçası olarak halletmesi gerekir. İşletim sistemi üreticisiyle iletişime geçip bug kaydı açmanız iyi olur.

  • Yerelde Unbound’u DoH sunucusu olarak kullanıyorum. Alpine Linux’un Unbound paketi, yerleşik DoH dinleyicisi için gereken libnghttp2 ile birlikte derlenmiş ve bu kadarı ECH’yi açmak için yeterli
    Her saat cron ile sık kullandığım tüm alan adlarını önceden önbelleğe alıyorum. ISS’imin DNS isteklerime karışacağını sanmıyorum; zaten oradaki çalışanlar benden daha tuhaf insanlar. Telefonda web’e bakmaya başlarsam kendi genel DoH sunucumu kurarım. Birkaç dakika sürer ve garip sorunları ayıklarken kendi sorgu günlüklerimi de elde ederim
    [1] - https://tls-ech.dev/

    • Yaklaşık 3 yıldır kendi herkese açık powerdns, dnsdist, özyinelemeli/yetkili sunucu örneklerimle DoH, DoT, DoQ, TCP ve UDP çalıştırıyorum
      Daha önce bind, unbound, dnsmasq kullandığım için yapılandırma biraz zaman aldı. Çok kararlı; mobilde veya eski cihazlarda da kullanılabiliyor, ayrıca unbound, adguard/dnsproxy ve yerel resolve.conf için çözümleyici olarak da kullanılabiliyor
    • Neden önceden önbelleğe aldığını merak ediyorum. Hız içinse en fazla 30–50 ms değil mi? Yetkili sunucunun TTL’i 60 dakikadan kısaysa 3600’e zorlayıp zorlamadığını da merak ediyorum
      Ziyaret ettiğin tüm web sitelerinin bağlantılarını denetleyip varlıkları barındıran alan adlarına kadar toplayarak hepsini önceden önbelleğe alıp almadığını, yoksa algılanan gecikmeyi en çok etkileyen ana site alan adlarının mı önemli olduğunu da merak ediyorum
    • Unbound’da süresi dolmaya yakın önbellek kayıtlarını yenileyen prefetch var; önbellek ve TTL ile ilgili birkaç ayar seçeneği de mevcut. serve-expired da iyi çalışıyor gibi görünüyordu
    • “Her saat cron ile sık kullandığım tüm alan adlarını önceden önbelleğe alıyorum”un tam olarak nasıl bir şey olduğunu merak ediyorum. Ana makine adları listesini sorgulayan bir shell betiği mi, ayrıca “kullandığın alan adları”nın ölçütü nedir?
    • Burada da Unbound çalıştırıyorum. Alan adı engellemede joker karakter kullanabilmeyi seviyorum. Büyük bir engelleme listesi kullanıp onun üstüne istisna izin listesi koyuyorum
      ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com gibi girdileri ads.acme.com olarak sadeleştiren küçük bir aracım da var
      Ayrıca kullandığım alan adlarının varyasyonlarını üreten bir betiğim var. Örneğin gerçek alan adı mybank.com ise myb4nk.com, mibank.com, mybank.{diğer tüm TLD’ler} vb. adresleri engelliyorum
      Bu tür yüz binlerce varyasyon üretip hepsini Unbound’da engelliyorum. Bankam çok inandırıcı bir oltalama sitesi örneği gönderdikten sonra bunu yaptım
      Bu yapılandırmayı yıllardır kullanıyorum ve bir milyon engelli alan adı bile eski bir Pi 3 üzerinde iyi çalışıyor. Daha güçlü bir bilgisayarda Unbound’un milyonlarca, hatta belki on milyonlarca alan adından oluşan engelleme listelerini de işleyebileceğini düşünüyorum. Henüz yalnızca izin listesine dayalı bir yaklaşıma geçmedim
      Unicode alan adlarının hepsini de engelliyorum. Adında Unicode karakter bulunan alan adlarına erişilemiyor; umurumda değil

  • NextDNS’i memnuniyetle kullanıyorum. Hangi filtre listelerini açacağınız, günlüklemeyi nasıl yapacağınız gibi konularda çok fazla yapılandırılabilirlik var
    Neredeyse her yerde kararlı ve hızlı. Bulutta kendi çözümleyicinizi çalıştırınca bunu başarmak daha zor, zaten bakımını yapmak da istemiyorum

    • Ben de NextDNS’i severek kullanıyorum. Özellikle yıllarca Pi-hole ile uğraşıp bakımından yorulduktan sonra daha da memnun kaldım. Gerektiğinde Mullvad VPN ile birlikte kullanması da kolay
    • Benim için de oldukça iyiydi

  • Neden yalnızca 29 tane olduğunu anlamıyorum
    Yazar günümüz internetindeki açık çözümleyicilerin gerçek sayısının bu kadar olduğunu mu söylüyor?
    DNS’in “gizliliği” veya “güvenliği” düşünülürken SNI nasıl birlikte ele alınmaz, merak ediyorum
    SNI, üçüncü tarafların kullanıcının hangi alan adına, herkese açık bir adrese bağlanmak istediğini görmesine ve böyle bir bağlantıyı engelleyebilmesine olanak tanır
    DNS ise üçüncü tarafların yalnızca kullanıcının hangi alan adı için herkese açık bir adres sorguladığını görmesine olanak tanır. DNS dışı trafiği bu sorguyla ilişkilendirmek için ilgili yazılımın nasıl çalıştığına dair varsayımlar gerekir
    Bu yüzden popüler web tarayıcılarını kontrol eden reklam şirketlerinin, kullanıcıların tarayıcı içinde veya kurumsal işletim sistemlerinde DoH’u seçmesini istemesi şaşırtıcı değil. Buna aldatıcı biçimde “private DNS” dendiğinde, üçüncü taraflar tarayıcıda veya kurumsal işletim sisteminde çalışan yazılımların DNS dışı trafiğiyle sorguları daha etkili biçimde korele edebilir
    Bu tür aldatıcı iddialar yüzünden dava konusu olunabilir. Örneğin “private browsing” hakkındaki aldatıcı iddialar için kullanıcıların davayı kazandığı olmuştu

    • O 29 tane, birçok kişinin DNS sorgularını emanet etmeye bir ölçüde güvenebileceği hizmetler anlamına geliyor. Ayrıca bu 29 hizmet, hizmet özellikleri hakkında bilgi yayımlıyor
      Sayfanın tamamını okursanız bahsetmeye değer başka genel DNS çözümleyicilerin de ayrı listelendiğini görürsünüz
      Bilinmeyen uzun kuyruktaki açık DNS çözümleyiciler için Shodan’ı kullanabilirsiniz. Ancak Shodan’da bulduklarınıza internet kullanımınızı emanet edecek kadar güvenmenizi önermek istemem
      SNI genel bir internet gizliliği sorunu, evet; ama DNS’in bir özelliği değil. Olumlu tarafından bakarsak ECH IETF’ten geçti ve yavaş yavaş son kullanıcılara da sunulacak
      — yazar
    • ECH, birkaç “test” sitesi dışında genel web kullanıcılarına yaygın olarak sunulmuyor
      Yazarın yanıtındaki “you” ile kimin kastedildiği de net değil
      Benim durumumda uzak DNS’i yalnızca toplu DNS verilerini periyodik olarak alırken kullanıyorum. HTTP sunucularına erişirken uzak DNS isteği yapmıyorum. Gerekli IP adresi bilgileri zaten elimde ve bu yöntem daha hızlı ve daha kararlı
      Çeşitli kaynaklardan elde edilen toplu DNS verilerini yerel TLS forward proxy’sinin belleğine yüklü tutuyorum
      Kullanıcıların hepsi farklıdır; herkes kendi başına düşünmeli

  • Kanada’daki kullanıcılar için CIRA, IPv4, IPv6, DoH ve DoT üzerinden genel çözümleyici işletiyor
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Kanadalıların CIRA’ya diğer alternatiflerden neden daha çok güvenmesi gerektiğini bilmiyorum. Yine de varsayılan ISS DNS’ini kullanmaktan büyük olasılıkla daha iyidir

  • DNScryptProxy, herkese açık DNS sunucularının çok geniş bir listesini tutar. DNSSEC, filtreleme ve günlükleme desteği olup olmadığını da gösterir
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Böyle bir sitenin yerel ağ bazında temel bir hız karşılaştırma testi sunması güzel olurdu
    Rastgele sorgular için P90 yanıt süresiyle medyan yanıt süresini karşılaştırabilmek iyi olur gibi

    • Yazarıyım; şimdi ekledim: https://evilbit.de/dns-resolver-guide2.html#speedtest
      Ancak yalnızca DoH ile çalışıyor
    • Bu depoyu klonladıktan sonra alan adlarını ve resolver’ları istediğiniz gibi değiştirirseniz, aradığınıza benzer sonuçlar elde edebilirsiniz
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • Bu amaçla yerelde bir smokeping instance’ı çalıştırıyorum. Birden fazla DNS sunucusuna, ISP DNS’ine ve birkaç büyük web sitesine ping atıyor; sonuçlara göre yerel DNS sunucusunun upstream’ini periyodik olarak güncelliyorum
      Benim ortamımda büyük DNS sunucularının hepsi 5–6 ms aralığında, ama bu her zaman böyle değildi. ISP DNS’inin ortalaması da benzer, fakat dağılımı çok geniş ve 50 ms’ye kadar sıçrayan spike’lar var. En hızlı olması gereken konumda bile durum böyle

  • DNS, gizlilik ve güvenlik açısından çok önemli bir konu. Herkese açık DNS seçmektense kendi altyapınızı barındırmanın daha iyi olduğunu düşünüyorum
    Herkese açık bir instance’a gerek yok. Router’da veya bir makinede ADGUARD, unbound, dnsmasq, dnsdist’i recursive modda çalıştırmanız yeterli
    İhtiyacınıza göre kısıtlamalar ve engelleme listeleri de ayarlayabilirsiniz

    • Yine de ISP tüm sorguları kaydedebilir