Quad9 DNS (9.9.9.9): Funktionsweise, Vorteile, Alternativen

⚡TL;DR

• 📢 Quad9 (9.9.9.9) ist ein öffentlicher DNS-Resolver mit Fokus auf Sicherheit und Datenschutz, leicht in KMU auszurollen.
• Nutze 9.9.9.9 für den "Secure"-Dienst (Blockieren bösartiger Domains + DNSSEC); 9.9.9.10 nur fürs Debugging.
• Um Ausspähen und DNS-Umleitungen zu vermeiden, bevorzuge einen verschlüsselten Transport (DoT oder DoH) und prüfe das tatsächlich verwendete Protokoll.
• Seit 15. Dezember 2025 unterstützt Quad9 DoH über HTTP/1.1 nicht mehr: jeder DoH‑Client muss HTTP/2 sprechen (sonst auf DoT wechseln).

Dein "Standard-DNS" (oft der des Providers oder der per DHCP im Netz verteilt wird) ist selten eine bewusste Wahl. Dabei gilt: Der DNS-Resolver sieht alle Domainnamen, die deine Maschinen auflösen und kann außerdem Sicherheit (Blockieren bösartiger Domains) und Verfügbarkeit (Ausfälle, Latenz, Fehler) beeinflussen.

Quad9 ist eine beliebte Alternative, wenn du einen öffentlichen DNS mit Fokus auf Sicherheit + Datenschutz willst: Er kann Domains blockieren, die mit Malware/Phishing verbunden sind, und gibt eine minimale Datensammlung an (insbesondere keine IP‑Adress-Logs im DNS‑Dienst). Das ist typischerweise hilfreich für Sysadmins / DevOps / KMU-CTOs, die sofort einen Sicherheitsgewinn wollen, ohne Proxy oder Agent auf jedem Gerät.

Wir schauen uns wie Quad9 funktioniert, welche Adressen du nutzen solltest (9.9.9.9 / 9.9.9.10 / 9.9.9.11), wie du es sauber konfigurierst (Router, Endgeräte, interner Forwarder), wie du testest, was wirklich passiert… und die wichtige Änderung: das Ende von DoH über HTTP/1.1 seit dem 15. Dezember 2025.

Quad9 und 9.9.9.9 in zwei Minuten

Quad9 ist ein öffentlicher rekursiver DNS-Resolver (ein DNS‑Auflösungsdienst, den du statt deines ISP nutzen kannst). Er ist vor allem bekannt für:

• Bedrohungsfilterung: Im "Secure"-Dienst kann Quad9 die Auflösung von Domains verweigern, die mit Malware, Phishing, Botnets usw. verbunden sind.
• DNSSEC-Validierung (bei "Secure"-Diensten): Die Auflösung schlägt fehl, wenn eine signierte DNS-Antwort manipuliert ist.
• Datenschutz: Quad9 sagt, dass keine IP‑Adressen im DNS‑Dienst gesammelt oder gespeichert werden, und dass die Sammlung auf aggregierte Daten begrenzt ist.
• Verschlüsselung: Du kannst Quad9 als klassisches DNS (Do53) oder als verschlüsseltes DNS via DoT (DNS‑over‑TLS) und DoH (DNS‑over‑HTTPS) nutzen, sowie auch via DNSCrypt.

Der bekannteste Einstiegspunkt ist 9.9.9.9 (und der IPv4‑"Sekundär" 149.112.112.112): Das ist der "Secure"-Dienst, in der Regel die richtige Standardwahl.

Wie löst Quad9 einen Domainnamen auf?

Wenn ein Client api.captaindns.com erreichen will, kennt er die IP nicht. Also stellt er eine DNS‑Anfrage.

Mit Quad9 sieht der Weg so aus:

1. Der Client sendet eine DNS‑Anfrage (über OS, Router, Forwarder…).
2. Quad9 empfängt die Anfrage und prüft zuerst seinen Cache.
3. Wenn nicht im Cache, macht Quad9 die rekursive Auflösung (Root → TLD → autoritative Server).
4. Im "Secure"-Dienst vergleicht Quad9 die Domain außerdem mit Bedrohungsinformationen:
   • Wenn die Domain als bösartig erkannt wird, liefert Quad9 typischerweise NXDOMAIN (die Domain "existiert" aus Client‑Sicht nicht).
