Leitfaden zur Auswahl öffentlicher DNS-Resolver

 (evilbit.de)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Bei öffentlichen DNS-Resolvern sollte man nicht nur auf reine Geschwindigkeit achten, sondern auch Datenschutz, Filterung, Rechtsraum, Betreiber, verschlüsselte Übertragung berücksichtigen; dieser Leitfaden vergleicht 30 globale Dienste nach Anforderungen
  • Das Auswahl-Tool nutzt DoH, DoT, DoQ, DNSCrypt, DNSSEC-Validierung, IPv6, Rechtsraum, Betreibertyp und EDNS Client Subnet als harte Filter und bewertet zweckbezogene Prioritäten mit Punkten
  • Der browserbasierte DoH-Latenztest zeigt die relative Geschwindigkeit vom aktuellen Standort aus, enthält aber TLS-/HTTP-Overhead und kann Resolver, die nur unverschlüsseltes DNS unterstützen, nicht messen
  • Verschlüsseltes DNS verringert Mitschnitt und Manipulation durch Man-in-the-Middle, doch der gewählte Resolver-Anbieter kann die abgefragten Domains sehen; daher sollten auch No-Log-Richtlinien und oblivious Designs berücksichtigt werden
  • In der Praxis sollte man bei der Auswahl DNSSEC, den Geschwindigkeits-Privatsphäre-Trade-off von ECS, DoQ-Performance, DNSCrypt-Eigenschaften, Grenzen der Traffic-Analyse, Unterschiede bei der Standardkonformität sowie Rechtsraum und Zentralisierungsrisiken gemeinsam abwägen

Kriterien, die das Auswahl-Tool vergleicht

  • Öffentliche DNS-Resolver werden verglichen, indem Nutzer die für sie wichtigen Bedingungen ankreuzen und passende Dienste finden
  • Bedingungen, die als harte Filter verwendet werden
    • Verschlüsselte Übertragung: DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), DNSCrypt
    • Unterstützung für DNSSEC-Validierung
    • Bereitstellung von IPv6-Resolver-Adressen
    • Rechtsraum des Betreibers
    • Betreibertyp: Non-Profit, Community, Gemeinwohl; kommerziell; alle
    • EDNS Client Subnet (ECS): nicht genutzt, genutzt, egal
  • Faktoren für die Prioritätsbewertung
    • Maximaler Datenschutz und keine oder minimale Logs
    • Blockieren von Malware und Phishing
    • Blockieren von Werbung und Trackern
    • Kinderschutz und Blockieren von Inhalten für Erwachsene
    • Keine Filterung, also unveränderte Rückgabe der veröffentlichten DNS-Antworten
    • Benutzerdefinierte Blocklisten und Regeln über ein Konto
    • Niedrige Latenz durch globales Anycast
    • Nichtkommerzieller Betreiber

DoH-Geschwindigkeitstest vom aktuellen Standort aus

  • Der integrierte Test misst im Browser die Round-Trip-Time zu jedem DoH-fähigen Resolver
  • Resolver, die nur unverschlüsseltes DNS unterstützen, können auf diese Weise nicht getestet werden
  • Die Ergebnisse sind relative Referenzwerte; da TLS- und HTTP-Overhead enthalten ist, sollten sie mehrfach gemessen werden
  • Da der Browser jeden Resolver direkt abfragt, wird die IP-Adresse des Nutzers diesem Resolver offengelegt
  • Die Testimplementierung wurde vom Open-Source-Projekt DNS Speed Test von Silviu Stroe inspiriert, ist aber eine eigenständige Implementierung und läuft nur, wenn die Seite per HTTPS bereitgestellt wird

Unterschiede bei Performance und verschlüsselter Übertragung

  • Verschlüsselte Übertragungen wie DoH und DoT erhöhen die Latenz pro Anfrage, doch die gesamte Seitenladezeit liegt oft nahe an unverschlüsseltem DNS; auch der DoH-Overhead fällt in realen Umgebungen gering aus
  • Auf Verbindungen mit Paketverlust oder hoher Latenz ist unverschlüsseltes Do53 weiterhin im Vorteil
  • Die Performance hängt von Anbieter und Region ab; der schnellste Resolver hängt daher vom Standort des Nutzers ab
  • Groß angelegte Ende-zu-Ende-Messungen zu verschlüsseltem DNS zeigten, dass Anfragen während der Übertragung deutlich seltener abgefangen oder verändert wurden als bei unverschlüsseltem DNS, während der Overhead gering war
  • Allerdings stellten in dieser Studie rund 25 % der DoT-Anbieter ungültige TLS-Zertifikate bereit; daher ist es wichtig, Anbieter mit guter Betriebsqualität zu wählen

