DNS-Proxy vs. nur DNS: Was ändert sich und wann ist jeder Modus sinnvoll?

Die meisten Teams, die zu Cloudflare migrieren, betrachten die Wahl zwischen orangefarbener und grauer Cloud als Konfigurationsdetail. Sie aktivieren für alles einen Proxy, gehen davon aus, dass mehr Schutz immer besser ist, und entdecken den Fehler Wochen später, wenn eine Datenbank anfängt, eine Zeitüberschreitung ohne Fehlermeldung zurückzugeben – oder wenn sie feststellen, dass die Quell-IP immer in den wirklich wichtigen Datensätzen offengelegt wurde.

Was der Proxy-Modus tatsächlich macht

Wenn sich ein A- oder CNAME-Eintrag im Proxy-Modus befindet, gibt das autorisierende DNS von Cloudflare die IP Ihres Ursprungsservers nicht zurück. Es gibt eine Anycast-IP von Cloudflare selbst zurück. Der Client stellt eine Verbindung zu einem der Edge-Knoten des Netzwerks her, der TLS abschließt, die Anfrage prüft und den Datenverkehr erst dann an seinen Server weiterleitet – optional mit aktiviertem Caching, mit angewendeten WAF-Regeln und Workern, die die Anfrage auf halbem Weg abfangen.

Die tatsächliche IP des Servers ist vor dem öffentlichen DNS verborgen. Jede externe Abfrage an die Registrierung gibt Cloudflare-IPs zurück, nicht Ihre. Dies hat konkrete Auswirkungen: Ein Angreifer, der WAF umgehen möchte, muss die Quell-IP auf andere Weise ermitteln – durch durchgesickerte Protokolle, historische TLS-Zertifikate in crt.sh, E-Mail-Header oder direkte Verbindungen zu Nebendiensten, die ohne Proxy offengelegt wurden.

Die nach außen sichtbare TTL beträgt immer 300 Sekunden, unabhängig davon, was intern in der Zone konfiguriert ist. Cloudflare steuert, was externe Resolver empfangen und zwischenspeichern – die interne Konfiguration dient nur der Synchronisierung zwischen Cloudflares eigenen Nameservern.

Was der Nur-DNS-Modus bietet

Mit dem grauen Symbol fungiert Cloudflare ausschließlich als autorisierendes DNS. Die Namensabfrage gibt die echte IP des Servers zurück. Es gibt keine TLS-Terminierung am Rand, keine WAF, keinen Cache und keine Worker im Pfad. Der Client stellt eine direkte Verbindung zum Ursprungsserver her – und Cloudflare sieht den Datenverkehr nie.

Für MX-Einträge ist dieses Fehlen eines Proxys obligatorisch. Der E-Mail-Zustellungsablauf erfordert, dass sendende Server eine direkte Verbindung zu dem im MX-Eintrag angegebenen E-Mail-Server herstellen. Wenn der MX-Eintrag versuchen würde, den Cloudflare-Proxy zu passieren, würde das SMTP einen Edge-Knoten erreichen, der nicht weiß, was er mit dem Verkehr auf Port 25 tun soll – und die E-Mail würde einfach nicht ankommen. Cloudflare erlaubt Ihnen nicht einmal, Proxying für MX-Einträge zu aktivieren; Die Standardeinstellung ist nur DNS und kann nicht geändert werden.

Das Gleiche gilt für alle anderen TCP-Dienste als HTTP oder HTTPS auf unterstützten Ports. Der Cloudflare-Proxy versteht HTTP/HTTPS auf den Ports 80 und 443 sowie eine begrenzte Anzahl dokumentierter alternativer Ports – 8080, 8443 und einige andere. Alles außerhalb dieser Menge ist für den Proxy unsichtbar.

Die Datenbankfalle hinter einem Proxy-Datensatz