5. Wenn DNSSEC beteiligt ist und die Validierung fehlschlägt, kann die Antwort SERVFAIL sein (Validierungsfehler).

Was du clientseitig siehst, wenn es blockiert

Das ist in der Praxis wichtig: ein DNS‑Block sieht oft aus wie "Internet geht nicht".

• Wenn Quad9 eine bösartige Domain blockiert: NXDOMAIN.
• Wenn die Domain wirklich nicht existiert: ebenfalls NXDOMAIN.
• Wenn DNSSEC fehlschlägt: oft SERVFAIL.

Der praktische Trick: Quad9 bietet Möglichkeiten, "NXDOMAIN wegen Block" vs. "NXDOMAIN wegen wirklich nicht existent" zu unterscheiden (dazu gleich in den Tests).

Vorteile und Grenzen von Quad9

Was Quad9 sofort bringt

• Risikoreduktion "mit einem Klick": Ein Teil bösartiger Domains löst nicht mehr auf.
• Weniger DNS‑Leaks bei aktiviertem DoT/DoH: Öffentliches WLAN sieht deutlich weniger, was du auflöst.
• DNSSEC bereits validiert auf Secure‑Diensten: weniger Risiko für Poisoning oder manipulierte Antworten bei signierten Zonen.
• Leichtes Deployment: Eine DNS‑Änderung am Router oder ein lokaler Forwarder reicht oft.

Was Quad9 nicht ersetzt

• Einen Web‑Proxy oder ein SASE‑Produkt: Quad9 arbeitet auf DNS‑Ebene, nicht auf URL‑, HTTP‑ oder TLS‑Inspection‑Ebene.
• Einen Adblocker: Quad9 ist "Bedrohungen"‑orientiert, nicht "Ads/Tracker" (auch wenn es Überschneidungen gibt).
• Eine Benutzer-/Geräte‑Policy: Du hast nicht nativ Profile wie "Marketing vs Dev vs Gäste" wie in verwalteten Enterprise‑DNS‑Lösungen.

Die richtige Einordnung: Quad9 ist eine Basisschicht (oft sehr effizient), aber kein einzelner Schutzschild.

Quad9‑Dienste, die du kennen solltest

Quad9 bietet nicht "ein DNS", sondern mehrere Varianten. In der Praxis begegnen dir vor allem diese drei:

Dienst	Einsatz wann	Bedrohungsfilter	DNSSEC	ECS	IPv4‑Adressen
9.9.9.9 "Secure"	Standardfall, KMU, Endgeräte, Gäste‑WLAN	✅	✅	❌	9.9.9.9, 149.112.112.112
9.9.9.10 "No Threat Blocking"	Debugging, Vergleiche, spezielle Anforderungen	❌	❌	❌	9.9.9.10, 149.112.112.10
9.9.9.11 "Secure + ECS"	CDN‑Geolok/Performance‑Probleme, Sonderfälle	✅	✅	✅	9.9.9.11, 149.112.112.11

Nützliche Adressen und Endpoints

Secure‑Dienst (empfohlen):

IPv4 : 9.9.9.9, 149.112.112.112
IPv6 : 2620:fe::fe, 2620:fe::9
DoT  : dns.quad9.net (port 853)
DoH  : https://dns.quad9.net/dns-query

No Threat Blocking‑Dienst:

IPv4 : 9.9.9.10, 149.112.112.10
IPv6 : 2620:fe::10, 2620:fe::fe:10
DoT  : dns10.quad9.net (port 853)
DoH  : https://dns10.quad9.net/dns-query

Secure + ECS‑Dienst:

IPv4 : 9.9.9.11, 149.112.112.11
IPv6 : 2620:fe::11, 2620:fe::fe:11
DoT  : dns11.quad9.net (port 853)
DoH  : https://dns11.quad9.net/dns-query

ECS aktivieren – ja oder nein?

