Cloudflare DNS (1.1.1.1): Datenschutz, DoH/DoT, Deployment

Von CaptainDNS
Veröffentlicht am 23. Dezember 2025

#DNS
#Cloudflare
#1.1.1.1
#DNS-Resolver
#Datenschutz
#DoH
#DoT
#Sicherheit

Illustration: 1.1.1.1 (Cloudflare), öffentlicher DNS-Resolver mit DoH/DoT/ODoH-Optionen und Fokus auf Datenschutz

TL;DR

📢 1.1.1.1 ist der öffentliche DNS von Cloudflare: leicht zu deployen und interessant, wenn Sie ein "sauberes" DNS in Sachen Datenschutz wollen.
Merken Sie sich die 3 nützlichen Varianten: 1.1.1.1 (ohne Filter), 1.1.1.2 (blockiert Malware), 1.1.1.3 (blockiert Malware + Inhalte für Erwachsene).
Um Mithören und Abfangen auf der letzten Meile zu vermeiden, bevorzugen Sie einen verschlüsselten Transport (DoT/DoH) oder, wenn Ihre Tools es unterstützen, ODoH.
Ops-Punkt: eine Fallback-Strategie vorsehen (zweiter Resolver oder lokaler Cache); ein Cloudflare-Vorfall 2025 hat gezeigt, dass ein Public DNS ausfallen kann.

Ihr "Default"-DNS (oft das Ihres ISP via DHCP) ist selten eine bewusste Wahl. Dennoch sieht der Resolver alle Domains, die Ihre Systeme erreichen wollen, und kann Performance, Datenschutz, Sicherheit und Verfügbarkeit beeinflussen.

In diesem Teil unserer Serie über öffentliche Resolver konzentrieren wir uns auf Cloudflare 1.1.1.1: was es ist, was es verspricht (und was nicht), wie man es im Klartext oder verschlüsselt aktiviert, wie man es testet und wie man es sauber in KMU integriert.

Zielgruppe: Heimnetz, aber auch Unternehmen – für Admins, DevOps oder KMU-CTOs, die eine pragmatische, auditierbare und reversible Konfiguration wollen.

1.1.1.1: worum geht es genau?

1.1.1.1 ist eine IP-Adresse, die auf einen öffentlichen rekursiven DNS-Resolver von Cloudflare zeigt. In der Praxis bedeutet die Konfiguration Ihrer Systeme (oder Ihres Routers) auf 1.1.1.1:

Ihre Geräte senden DNS-Anfragen an Cloudflare (statt an den DNS Ihres ISP),
Cloudflare antwortet aus dem Cache, wenn möglich,
ansonsten löst Cloudflare rekursiv (Root → TLD → autoritative Server) und liefert die Antwort zurück.

Cloudflare bietet außerdem "fertige" Varianten:

1.1.1.1 / 1.0.0.1: Resolver ohne Filterung ("rohe" DNS-Antworten).
1.1.1.2 / 1.0.0.2: Malware-Blockierung (Cloudflare "Families").
1.1.1.3 / 1.0.0.3: Malware- + Erwachseneninhalte-Blockierung (Cloudflare "Families").

DNS-Auflösung mit 1.1.1.1: Do53 vs DoT/DoH

Cloudflare-Adressen und -Endpoints, die man kennen sollte (Merkliste)

Sie werden häufig zwei Fragen beantworten müssen:

Welche IPs als primär/sekundär (IPv4/IPv6)?
Welchen Endpoint nutzen, wenn ich verschlüsseln will (DoH/DoT)?

Referenztabelle (zum Copy-Paste in Ihre Verfahren):

