Cloudflare DNS: Netzwerkinfrastruktur, die weit über die Namensauflösung hinausgeht

DNS wird als Standardinfrastruktur behandelt: Sie geben die Nameserver an, konfigurieren einen A-Eintrag und einen MX-Eintrag und vergessen es. Was Cloudflare mit einem Proxy-Eintrag macht, verstößt gegen diese Prämisse – das Protokoll existiert immer noch, aber was passiert, wenn Sie den Proxy-Modus aktivieren, ändert die Bedeutung von DNS in Ihrer Architektur.

Was ändert sich, wenn Sie einen Datensatz als Proxy verwenden?

Wenn Sie in Cloudflare einen A-Eintrag erstellen und den Proxy (das orangefarbene Wolkensymbol) aktivieren, ist die IP-Adresse, die Ihre Clients in der DNS-Antwort erhalten, nicht Ihre Ursprungs-IP. Cloudflare gibt eine seiner eigenen IPs zurück – Adressen, die zum Anycast-Netzwerk des Unternehmens gehören und über mehr als 300 Points of Presence auf der ganzen Welt verteilt sind.

Jede HTTP- und HTTPS-Anfrage, die diese Domäne erreicht, gelangt in das Cloudflare-Netzwerk, bevor sie Ihren Server erreicht. TLS wird am PoP beendet, der dem Client am nächsten liegt. Die WAF prüft die Anfrage. Es gelten Tarifbegrenzungsregeln. Der Cache wird konsultiert. Die DDoS-Abwehr funktioniert am Netzwerkrand. Erst dann – wenn die Anfrage alle diese Ebenen durchlaufen hat – wird sie in einer separaten Verbindung über das interne Netzwerk von Cloudflare an ihren Ursprung weitergeleitet. Die tatsächliche IP-Adresse Ihres Servers bleibt für jeden externen Client verborgen.

DNS ist in diesem Modell der Einstiegspunkt für die gesamte Sicherheits- und Leistungskette – nicht der Dienst, der ihr vorangeht.

Anycast: Warum 300 PoPs für die Latenz wichtig sind

Die meisten Netzwerke arbeiten mit Unicast-Routing – jede IP wird von einem einzigen Standort aus bekannt gegeben und das Paket legt die gesamte Distanz bis zu diesem Rechenzentrum zurück, unabhängig davon, wo sich der Kunde befindet.

Das Cloudflare-Netzwerk funktioniert mit Anycast: Über BGP wird von jedem der mehr als 300 Points of Presence gleichzeitig derselbe IP-Adressblock bekannt gegeben. Wenn ein Kunde eine Cloudflare-IP in der DNS-Antwort erhält, leitet die BGP-Infrastruktur des Internets das Paket an den geografisch nächstgelegenen PoP weiter. Dort wird TLS beendet, nur wenige Millisekunden vom Client entfernt. Die Route zu ihrem Ursprung – der möglicherweise in einer anderen Region der Welt liegt – erfolgt über das private Netzwerk von Cloudflare mit optimierten Routen zwischen PoPs, die für den Endbenutzer unsichtbar sind.

Ausbreitung, TTL und die Trennung zwischen autorisierend und rekursiv

Im DNS-Angebot von Cloudflare existieren zwei unterschiedliche Rollen nebeneinander, und ihre Verwechslung führt bei Vorfällen zu falschen Erwartungen. Der autorisierende Dienst – wenn Sie Ihre Domain an die Nameserver von Cloudflare delegieren – antwortet mit der Autorität über Ihre Datensätze. 1.1.1.1 ist ein öffentlicher rekursiver Resolver, ein separater Dienst, der im Namen von Clients autorisierende Server abfragt. Sie können Cloudflare-Nameserver für Ihre Domain verwenden, ohne jemals 1.1.1.1 zu verwenden, und umgekehrt.