ECS (EDNS Client Subnet) übermittelt teilweise Standortinformationen (einen Teil deines IP‑Präfixes) an autoritative Server/CDNs. Ergebnis: Du bekommst in manchen Netzen ein "besseres" CDN‑POP (geringere Latenz), wenn Anycast dich zu einem Quad9‑Standort schickt, der für deine tatsächliche Geografie nicht ideal ist.

Der Kompromiss:

• ✅ Potenziell bessere CDN‑Performance (Video, große Plattformen).
• ❌ Weniger Datenschutz, weil ein Teil deines Präfixes zur Geolokalisierung dient.

In der Praxis: Starte mit 9.9.9.9, wechsle erst zu 9.9.9.11, wenn du ein echtes Problem beobachtest (ungewöhnliche Latenz zu einem Dienst, falsche Geolok, etc.).

Do53, DoT, DoH und DNSCrypt

Oft wird "DNS ändern" mit "DNS verschlüsseln" verwechselt. Das ist nicht dasselbe.

Do53

Do53 ist klassisches DNS: UDP/53 (und manchmal TCP/53). Einfach und universell, aber:

• sichtbar (sniffbar) im Netz,
• umleitbar (manche Netze intercepten Port 53),
• leichter manipulierbar für lokale Angreifer (öffentliches WLAN, Gäste‑Netz…).

DoT

DoT (DNS‑over‑TLS) verschlüsselt DNS auf Transportebene (TCP + TLS, meistens Port 853). Vorteile:

• oft auf OS‑Ebene verfügbar (z. B. Android "Private DNS", Linux via systemd‑resolved etc.),
• leichter über Router/Forwarder zu proxen,
• kein HTTP‑Wrapper: weniger Überraschungen clientseitig.

DoH

DoH (DNS‑over‑HTTPS) kapselt DNS in HTTPS (Port 443). Praktisch in Umgebungen, in denen 853 gefiltert ist, aber stärker "webby".

Wichtig für Quad9: DoH über HTTP/1.1 wurde ab dem 15. Dezember 2025 entfernt. Ein DoH‑Client muss HTTP/2 unterstützen (oder höher).

DNSCrypt

DNSCrypt ist ein alternatives DNS‑Verschlüsselungsprotokoll, vor allem in bestimmten Clients/Proxys (dnscrypt‑proxy, manche Appliances, etc.). Du nutzt es meist nur, wenn du bereits DNSCrypt‑Tooling oder spezielle Anforderungen hast.

DNS‑Performance: wie man eine Einschätzung bekommt, ohne sich zu täuschen

"Welcher DNS ist der schnellste?" ist eine tückische Frage, weil:

• der Cache (lokal + Resolver) die Tests verfälscht,
• die Performance von deinem Netz, Anycast und Peering abhängt,
• manche Apps vor allem die erste Auflösung spüren, andere vom Cache profitieren.

Eine einfache und ehrliche Methode:

1. Teste mehrere Namen (CDN, SaaS, interne Domains).
2. Wiederhole die Tests zu unterschiedlichen Zeiten.
3. Vergleiche Do53 und DoT/DoH, wenn du Verschlüsselung planst.

Schnelles Beispiel mit dig (auf mehrere Domains wiederholen):

dig @9.9.9.9 www.captaindns.com A +tries=1 +time=2
dig @149.112.112.112 www.captaindns.com A +tries=1 +time=2

Wenn du einen lokalen Forwarder (Unbound/dnsdist) hast, miss auch die Latenz aus Sicht der Endgeräte, nicht nur die des Forwarders.

Quad9 in der Praxis konfigurieren

Wo konfigurieren?

Es gibt 3 Ebenen, die nicht die gleichen Bedürfnisse abdecken:

1. Router/DHCP‑Ebene: einfach, deckt "fast alles" ab, aber oft Do53 (also unverschlüsselt).
2. Endgerät/OS‑Ebene: gut für natives DoT/DoH, hilfreich für mobile Laptops.
3. Lokaler Forwarder (empfohlen für KMU, wenn du überall Verschlüsselung willst): Endgeräte sprechen mit lokalem DNS und lokales DNS spricht DoT/DoH zu Quad9.

Option 1: Router und DHCP