Service	Einsatz	IPv4	IPv6	DoH (HTTPS)	DoT (TLS)
1.1.1.1 (ohne Filterung)	Allgemeiner Fall ohne Filterung	`1.1.1.1`, `1.0.0.1`	`2606:4700:4700::1111`, `2606:4700:4700::1001`	`https://cloudflare-dns.com/dns-query`	`one.one.one.one`
Families (Malware)	Risiko "Klick" reduzieren	`1.1.1.2`, `1.0.0.2`	`2606:4700:4700::1112`, `2606:4700:4700::1002`	`https://security.cloudflare-dns.com/dns-query`	`security.cloudflare-dns.com`
Families (Adult+Malware)	Familiennetz, Gäste, öffentliche Orte	`1.1.1.3`, `1.0.0.3`	`2606:4700:4700::1113`, `2606:4700:4700::1003`	`https://family.cloudflare-dns.com/dns-query`	`family.cloudflare-dns.com`

Ops-Notizen, die Sie kennen sollten:

Do53 (UDP/TCP 53): Sie setzen IPs (z. B. 1.1.1.1) in Ihren Netzwerk-/DHCP-Einstellungen.
DoT/DoH: Sie müssen einen kompatiblen Client konfigurieren (OS, Browser, DNS-Proxy am Router, lokaler DNS-Relay usw.).
Für DoH bevorzugen Sie die Konfiguration per Hostname (cloudflare-dns.com) statt "per IP", um bestimmte Anycast-Incidents zu vermeiden (mehr dazu unten).

Datenschutz: was 1.1.1.1 verspricht (und wie man es als Admin liest)

Die richtige Einordnung: DoT/DoH verschlüsseln den Transport zwischen Client und Resolver. Der Resolver sieht aber weiterhin die angefragten Domains (sonst könnte er nicht antworten). Am Ende wählen Sie vor allem, wem Sie Ihren DNS anvertrauen und wie Sie die letzte Meile schützen.

Cloudflare dokumentiert seine Datenschutz-Zusagen für den 1.1.1.1-Resolver, u. a.:

kein Verkauf/Sharing personenbezogener Daten der Resolver-Nutzer an Dritte, keine Werbung,
begrenzte Aufbewahrung (Resolver-Logs werden nach ~25 Stunden gelöscht),
keine Speicherung der Quell-IP im "non-volatile storage", mit Anonymisierung/Trunkierung,
sehr geringe Stichprobe von Netzwerkpaketen für Troubleshooting/DoS-Mitigation,
begrenztes Sharing aggregierter Daten mit APNIC zu Forschungszwecken.

Operative Übersetzung:

Wenn Sie vor allem lokale Beobachtung vermeiden wollen (Wi-Fi, ISP, Gastnetz): DoT/DoH aktivieren.
Wenn Ihr Ziel "möglichst geringe Spur beim Anbieter" ist: Lesen Sie die Retention-Policy und fragen Sie sich, ob Sie einen Anbieter mit "kurzen Logs" (Cloudflare) vs "ohne IP" (z. B. Quad9) vs einen Anbieter mit längeren temporären Logs (z. B. Google) bevorzugen.
Wenn Ihr Ziel Compliance ist: Mischen Sie nicht "Public DNS" und "Enterprise DNS". Für Policies (Kategorien, Ausnahmen, Logs, Analytics) wollen Sie meist Managed DNS (Zero Trust / DNS-Gateway) oder einen internen Resolver.

Do53, DoT, DoH, ODoH: den richtigen Transport wählen

Hilfreiche Abkürzung: den Resolver wechseln (1.1.1.1 vs ISP-DNS) bedeutet nicht automatisch DNS zu verschlüsseln.

Do53 (klassisches DNS)

Ports: UDP/53 (hauptsächlich), manchmal TCP/53.
Vorteil: universell, einfach (Router/DHCP).
Grenzen: lesbar/abfangbar im Netz; einige Umgebungen schreiben DNS um.

DoT (DNS-over-TLS)

Port: TCP/853.
Vorteil: verschlüsseltes DNS, oft nativ auf OS-Ebene unterstützt (Android "Private DNS", systemd-resolved, einige Router).
Grenzen: Port 853 ist manchmal gefiltert.

DoH (DNS-over-HTTPS)