Praktische Grenzen des Datenschutzes

  • Verschlüsseltes DNS verbirgt Anfragen im Netzwerk, doch der gewählte Resolver-Anbieter kann alle abgefragten Domains sehen
  • Wenn das ein Problem ist, sollte man einen No-Log-Betreiber wählen oder oblivious Designs wie ODoH in Betracht ziehen, bei denen ein Proxy Identität und Anfrage trennt
  • Cloudflare und Apple sind Beispiele für den Einsatz von ODoH
  • Verschlüsseltes DNS allein verbirgt besuchte Websites nicht vollständig
    • Auch bei DoH können besuchte Domains per Traffic-Analyse mit hoher Genauigkeit identifiziert werden
    • Standardisiertes EDNS-Padding verhindert das ebenfalls nicht vollständig
    • Wenn dieses Bedrohungsmodell relevant ist, sollte man sich nicht nur auf Padding verlassen, sondern zusätzlich Tor oder oblivious Designs nutzen

DNSSEC, ECS und Rechtsraum

  • Nur Resolver mit DNSSEC-Validierung schützen vor gefälschten Records
  • Google, Cloudflare und Quad9 validieren DNSSEC und bewältigten den ersten Root-Key-KSK-Rollover ohne Störungen für Nutzer
  • Wenn Integrität wichtig ist, sollte DNSSEC-Validierung als Pflichtkriterium gelten
  • EDNS Client Subnet (ECS) sendet einen Teil der IP-Adresse an CDNs, um besseres geografisches Routing zu ermöglichen
    • Google und OpenDNS senden ECS für präzisere CDN-Zuordnung
    • Cloudflare und das standardmäßige Quad9 deaktivieren ECS aus Datenschutzgründen
  • Der rechtliche Sitz des Betreibers beeinflusst durchsetzbare Maßnahmen und Logs
  • Eine kleine Zahl von Anbietern verarbeitet einen großen Anteil des weltweiten rekursiven DNS-Traffics
  • Die US-amerikanische NSA warnt, dass externe Resolver interne DNS-Filterung und -Prüfung umgehen; daher sollte man Bequemlichkeit und Kontrolle gegeneinander abwägen

DoQ und DNSCrypt

  • Messungen zu DoQ aus dem Jahr 2022 zeigten, dass DNS-over-QUIC bei der Antwortzeit sowohl DoT als auch DoH übertraf
  • Wegen Einschränkungen bei der Adressvalidierung von QUIC wurden jedoch rund 40 % der Handshakes verlangsamt
  • Wenn Client und Resolver es beide unterstützen, ist DoQ die bevorzugte verschlüsselte Option
    • Unterstützungsbeispiele: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, große chinesische Dienste
  • DNSCrypt ist eine ältere Verschlüsselungsoption als DoH, DoT und DoQ; Version 2 erschien 2013
  • DNSCrypt verschlüsselt ab dem ersten Paket mit dem vorab geteilten öffentlichen Schlüssel des Resolvers, sodass keine unverschlüsselte Hostnamen-Abfrage und keine Abhängigkeit von Zertifizierungsstellen entsteht
  • Der Anonymized-DNS-Modus von 2019 verbirgt auch die Client-IP
  • Unter den verglichenen Anbietern unterstützen Quad9, OpenDNS, AdGuard, NextDNS, Control D und Yandex DNSCrypt
  • Verlässliche Nutzungszahlen fehlen; groß angelegte Messungen wie APNIC Labs verfolgen DoH und DoT, aber nicht DNSCrypt

Implementierungsqualität und Betriebsdaten von Resolvern

  • In einer Studie zu Extended DNS Errors aus dem Jahr 2023 waren die Diagnose-Fehlermeldungen großer Resolver in 94 % der Testfälle uneinheitlich
  • Cloudflare zeigte in dieser Studie die präzisesten Fehlermeldungen
  • Unterschiede bei Implementierungsqualität und Standardkonformität je Resolver wirken sich auf Fehlersuche und Zuverlässigkeit aus
  • Nützliche Betriebs- und Community-Daten