Ziel: Alle Endgeräte nutzen Quad9, ohne jede Maschine anzufassen.

• Konfiguriere primären/sekundären DNS im LAN auf:
  • 9.9.9.9 und 149.112.112.112
  • (idealerweise auch die IPv6‑Äquivalente, falls dein LAN IPv6 nutzt)

Zu beachten:

• Ein Endgerät kann "tricksen" und einen statischen DNS setzen (oder DoH im Browser aktivieren).
• In "feindlichen" Netzen (Hotel, Hotspot) kann Port 53 abgefangen werden.

Option 2: Linux‑Endgeräte und ‑Server mit systemd‑resolved

Einfaches DoT‑Beispiel (an deine Distribution anpassen):

# /etc/systemd/resolved.conf
[Resolve]
DNS=9.9.9.9 149.112.112.112
DNSOverTLS=yes
DNSSEC=no

Anwenden:

sudo systemctl restart systemd-resolved
resolvectl status

⚠️ Vermeide es, DNSSEC zusätzlich im Forwarder/OS zu aktivieren, wenn dein Upstream bereits DNSSEC validiert: Das kann zu doppelter Validierung und nervigem Verhalten führen.

Option 3: Verschlüsselung per lokalem Forwarder erzwingen

Das ist die robusteste Strategie im Unternehmensnetz: Endgeräte nutzen dein internes DNS, und dein internes DNS verschlüsselt zu Quad9.

Beispiel mit Unbound (vereinfacht):

# /etc/unbound/unbound.conf.d/quad9.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 9.9.9.9@853#dns.quad9.net
  forward-addr: 149.112.112.112@853#dns.quad9.net

Dieses Muster bringt mehrere Vorteile:

• Verschlüsselung nach außen,
• lokaler Cache (schnellere Antworten),
• zentraler Kontrollpunkt (Observability, Troubleshooting).

Testen, ob du Quad9 und das richtige Protokoll nutzt

Test 1: Quad9‑Nutzung bestätigen

Quad9 bietet eine Kontrollseite: on.quad9.net. Wenn diese Seite nicht zeigt, dass du Quad9 nutzt, wird ein anderer DNS verwendet (VPN, erzwungenes DNS, statischer DNS etc.).

Test 2: Prüfen, ob es verschlüsselt ist: Do53, DoT oder DoH

Quad9 stellt einen praktischen "TXT‑Test" bereit.

Unter Linux/macOS:

dig +short txt proto.on.quad9.net.

Unter Windows PowerShell:

Resolve-DnsName -Type txt proto.on.quad9.net.

Mögliche Antworten (Beispiele):

• do53-udp / do53-tcp → unverschlüsseltes DNS
• dot → DNS‑over‑TLS
• doh → DNS‑over‑HTTPS
• dnscrypt-udp / dnscrypt-tcp → DNSCrypt

Wenn du NXDOMAIN bekommst: Deine Anfrage ging nicht zu Quad9.

Test 3: Einen Quad9‑Block prüfen

Quad9 nutzt eine Testdomain: isitblocked.org.

dig @9.9.9.9 isitblocked.org | grep "status\|AUTHORITY"

• NXDOMAIN + AUTHORITY: 0 → Quad9‑Block
• NXDOMAIN + AUTHORITY: 1 → Domain wirklich nicht existent

Update: Ende von DoH über HTTP/1.1 seit 15. Dezember 2025

⚠️Update

Merke - ⚠️ Quad9 hat DNS‑over‑HTTPS über HTTP/1.1 ab 15. Dezember 2025 eingestellt.

• Wenn du DoH nutzt, prüfe, dass deine Clients HTTP/2 sprechen (die meisten modernen Browser tun das bereits).
• Bekannte Problemgeräte: MikroTik RouterOS mit DoH (DoH‑Implementierung ohne HTTP/2).
• Bei Inkompatibilität ist der "ohne Überraschungen"‑Weg der Wechsel zu DoT (keine HTTP‑Schicht).

Wie du deine DoH‑Landschaft schnell auditierst

1. Inventar: Wer macht DoH? (Browser, Endpoint‑Agents, Router, Appliances, Forwarder).
2. HTTP/2‑Test am Quad9‑DoH‑Endpoint:

   curl --http2 -I https://dns.quad9.net/dns-query
   