Port: HTTPS 443.
Vorteil: schwerer zu blocken (es ist HTTPS), gut in "feindlichen" Netzen.
Grenzen: im Bestand müssen Sie wissen, wer DoH nutzt (Browser, Agenten, DNS-Proxy...), sonst verlieren Sie die Kontrolle über den DNS-Pfad.

ODoH (Oblivious DoH)

Idee: "wer fragt" (Quell-IP) von "was gefragt wird" (Domainname) via Proxy trennen.
Vorteil: reduziert die Fähigkeit eines einzelnen Akteurs, IP ↔ Anfragen zu verknüpfen.
Grenzen: noch kein "universeller Standard" im Enterprise; Client-Support ist rar; als Advanced-Option behandeln.

Do53 / DoT / DoH / ODoH je nach Netzwerkbedingungen wählen

Aktuelles 2025: der globale 1.1.1.1-Ausfall und die Lehre

Am 14. Juli 2025 erlitt Cloudflare einen globalen Ausfall seines 1.1.1.1-Resolvers (ca. 62 Minuten). In solchen Incidents ist der Effekt für Nutzer brutal: "Internet ist kaputt", weil nichts mehr auflöst.

Ein interessanter Punkt aus dem Post-mortem: DoH-Traffic blieb stabiler, weil viele DoH-Clients den Domainnamen cloudflare-dns.com nutzen (andere Anycast-Oberfläche) statt DoH "per IP".

Die Admin-Schlussfolgerung ist nicht, 1.1.1.1 zu meiden, sondern es korrekt zu integrieren:

nicht von einem einzigen Resolver abhängen,
eine Fallback-Strategie hinzufügen,
regelmäßig beobachten und testen.

Deployment in KMU: 3 Modelle, die funktionieren (und ihre Fallstricke)

Modell 1: Router/DHCP (schnell, aber oft im Klartext)

Ziel: das ganze LAN umstellen, ohne jede Maschine anzufassen.

LAN-DNS auf 1.1.1.1 und 1.0.0.1 setzen (und IPv6, wenn vorhanden).
Beachten: Das ist meist Do53 (unverschlüsselt) und einige Geräte können es umgehen (statisches DNS, Browser-DoH, VPN).

Modell 2: Konfiguration am OS (gut für natives DoT/DoH)

Typische Fälle: mobile Laptops, kritische Server, Mobile-Fleet.

Konkrete Beispiele:

Android 9+ (DoT via "Private DNS"): Provider auf one.one.one.one setzen (oder security.cloudflare-dns.com / family.cloudflare-dns.com je nach Bedarf).
Browser (DoH): unterwegs nützlich, aber Achtung: kann Ihr Enterprise-DNS umgehen.

Modell 3: Lokaler DNS-Forwarder (empfohlen, wenn Sie "überall" verschlüsseln wollen)

Ziel: Geräte sprechen mit einem lokalen DNS (Cache + Kontrolle), und dieser lokale DNS spricht per DoT/DoH zu 1.1.1.1.

Vorteile:

Verschlüsselung nach außen,
lokaler Cache (geringere gefühlte Latenz),
zentraler Kontrollpunkt (Beobachtbarkeit, Troubleshooting, Failover).

Minimalbeispiel mit Unbound über DoT (anpassen):

# /etc/unbound/unbound.conf.d/cloudflare-1111.conf
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#one.one.one.one
  forward-addr: 1.0.0.1@853#one.one.one.one

Und auf den Clients zeigen Sie auf Ihren DNS-Forwarder (z. B. 10.0.0.53) statt direkt auf 1.1.1.1.

Empfohlene Architektur: lokaler Cache + Failover

Wirklich testen, ob Sie 1.1.1.1 und das richtige Protokoll nutzen

Test 1: Auf der Cloudflare-Seite prüfen

Cloudflare bietet eine Diagnose-Seite: Öffnen Sie https://1.1.1.1/help von einem Gerät im Netzwerk. Sie zeigt, ob Sie mit 1.1.1.1 verbunden sind und ob Sie DoH/DoT verwenden.

Test 2: Eine einfache Auflösung testen