Wenn Sie einen Datensatz im Cloudflare-Dashboard ändern, wird die Änderung in etwa 30 Sekunden über das maßgebliche Netzwerk verbreitet – eine beeindruckende Zahl für Anbieter, die Stunden für die Aktualisierung von Zonen benötigen. Das Problem besteht darin, dass die „Weitergabe“ in dem Sinne, dass sie echte Benutzer betrifft, von einer anderen Ebene abhängt: den rekursiven Resolvern.

Resolver wie Googles 8.8.8.8 und ISP-Resolver speichern Antworten anhand der TTL der Registrierung im Cache. Wenn die TTL bei 3600 Sekunden lag, als ein Resolver die Anfrage stellte, antwortet er bis zu einer Stunde lang mit dem alten Wert – selbst wenn Cloudflare den neuen Rekord bereits 30 Sekunden lang bereitgestellt hat. Bei der „vollständigen Weitergabe“ an alle Clients wird genau die maximale TTL verwendet, die zum Zeitpunkt der Änderung gültig war.

Die Standard-TTL für Nicht-Proxy-Registrierungen bei Cloudflare beträgt 300 Sekunden. Proxy-Datensätze stellen extern immer eine TTL von 300 Sekunden zur Verfügung, unabhängig vom internen Wert – Cloudflare benötigt diese Flexibilität, um seine eigenen Anycast-IPs zu verwalten. Vor jeder geplanten Änderung – Quellmigration, Failover, IP-Rotation – besteht die richtige Vorgehensweise darin, die TTL im Voraus auf 60 oder 300 Sekunden zu reduzieren, darauf zu warten, dass die Resolver den Cache aktualisieren, die Änderung auszuführen und die TTL später zu erhöhen. In umgekehrter Reihenfolge bedeutet dies, dass man genau dann mit einer langsamen Ausbreitung leben muss, wenn die Kosten höher sind.

CNAME-Flattening und das Apex-Problem

Die ursprüngliche DNS-Spezifikation verbietet CNAME am Domänen-Apex – exemplo.com selbst ohne Subdomäne –, da es mit den erforderlichen SOA- und NS-Einträgen in Konflikt steht. Dies zwang Teams jahrelang dazu, feste IPs im A-Eintrag der Stammdomäne festzulegen, was zu Reibungen mit Diensten führte, die keine statischen IPs garantieren: Load Balancer in AWS legen nur DNS-Namen offen, keine IPs.

Cloudflare löst dieses Problem mit CNAME Flattening. Wenn Sie einen CNAME für den Apex konfigurieren, löst Cloudflare das Ziel in Echtzeit auf – indem es zum Zeitpunkt der Anfrage die A- und AAAA-Adressen des Ziels abfragt – und gibt diese IPs direkt an den Client zurück. Aus Sicht des externen Resolvers handelt es sich um einen normalen A-Record.

Was verlangt das von denen, die die Produktion leiten?

Teams, die DNS als statische Konfiguration behandeln, haben beim Betrieb mit Cloudflare besondere Probleme. Der Proxy-Modus jeder Registrierung – ein- oder ausgeschaltet – bestimmt, ob Edge-Sicherheits- und Leistungssysteme im Weg stehen oder nicht. Ein A-Eintrag mit deaktiviertem Proxy legt die echte IP der Quelle offen, macht den DDoS-Schutz ungültig und entfernt die WAF aus dem Stream. Die Prüfung, welche Datensätze weitergeleitet werden und welche nicht, ist keine anfängliche Implementierungsaufgabe; muss Teil des Änderungsüberprüfungsprozesses sein.

TTL verdient fortlaufende operative Aufmerksamkeit. Eine hohe TTL reduziert die autorisierende Last und verbessert den Cache in Resolvern, erhöht jedoch die Wiederherstellungszeit für Routenänderungen. Die Ausbreitungszeittoleranz unterscheidet sich häufig zwischen kritischen Datensätzen wie MX und internen Service-Subdomänen – und dieser Unterschied sollte in den Zoneneinstellungen explizit angegeben werden.