3. Legacy‑Clients identifizieren: typischerweise Netzwerkgeräte, die DoH früh eingeführt haben, aber ohne HTTP/2‑Stack.
4. Fallback entscheiden (dokumentiere es!):
   • fallback zu DoT?
   • fallback zu Do53 (Risiko: Datenschutzverlust + mögliche Umleitung)?
5. Beobachtbar machen: Auf deinen Forwardern das tatsächlich genutzte Protokoll loggen und NXDOMAIN/SERVFAIL‑Raten überwachen.

Häufige Fallen in der Produktion

9.9.9.9 und 9.9.9.10 mischen

Das ist verlockend ("wenigstens löst es auf"), aber du verlierst:

• Sicherheitsabdeckung für einen Teil der Anfragen,
• Diagnosefähigkeit (ein Client landet "zufällig" auf dem einen oder anderen).

Wähle einen Dienst pro Umgebung und bleib dabei.

DNSSEC überall aktivieren

Wenn du bereits einen Upstream nutzt, der DNSSEC validiert (wie 9.9.9.9), kann DNSSEC in allen Kettengliedern:

• verlangsamen,
• Fehler komplizierter machen,
• die Zahl der "Bruchstellen" erhöhen.

Im Allgemeinen gilt: eine gut gemachte DNSSEC‑Validierung am richtigen Ort ist besser als zwei Validierungen in Kaskade.

VPN und "erzwungenes" DNS

Viele "Quad9 funktioniert nicht"‑Fälle kommen von erzwungenem DNS (oft in einem VPN‑Tunnel) oder einer App‑Konfiguration, die das Netzwerk‑DNS umgeht.

Reflex: Prüfe das tatsächlich verwendete Protokoll mit proto.on.quad9.net und die tatsächlich genutzte DNS‑IP auf dem Endgerät (nicht nur am Router).

Alternativen zu Quad9

Quad9 ist eine sehr gute Standardwahl, wenn du Sicherheit + Datenschutz mit einem öffentlichen Dienst willst. Je nach Anforderungen kannst du aber auch bevorzugen:

• Cloudflare (1.1.1.1): oft wegen Performance und Ökosystem gewählt.
• Google Public DNS (8.8.8.8): extrem verbreitet, leicht in Dev/Test‑Umgebungen zu finden.
• Cisco Umbrella / OpenDNS: interessant, wenn du im Cisco‑Ökosystem bist und zentrale Policies willst.
• NextDNS: nützlich für einen policy‑getriebenen Ansatz mit gerätespezifischen Profilen.
• AdGuard DNS: fokus auf Ad/Tracker‑Blocking mit vordefinierten Profilen.
• Self‑hosted: Unbound/Knot Resolver + Blocklisten (oft mit Pi‑hole) für maximale Kontrolle, mit mehr Betrieb.

Der richtige Reflex: Zuerst die Priorität wählen (Sicherheit, Datenschutz, Compliance, Kontrolle, Performance) und dann testen.

Aktionsplan

1. Quad9‑Dienst wählen
   • Standard: 9.9.9.9;
   • auf 9.9.9.11 wechseln nur bei echtem CDN‑Performance‑Problem;
   • 9.9.9.10 nur für Tests, nicht für Prod.
2. Integrationspunkt festlegen
   • Router/DHCP (einfach);
   • lokaler Forwarder (robust und verschlüsselt);
   • Endgerät/OS (mobile Nutzer).
3. Pilot ausrollen
   • eine Maschine, dann ein VLAN, dann das gesamte LAN.
4. Verschlüsselung aktivieren, wenn möglich
   • DoT zuerst (oft am stabilsten);
   • DoH, wenn nötig (aber HTTP/2 erforderlich bei Quad9).
5. Objektiv validieren
   • dig +short txt proto.on.quad9.net. sollte dot oder doh liefern, wenn du Verschlüsselung anstrebst.
6. Ausnahmen dokumentieren
   • VPN, Appliances, IoT, Gastnetze, Captive Portals.