dig @1.1.1.1 cloudflare.com A +tries=1 +time=2
dig @1.0.0.1 cloudflare.com AAAA +tries=1 +time=2

Test 3: DoH per Kommandozeile testen

curl -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Aktionsplan (ready for prod)

Inventar: Wo ist DNS heute definiert (DHCP, statisch, VPN, Browser, Agenten)?
Ziel wählen: Datenschutz auf der letzten Meile (DoT/DoH), simples Filtering (Families) oder feine Kontrolle (DNS-Gateway/Managed Lösung).
Modell wählen: Router/DHCP (schnell), OS (mobile Nutzer), lokaler DNS-Forwarder (robust).
Verschlüsselung dort aktivieren, wo es zählt: mindestens auf mobilen Geräten und/oder via DNS-Forwarder.
Fallback planen: sekundärer Resolver oder mindestens lokaler Cache + dokumentierter Failover.
Tests: 1.1.1.1/help, dig und ein DoH/DoT-Test passend zu Ihrem Tooling.
Beobachtbarkeit: SERVFAIL/NXDOMAIN-Rate, Latenz, Timeouts und Incidents überwachen.

FAQ

Ist 1.1.1.1 wirklich privater als das DNS meines ISP?

Ja, in der Praxis, vor allem wenn Sie DoT/DoH aktivieren: Sie vermeiden Beobachtung und Abfangen im lokalen Netz und beim ISP. Sie vertrauen Ihre Anfragen dann aber Cloudflare an: entscheidend sind Log-Policy und Vertrauen in den Anbieter.

DoH oder DoT: was sollte ich im Unternehmen wählen?

Wählen Sie DoT, wenn Sie das Netzwerk kontrollieren (Port 853 erlaubt) und eine "reine DNS"-Implementierung wollen. Wählen Sie DoH, wenn Sie oft in filternden Netzen sind (Hotels, öffentliches Wi-Fi) oder über 443 gehen müssen.

Browser-DoH: gute Idee oder Falle?

Gute Idee unterwegs (unsicheres Netz), aber Falle im Enterprise: der Browser kann Ihr internes DNS umgehen (Split-Horizon, interne Domains, Policies). Wenn Sie ein Firmen-DNS haben, definieren Sie eine klare Policy (erlauben, via DNS-Proxy erzwingen oder deaktivieren).

Warum ein sekundäres DNS hinzufügen, wenn 1.1.1.1 Anycast ist?

Weil Anycast globale Ausfälle nicht verhindert, und ein DNS-Incident wie ein Internet-Ausfall wirkt. Der beste Kompromiss: lokaler DNS-Cache/Forwarder + ein oder zwei Upstream-Resolver, plus dokumentierter Failover.

Ist ODoH etwas für mich?

Wenn Sie bereits einen fortgeschrittenen DNS-Stack haben und den starken Bedarf, IP ↔ Anfragen zu entkoppeln (sensible Fälle), kann ein POC sinnvoll sein. Sonst liefern DoT/DoH + eine klare Log-Policy bereits 80% des Nutzens bei deutlich weniger Komplexität.

Vergleichstabellen herunterladen

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

Vergleich öffentlicher DNS-Resolver (CSV)

Glossar

Rekursiver DNS-Resolver: Server, der einen Domainnamen in eine IP auflöst, indem er Root, TLDs und autoritative Server abfragt, und dann cached.
Do53: klassisches DNS im Klartext über UDP/TCP Port 53.
DoT: DNS-over-TLS, verschlüsseltes DNS über TCP/853.
DoH: DNS-over-HTTPS, verschlüsseltes DNS über HTTPS/443.
ODoH: Oblivious DoH, Variante mit Proxy zur Entkopplung von Quell-IP und Anfrageinhalt.
Anycast: Routing, das Traffic zum "nächstgelegenen" POP (routing-seitig) schickt, genutzt von großen Resolvern.
NXDOMAIN: DNS-Antwort, die anzeigt, dass ein Name nicht existiert.
SERVFAIL: Auflösungsfehler (Upstream nicht verfügbar, Validierung, Timeouts usw.).