Dies ist das Szenario, das bei Vorfällen am leisesten auftritt. Ein A-Eintrag verweist auf einen Server, auf dem MySQL auf Port 3306 läuft. Das Team schaltet den Proxy-Modus ein, weil „wir mehr Schutz wollen“. Der Client versucht, eine Verbindung zu Port 3306 herzustellen – stellt jedoch jetzt eine Verbindung zum Cloudflare-Edge-Knoten her, der keinen willkürlichen TCP-Verkehr weiterleitet. Die Verbindung wird geöffnet, wartet und wird aufgrund einer Zeitüberschreitung geschlossen. Es gibt keine eindeutige Fehlermeldung. MySQL sieht den Verbindungsversuch nicht einmal.

Das Gleiche passiert mit PostgreSQL auf Port 5432, mit Redis auf Port 6379 und mit jedem Binärprotokoll außer HTTP. Der Proxy verwirft einfach Datenverkehr, den er nicht interpretieren kann. Um diese Dienste verfügbar zu machen, muss sich die Registrierung im Nur-DNS-Modus befinden – und die direkte Folge ist, dass die IP des Servers öffentlich sichtbar ist.

Auch Subdomain-Registrierungen für direktes SSH gehören in diese Kategorie. Wenn das Team einen ssh.exemplo.com-Eintrag verwaltet, der auf einen Bastion-Server verweist, muss es sich nur um einen DNS-Eintrag handeln. Proxyd unterbricht die Verbindung auf die gleiche Weise.

Prüfen Sie, was in Ihrem Bereich offengelegt wird

Die Frage, die es wert ist, regelmäßig gestellt zu werden, ist einfach: Welche Zoneneinträge befinden sich im Nur-DNS-Modus und ist der durch sie fließende Datenverkehr auf andere Weise geschützt?

Nur DNS-Einträge legen IP-Adressen offen, mit denen der Ursprung direkt angegriffen werden kann, wobei alle in den Proxy-Einträgen konfigurierten WAF-Regeln umgangen werden. Wenn ein Server sowohl in einem Proxy-Eintrag als auch in einem anderen Nur-DNS-Eintrag erscheint – oder wenn die IP irgendwann in der Vergangenheit offengelegt wurde und in Diensten wie Shodan indiziert ist – ist die Schutzwirkung des Proxys teilweise.

Um die Quell-IP-Offenlegung in HTTP-Diensten vollständig zu eliminieren, löst Cloudflare Tunnel das Problem endgültig. Der Ursprungsserver stellt mithilfe des cloudflared-Daemons eine ausgehende Verbindung zum Cloudflare-Netzwerk her. Der Benutzerverkehr kommt am Edge an, wird zum Server getunnelt und der Server muss niemals eingehende Verbindungen akzeptieren – es gibt keinen offenen Port, keine offengelegte IP. Für beliebigen TCP-Verkehr außerhalb von HTTP deckt Cloudflare Spectrum dieses Szenario ab, ist jedoch exklusiv für den Enterprise-Plan verfügbar.

Was Sie überprüfen sollten, bevor Sie die Konfiguration als abgeschlossen betrachten

Zonen, die im Laufe der Zeit wachsen, sammeln Aufzeichnungen an, die in unterschiedlichen Kontexten von verschiedenen Personen erstellt wurden und deren Absichten manchmal nicht dokumentiert sind. Ein *.exemplo.com-Platzhalter im Proxy-Modus ist legitim und nützlich für dynamisch erstellte Subdomains – er kann jedoch die Tatsache verschleiern, dass bestimmte Datensätze innerhalb dieses Platzhalters nur aus Gründen, an die sich niemand mehr erinnert, manuell als DNS erstellt wurden.

TXT- und CAA-Datensätze werden niemals per Proxy weitergeleitet – es handelt sich um Daten, die Kunden direkt lesen müssen, und Cloudflare greift nicht ein. SRV und NS liegen ebenfalls außerhalb des Proxys. In diesen Fällen bietet die Schnittstelle nicht einmal diese Option an.