7. DoH‑Änderung behandeln
   • Inventar der DoH‑Clients;
   • HTTP/1.1‑Clients updaten/ersetzen (z. B. MikroTik mit DoH);
   • expliziter Fallback zu DoT, wenn kein Upgrade möglich ist.
8. Signale beobachten
   • Peaks bei NXDOMAIN/SERVFAIL,
   • App‑Beschwerden ("löst nicht mehr auf"),
   • TLS/HTTP‑Fehler auf dem Forwarder.
9. Formalisieren
   • interne "DNS‑Standard"‑Seite (Adressen, Protokolle, Ausnahmen),
   • und eine Checkliste (siehe Export dieses Artikels).

FAQ

Ist Quad9 kostenlos und für KMU geeignet?

Ja. Für KMU ist Quad9 oft ein guter "Quick Win": Du reduzierst die Exposition gegenüber bösartigen Domains und verbesserst den DNS‑Datenschutz ohne schwere Infrastruktur.

Welche Quad9‑Adresse sollte ich im Alltag nutzen?

In 90% der Fälle: 9.9.9.9 und 149.112.112.112. 9.9.9.10 nur für gelegentliche Tests, und nur auf 9.9.9.11 wechseln, wenn du ein Routing/CDN‑Performance‑Problem identifiziert hast.

Wie prüfe ich, ob ich DoT oder DoH nutze?

Mach einen TXT‑Test: dig +short txt proto.on.quad9.net. (oder Resolve-DnsName unter Windows). Wenn die Antwort dot oder doh ist, ist es verschlüsselt. Wenn do53-udp, bist du auf klassischem DNS.

Warum sieht eine blockierte Domain wie ein DNS‑Ausfall aus?

Weil Quad9 beim Blockieren normalerweise NXDOMAIN zurückgibt. Zum Unterscheiden nutze die Testdomain isitblocked.org und prüfe den AUTHORITY‑Wert in der Antwort.

Mein Router unterstützt DoH, aber nichts löst mehr auf. Was tun?

Seit dem 15. Dezember 2025 akzeptiert Quad9 kein DoH über HTTP/1.1 mehr. Wenn dein Router/DoH‑Client HTTP/2 nicht unterstützt, wechsle zu DoT über ein kompatibles Endgerät/Forwarder oder ersetze den DoH‑Client.

Protokolliert Quad9 meine IP‑Adresse?

Quad9 sagt, dass keine IP‑Adressen im DNS‑Dienst gesammelt oder gespeichert werden und die Sammlung auf aggregierte technische Zähler begrenzt ist.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

• Vergleich öffentlicher DNS-Resolver (CSV)

Glossar

• Rekursiver Resolver: DNS‑Server, der die vollständige Auflösung (Cache + Anfragen an Root/TLD/Autoritative) durchführt und die Antwort an den Client liefert.
• Do53: klassisches DNS auf Port 53 (UDP/TCP), unverschlüsselt.
• DoT: DNS‑over‑TLS, DNS‑Verschlüsselung auf Transportebene (meist Port 853).
• DoH: DNS‑over‑HTTPS, DNS über HTTPS (Port 443). Bei Quad9 ist HTTP/2 seit 15. Dezember 2025 erforderlich.
• DNSSEC: kryptografischer Mechanismus zur Validierung der Authentizität von DNS‑Antworten signierter Zonen.
• NXDOMAIN: DNS‑Code für "Domain existiert nicht" (wird auch als Blocking‑Technik verwendet).
• SERVFAIL: DNS‑Code für Auflösungsfehler (oft bei DNSSEC‑Fehlern).
• ECS: EDNS Client Subnet, Erweiterung, die einen Standort‑Hinweis (Teil des IP‑Präfixes) an autoritative/CDN‑Server sendet.
• Anycast: Routing, bei dem mehrere Server die gleiche IP teilen und das Netz dich zum "nächstgelegenen" Punkt routet.
• DNS‑Forwarder: lokaler DNS‑Server, der Anfragen an einen Upstream (Quad9, andere) weiterleitet und Cache, Logs, Policies hinzufügen kann.

Offizielle Quellen

• Quad9 - DOH HTTP/1.1 Retirement December 15, 2025