Kleine, Community- und regionale Resolver

  • Neben der Vergleichstabelle gibt es Hobby-, Community- und länderspezifische Resolver; vor der Nutzung sollte man aktuellen Status und Richtlinien prüfen
  • Europäische Angebote sind bei European Alternatives zusammengestellt
  • Bei Resolvern in Regionen mit starker Zensur oder Sanktionen ist besondere Vorsicht geboten, da sie lokale Inhaltsregeln anwenden oder zur Umgehung von Geoblocking betrieben werden können
  • Beispieldienste
    • DNS4all: europäischer ungefilterter Resolver mit Fokus auf Neutralität und Performance
    • BlahDNS: Open-Source-Hobbyprojekt zur Werbeblockierung, betrieben auf kleinen regionalen Servern, mit Unterstützung für DoH, DoT und DoQ
    • LibreDNS: Community-Resolver von LibreOps mit Werbeblockierung, No-Log-Richtlinie sowie Unterstützung für DoH und DoT
    • Dismail.de: datenschutzorientierter deutscher Community-Resolver, No-Log, mit Unterstützung für DoH und DoT
    • IIJ Public DNS: öffentlicher DoH-/DoT-Resolver von Internet Initiative Japan, blockiert Domains mit Darstellungen sexuellen Kindesmissbrauchs
    • DNS for Family: DoH mit Familienfilterung für Pornografie, Glücksspiel, Malware, Werbung/Tracker und Safe Search
  • Als zu meidende Legacy- oder eingestellte Dienste werden Oracle Dyn, Level3 (4.2.2.x), Freenom World, dns0.eu und Norton ConnectSafe genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Immer wenn ich solche Listen oder Ankündigungen neuer Dienste sehe, löst das bei mir wenig Begeisterung aus, und auch auf Hacker News scheint die Reaktion überraschend oft ähnlich zu sein.
    Ich betreibe seit fast 25 Jahren selbst einen Proxy-DNS-Dienst und habe drei Software-Bundles auf sechs Betriebssystemen eingesetzt; alles, was im Filter-Tab steht, kann man selbst machen, und ich mache es auch tatsächlich.
    An dieser Liste sind weniger die Auswahlmöglichkeiten interessant als das, was sie offenlegt. Zum Beispiel sind alle als „China“ gekennzeichneten Einträge mit „unter chinesischer Regulierung betrieben“ versehen; 2026 ist das nicht nur bei China-Einträgen ein Punkt, der auch Nutzer auf meinem Kontinent beschäftigt.
    Die Formulierung „betrieben von 1 Privatperson in Dänemark“ ist eine interessante Information zum Bus-Faktor, aber man kann nicht annehmen, dass andere Einträge besser sind, nur weil sie diesen Punkt nicht erwähnen. Über die Personen hinter DNS.Watch gibt es deutlich weniger Informationen als über Thomas Steen Rasmussen, und da der Dienst in den letzten Jahren offenbar mindestens einmal ausgefallen ist, ist das eine berechtigte Sorge.
    Bei Quad101 scheint es regionale Einschränkungen der Verfügbarkeit zu geben, und auch dass Gcore ein AI-Unternehmen ist, steht nicht in dieser Liste, kann für Nutzer aber wichtig sein.

    • „Betrieben von 1 Privatperson in Dänemark“ ist unter dem Aspekt organisatorischer Kontrolle interessanter als beim Bus-Faktor.
      Wenn mehrere Personen am Betrieb beteiligt sind, können sie sich gegenseitig kontrollieren und Alarm schlagen, wenn etwas Seltsames passiert, etwa wenn ein DNS-Resolver selektiv loggt oder in Ergebnisse eingreift. Wenn eine Person alles allein betreibt, gibt es niemanden, der sie bremst.
      Man kann zwar denken: „Diese Person hat Prinzipien und würde so etwas nie tun“, aber der Druck von Strafverfolgungsbehörden kann erheblich sein.
    • Ich habe vor etwa zwei Jahren selbst einen Resolver eingerichtet, und er läuft einfach. Kein einziges Problem bisher.

  • Wenn man den offiziellen DNS des ISP nutzt, bekommt man am Übergabepunkt des ISP den möglichst kürzesten Pfad zum CDN oder zum internationalen Trunk. Gemeint ist: Man sollte keinen allgemeinen DNS nutzen, der die Struktur des ISP nicht kennt.
    ISP: 1 ms bis Cloudflare
    Cloudflare: 10 ms bis Cloudflare
    Allerdings gilt dieser Rat für Länder mit guten Datenschutzgesetzen und ohne staatliche Überwachung. Also nicht für die USA.

    • Wenn man unzensiertes DNS braucht, ist das keine gute Methode.
    • In der Praxis dürfte ein DNS, der Ad-Server blockiert, für die Gesamtperformance wahrscheinlich besser sein.
    • Ich weiß nicht, ob solche Länder heute überhaupt noch real existieren. Und es geht hier nicht nur um Datenschutz: Fast jedes Land versucht zu verhindern, dass Nutzer Orte erreichen, die sie nicht erreichen sollen, meist auf plumpe Weise, indem der Standard-DNS des ISP statt der eigentlich gewünschten Website eine Warnseite ausliefert.
      Deshalb ist der Wechsel zu einem DNS wie 8.8.8.8, auch wenn er den Datenschutz nicht zwangsläufig verbessert, ein erster großer Schritt zu einer besseren Browsing-Erfahrung.
    • Cloudflare verwendet bekanntermaßen Anycast, daher ist die DNS-Antwort dieselbe, egal von wo die Anfrage kommt. Die genannten Zahlen lassen sich schwerlich auf DNS zurückführen.
      Im Gegenteil: Cloudflare kann rekursive Abfragen für eigene Dienste abkürzen und dadurch in der Namensauflösung schneller sein; falls nötig, ist mit eDNS Client Subnet auch standortbasiertes Routing möglich.
    • Ein DNS-Wechsel bringt für die Privatsphäre kaum etwas. DNS-Anfragen und SNI können weiterhin gelesen werden.

  • Ich bräuchte Rat dazu, wie man öffentliche WLANs zusammen mit einem DNS-Resolver nutzt.
    Viele öffentliche WLANs müssen ihr eigenes DNS verwenden, um auf die Seite zur Zustimmung zu den Nutzungsbedingungen umzuleiten, und verlangen teils alle 30 bis 60 Minuten eine erneute Freigabe.
    Wenn ein Problem auftritt, merkt man, dass das Internet hängt, pingt google.com an und wartet auf den Timeout, rätselt, ob es ein ISP-Problem ist, erkennt dann, dass die WLAN-Sitzung wohl abgelaufen ist, ändert DNS und leert den Cache, ruft eine Nicht-TLS-Domain auf, bestätigt das Gateway und stellt DNS anschließend wieder zurück.
    Es muss doch definitiv etwas geben, das so etwas verwaltet.

    • Unter macOS lässt sich das vielleicht mit /etc/resolver lösen.
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      Ich habe diese Methode genutzt, wenn interne Uni-Websites nur über den Nameserver des Netzwerks aufgelöst wurden. Mir kam der Gedanke, dass sich das auch auf die URL anwenden lassen könnte, die macOS zur Erkennung von Captive Portals verwendet; beim nächsten Cafébesuch sollte ich das prüfen.
    • Unter macOS und iOS kann man ein Profil erstellen, das den immer zu verwendenden DNS-Server festlegt. Das gilt dann auch in anderen WLANs und über mobile Daten.
      https://doh.lvv.me/
      Ich nutze das seit Jahren und hatte in öffentlichen Hotspots nie Probleme.
    • Man kann einfach die IP-Adresse in die Adressleiste eingeben. Normalerweise wird der gesamte Traffic auf Port 80 abgefangen.
    • So etwas sollte das Betriebssystem als Teil der Captive-Portal-Unterstützung behandeln. Am besten den Betriebssystemhersteller kontaktieren und einen Bug melden.

  • Ich nutze Unbound lokal als DoH-Server. Das Unbound-Paket von Alpine Linux ist mit libnghttp2 kompiliert, das für den eingebauten DoH-Listener nötig ist, und das reicht aus, um ECH zu aktivieren.
    Per stündlichem cron werden alle häufig genutzten Domains vorab gecacht. Mein ISP wird meine DNS-Anfragen wohl nicht manipulieren, und dessen Mitarbeitende sind noch seltsamere Leute als ich. Wenn ich anfange, auf dem Handy im Web zu surfen, werde ich mir einen eigenen öffentlichen DoH-Server bauen. Das dauert nur ein paar Minuten, und beim Debuggen merkwürdiger Probleme bekomme ich auch meine eigenen Query-Logs.
    [1] - https://tls-ech.dev/

    • Ich betreibe seit etwa drei Jahren eigene öffentliche powerdns-, dnsdist- sowie rekursive/autoritative Serverinstanzen für DoH, DoT, DoQ, TCP und UDP.
      Vorher habe ich bind, unbound und dnsmasq verwendet, daher hat die Konfiguration etwas Zeit gekostet. Es ist sehr stabil, lässt sich auch auf Mobilgeräten oder älteren Geräten nutzen und kann ebenso als Resolver für unbound, adguard/dnsproxy oder eine lokale resolve.conf dienen.
    • Mich würde interessieren, warum du vorab cachst. Wenn es um Geschwindigkeit geht: Sind das nicht höchstens 30–50 ms? Ich frage mich auch, ob du auf 3600 erzwingst, falls die TTL des autoritativen Servers kürzer als 60 Minuten ist.
      Außerdem frage ich mich, ob du die Verbindungen aller besuchten Websites auditierst, um auch die Domains zu sammeln, auf denen Assets gehostet werden, und dann alles vorab cachst – oder ob nur die Hauptdomain der Website wichtig ist, weil sie den wahrgenommenen Lag am stärksten beeinflusst.
    • Unbound hat Prefetch, das Cache-Records kurz vor Ablauf erneuert, und außerdem mehrere Optionen zum Anpassen von Cache und TTL. serve-expired schien ebenfalls gut zu funktionieren.
    • Mich würde interessieren, wie „per stündlichem cron alle häufig genutzten Domains vorab cachen“ konkret aussieht. Ist das ein Shell-Skript, das eine Liste von Hostnamen abfragt, und was ist das Kriterium für „genutzte Domains“?
    • Ich betreibe hier ebenfalls Unbound. Mir gefällt, dass man Wildcards zum Blockieren von Domains verwenden kann. Ich nutze große Blocklisten und darüber eine Allowlist mit Ausnahmen.
      Ich habe auch ein kleines Tool, das Eingaben wie ayt7.ads.acme.com, afi6.ads.acme.com oder foi5.ads.acme.com zu ads.acme.com vereinfacht.
      Außerdem habe ich ein Skript, das Varianten von Domains erzeugt, die ich nutze. Wenn die legitime Domain zum Beispiel mybank.com ist, blockiere ich myb4nk.com, mibank.com, mybank.{alle anderen TLDs} usw.
      Ich generiere Hunderttausende solcher Varianten und blockiere sie alle in Unbound. Das habe ich gebaut, nachdem mir meine Bank Beispiele sehr plausibler Phishing-Websites geschickt hatte.
      Ich nutze diese Konfiguration seit Jahren, und selbst eine Million blockierte Domains laufen auf einem alten Pi 3 gut. Auf einem leistungsfähigeren Rechner könnte Unbound vermutlich Blocklisten mit mehreren Millionen, vielleicht sogar zig Millionen Domains verarbeiten. Auf einen reinen Allowlist-Ansatz bin ich noch nicht umgestiegen.
      Unicode-Domains blockiere ich ebenfalls komplett. Domains, die Unicode-Zeichen im Namen verwenden, kann ich nicht aufrufen, und das ist mir egal.

  • Ich nutze NextDNS zufrieden. Es gibt viele Konfigurationsmöglichkeiten, etwa welche Filterlisten aktiviert werden sollen oder wie Logging gehandhabt wird.
    Es ist fast überall zuverlässig und schnell. Das selbst mit einem Resolver in der Cloud zu erreichen, ist schwieriger, und ich will ihn ohnehin nicht warten.

    • Ich nutze NextDNS ebenfalls gern. Besonders nachdem ich jahrelang an Pi-hole herumgeschraubt hatte und die Wartung leid war, bin ich damit zufriedener. Bei Bedarf lässt es sich auch leicht zusammen mit Mullvad VPN verwenden.
    • Für mich war es auch ziemlich gut.

  • Ich weiß nicht, warum es nur 29 sind.
    Will der Autor sagen, dass es im heutigen Internet tatsächlich nur ungefähr so viele offene Resolver gibt?
    Ich frage mich, wie man „Privatsphäre“ oder „Sicherheit“ bei DNS betrachten kann, ohne zugleich SNI zu berücksichtigen.
    SNI erlaubt Dritten zu sehen, zu welchem Domainnamen ein Nutzer eine Verbindung zu einer öffentlichen Adresse herstellen möchte, und es ermöglicht ihnen auch, solche Verbindungen zu stören.
    DNS erlaubt Dritten nur zu sehen, für welchen Domainnamen ein Nutzer eine öffentliche Adresse nachschlägt. Um Nicht-DNS-Traffic mit dieser Anfrage zu verknüpfen, braucht es Annahmen darüber, wie die jeweilige Software funktioniert.
    Deshalb ist es nicht überraschend, dass Werbefirmen, die populäre Webbrowser kontrollieren, möchten, dass Nutzer im Browser oder in Unternehmensbetriebssystemen DoH wählen. Wenn man das irreführend „private DNS“ nennt, können Dritte Anfragen effektiver mit Nicht-DNS-Traffic von Software korrelieren, die im Browser oder im Unternehmensbetriebssystem läuft.
    Wegen solcher irreführender Behauptungen kann man verklagt werden. Bei irreführenden Aussagen zu „private browsing“ haben Nutzer zum Beispiel schon einmal vor Gericht gewonnen.

    • Die 29 sind Dienste, denen viele Menschen einigermaßen zutrauen, ihre DNS-Anfragen anzuvertrauen. Außerdem veröffentlichen diese 29 Informationen zu ihren Diensteigenschaften.
      Wenn du die ganze Seite liest, sind dort auch andere erwähnenswerte öffentliche DNS-Resolver separat aufgeführt.
      Für den unbekannten Long Tail offener DNS-Resolver kann man Shodan verwenden. Ich würde allerdings nicht empfehlen, dem, was man über Shodan findet, die eigene Internetnutzung anzuvertrauen.
      SNI ist tatsächlich ein allgemeines Problem der Internet-Privatsphäre, aber keine Eigenschaft von DNS. Positiv betrachtet hat ECH die IETF passiert und wird langsam auch normalen Nutzern bereitgestellt werden.
      — Autor
    • ECH ist, abgesehen von ein paar „Test“-Sites, für normale Webnutzer nicht breit verfügbar.
      Es ist auch nicht klar, auf wen sich das „you“ in der Antwort des Autors bezieht.
      In meinem Fall nutze ich Remote-DNS nur, wenn ich regelmäßig Massendaten zu DNS abrufe. Wenn ich auf HTTP-Server zugreife, stelle ich keine Remote-DNS-Anfragen. Ich habe die nötigen IP-Adressinformationen bereits, und diese Methode ist schneller und zuverlässiger.
      DNS-Massendaten aus mehreren Quellen halte ich im Speicher eines lokalen TLS-Forward-Proxys geladen.
      Nutzer sind alle unterschiedlich und müssen jeweils selbst nachdenken.

  • Für Nutzer in Kanada betreibt CIRA einen öffentlichen Resolver über IPv4, IPv6, DoH und DoT.
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • Ich weiß nicht, warum Kanadier CIRA mehr vertrauen sollten als anderen Alternativen. Wahrscheinlich ist es aber trotzdem besser, als den Standard-DNS des ISP zu verwenden.

  • DNScryptProxy pflegt eine umfangreiche Liste öffentlicher DNS-Server. Sie zeigt auch an, ob DNSSEC, Filtering und Logging unterstützt werden.
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • Es wäre gut, wenn solche Sites einen einfachen Geschwindigkeitsvergleichstest bezogen auf das lokale Netzwerk anbieten würden.
    Es wäre hilfreich, die P90-Antwortzeit und die mediane Antwortzeit für zufällige Abfragen vergleichen zu können.

    • Ich bin der Autor, und habe das jetzt hinzugefügt: https://evilbit.de/dns-resolver-guide2.html#speedtest
      Funktioniert allerdings nur mit DoH.
    • Wenn man dieses Repository klont und Domainnamen sowie Resolver nach Wunsch anpasst, bekommt man ungefähr die gesuchten Ergebnisse.
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • Ich betreibe für diesen Zweck lokal eine smokeping-Instanz. Sie pingt mehrere DNS-Server, ISP-DNS und ein paar wichtige Websites an, und anhand der Ergebnisse aktualisiere ich regelmäßig die Upstreams meines lokalen DNS-Servers.
      In meiner Umgebung liegen die großen DNS-Server alle im Bereich von 5–6 ms, aber das war nicht immer so. Der ISP-DNS hat im Durchschnitt ähnliche Werte, streut aber stark und hat Spitzen bis 50 ms. Und das, obwohl er eigentlich am schnellsten sein sollte.

  • DNS ist ein sehr wichtiges Thema für Privatsphäre und Sicherheit. Statt einen öffentlichen DNS zu wählen, halte ich es für besser, eigene Infrastruktur zu hosten.
    Man braucht keine öffentliche Instanz. Es reicht, ADGUARD, unbound, dnsmasq oder dnsdist im rekursiven Modus auf einem Router oder einer Maschine laufen zu lassen.
    Je nach Bedarf kann man auch Beschränkungen und Blocklisten konfigurieren.

    • Trotzdem kann der ISP alle Anfragen protokollieren.