Wir präsentieren Foundation DNS, das neue erstklassige DNS-Angebot von Cloudflare

Heute stellen wir Foundation DNS vor, das neue Premium-DNS-Angebot von Cloudflare, das unvergleichliche Zuverlässigkeit und höchste Performance bietet und in der Lage ist, die komplexesten Anforderungen von Infrastrukturteams zu erfüllen.

Wenn Sie einen DNS-Vertrag für ein Unternehmen abschließen, verlangen DNS-Anbieter in der Regel drei Angaben von Ihnen, um ein Angebot zu erstellen:

• Anzahl an Zonen

• Gesamte DNS-Abfragen pro Monat

• Gesamte DNS-Einträge in allen Zonen

Einige sind wesentlich komplizierter und viele haben Preiskalkulatoren oder undurchsichtige „Kontaktieren Sie uns“-Preise. Die Planung eines Budgets, das Ihr Wachstum berücksichtigt, bringt unnötige Komplexität mit sich. Wir glauben, dass wir es besser machen können. Warum sollte man das nicht noch einfacher machen? So geht's: Wir haben beschlossen, Foundation DNS auf der Grundlage eines einzigen Inputs für unsere Unternehmenskunden zu berechnen: Gesamte DNS-Abfragen pro Monat. Auf diese Weise wollen wir den Unternehmen Geld sparen und, was noch wichtiger ist, die Komplexität ihrer DNS-Rechnung verringern.

Und keine Sorge, genau wie der Rest unserer Produkte ist auch die DDoS-Abwehr weiterhin im Volumen unbegrenzt. Es fallen keine versteckten Gebühren an, falls Ihre Nameserver durch DDoS angegriffen werden oder die Anzahl der DNS-Abfragen Ihr Kontingent für ein oder zwei Monate übersteigt.

Das Domain Name System (DNS) ist fast so alt wie das Internet selbst. Es wurde ursprünglich 1983 in RFC882 und RFC883 aus der Notwendigkeit heraus definiert, eine Zuordnung zwischen Hostnamen und IP-Adressen zu schaffen. Damals stellten die Autoren weise fest: „[Das Internet] ist ein großes System und wird wahrscheinlich noch viel größer werden.“ [RFC882]. Heute gibt es allein unter .com, einer der größten Top Level Domains (TLD), fast 160 Millionen Domain-Namen [Quelle].

DNS ist ein hierarchisches und hochgradig verteiltes System, aber als Endbenutzer kommunizieren Sie in der Regel nur mit einem Resolver (1), der entweder von Ihrem Internet Service Provider (ISP) zugewiesen oder betrieben wird oder direkt von Ihrem Arbeitgeber oder Ihnen selbst konfiguriert wird. Der Resolver kommuniziert mit einem der Root-Server (2), dem zuständigen TLD-Server (3) und dem autoritativen Nameserver (4) der betreffenden Domain. In vielen Fällen werden alle vier Parteien von einer anderen Einrichtung betrieben und befinden sich in verschiedenen Regionen, vielleicht sogar auf verschiedenen Kontinenten.

Wie wir in der jüngsten Vergangenheit gesehen haben, sind Sie in ernsten Schwierigkeiten, wenn Ihre DNS-Infrastruktur ausfällt, und es wird Sie wahrscheinlich eine Menge Geld kosten und möglicherweise Ihren Ruf schädigen. Als Domain-Inhaber möchten Sie also, dass DNS-Abfragen zu Ihrer Domain zu 100 % beantwortet werden, und zwar idealerweise so schnell wie möglich. Was können Sie also tun? Sie können nicht beeinflussen, welchen Resolver Ihre Benutzer konfiguriert haben. Sie können den Root-Server nicht beeinflussen. Sie können wählen, welcher TLD-Server beteiligt ist, indem Sie einen Domain-Namen mit der entsprechenden TLD wählen. Wenn Sie aber aus anderen Gründen an eine bestimmte TLD gebunden sind, haben Sie auch darauf keinen Einfluss. Was Sie jedoch leicht beeinflussen können, ist der Provider für Ihre autoritativen Nameserver. Werfen wir also einen genaueren Blick auf das autoritative DNS-Angebot von Cloudflare.

Autoritatives DNS ist eines unserer ältesten Produkte, und wir haben viel Zeit darauf verwendet, es zu einem großartigen Produkt zu machen. Alle DNS-Anfragen werden von unserem globalen Anycast-Netzwerk beantwortet, das in mehr als 250 Städten Präsenz hat. Auf diese Weise können wir eine hervorragende Performance bieten und gleichzeitig eine globale Verfügbarkeit garantieren. Und natürlich nutzen wir unsere umfassende Erfahrung bei der Abschwächung von DDoS-Angriffen, um zu verhindern, dass jemand unsere Nameserver und damit die Domains unserer Kunden lahmlegt.

DNS ist für Cloudflare von entscheidender Bedeutung, denn bis zur Veröffentlichung von Magic Transit war DNS die Art und Weise, wie jeder Nutzer im Internet zu Cloudflare geleitet wurde, um die Anwendungen unserer Kunden zu schützen und zu beschleunigen. Wenn unsere DNS-Antworten langsam waren, war Cloudflare langsam. Wenn unsere DNS-Antworten nicht verfügbar waren, war auch Cloudflare nicht verfügbar. Die Geschwindigkeit und Zuverlässigkeit unseres autoritativen DNS ist für die Geschwindigkeit und Zuverlässigkeit von Cloudflare von größter Bedeutung, ebenso wie für unsere Kunden. Auch unsere Kunden haben unsere DNS-Infrastruktur in dem Maße erweitert, wie sie mit Cloudflare gewachsen sind. Heute hat unsere größte Kundenzone mehr als 3 Millionen Datensätze und die Top 5 erreichen zusammen fast 10 Millionen Datensätze. Diese Kunden verlassen sich darauf, dass Cloudflare neue DNS-Datensatz-Updates in Sekunden, nicht Minuten, an unsere Edge weiterleitet. Aufgrund dieser Bedeutung und der Bedürfnisse unserer Kunden haben wir im Laufe der Jahre unser engagiertes DNS-Engineering-Team ausgebaut, das sich darauf konzentriert, dass unser DNS-Stack schnell und zuverlässig bleibt.

Die Sicherheit des DNS-Ökosystems ist ebenfalls wichtig. Cloudflare war schon immer ein Befürworter von DNSSEC. Das Signieren und Validieren von DNS-Antworten durch DNSSEC stellt sicher, dass ein Angreifer auf dem Pfad keine Antworten kapern und den Traffic umleiten kann. Cloudflare hat DNSSEC schon immer kostenlos für alle Tarifstufen angeboten, und es wird auch weiterhin eine kostenlose Option für Foundation DNS sein. Für Kunden, die Cloudflare auch als Registrar nutzen, ist die einfache Ein-Klick-Einrichtung von DNSSEC eine weitere wichtige Funktion, die sicherstellt, dass die Domains unserer Kunden nicht gekapert werden und ihre Nutzer geschützt sind. Wir unterstützen RFC 8078 für die Ein-Klick-Bereitstellung auf externen Registraren ebenfalls.

Es gibt jedoch auch andere Probleme, die Teile des Internets zum Stillstand bringen können, und diese liegen meist außerhalb unserer Kontrolle: Routenlecks oder, noch schlimmer, Routen-Hijacking. DNSSEC kann zwar bei der Eindämmung von Routen-Hijackings helfen, aber leider validieren nicht alle rekursiven Resolver. Und selbst wenn der Resolver die Validierung vornimmt, führt ein Routenleck oder ein Hijack auf Ihre Nameserver immer noch zu Ausfallzeiten. Wenn alle IPs Ihrer Nameserver von einem solchen Ereignis betroffen sind, wird Ihre Domain unauflösbar.

Bei vielen Providern wird jeder Ihrer Nameserver in der Regel nur zu einer IPv4- und einer IPv6-Adresse aufgelöst. Wenn diese IP-Adresse nicht erreichbar ist – z. B. wegen Netzwerküberlastung oder, noch schlimmer, wegen eines Routenlecks – wird der gesamte Nameserver nicht mehr erreichbar, was dazu führt, dass Ihre Domain nicht mehr aufgelöst werden kann. Noch schlimmer ist, dass einige Anbieter sogar das gleiche IP-Subnetz für alle ihre Nameserver verwenden. Wenn es also ein Problem mit diesem Subnetz gibt, sind alle Nameserver ausgefallen.

Schauen wir uns ein konkretes Beispiel an:

Alle Nameserver-IPs sind Teil von 205.251.192.0/21. Glücklicherweise signiert AWS jetzt ihre Bereiche bis RPKI, was die Wahrscheinlichkeit eines Lecks verringert...vorausgesetzt, der ISP des Resolvers validiert RPKI. Wenn der Resolver-ISP die RPKI jedoch nicht validiert und dieses Subnetz undicht wird oder gekapert wird, können Resolver keinen der Nameserver erreichen und aws.com wäre nicht mehr auffindbar.

$ dig aws.com ns +short              
ns-1500.awsdns-59.org.
ns-164.awsdns-20.com.
ns-2028.awsdns-61.co.uk.
ns-917.awsdns-50.net.

$ dig ns-1500.awsdns-59.org. +short
205.251.197.220
$ dig ns-164.awsdns-20.com. +short
205.251.192.164
$ dig ns-2028.awsdns-61.co.uk. +short
205.251.199.236
$ dig ns-917.awsdns-50.net. +short
205.251.195.149

Es versteht sich von selbst, dass Cloudflare alle unsere Routen signiert und den Rest des Internets dazu drängt, die Auswirkungen von Routenlecks zu minimieren, aber was können wir sonst noch tun, um sicherzustellen, dass unsere DNS-Systeme gegen Routenlecks resilient bleiben, während wir darauf warten, dass RPKI flächendeckend eingesetzt wird?

Wenn Sie heute Cloudflare DNS im Free-, Pro-, Business- oder Enterprise-Tarif verwenden, erhält Ihre Domain zwei Nameserver der Struktur <name>.ns.cloudflare.com, wobei <name> ein zufälliger Vorname ist.

Wie wir bereits gelernt haben, müssen die Nameserver einer Domain verfügbar sein, damit diese verfügbar ist. Aus diesem Grund löst jeder dieser Nameserver zu 3 anycast IPv4- und 3 anycast IPv6-Adressen auf.

$ dig isbgpsafeyet.com ns +short
tom.ns.cloudflare.com.
kami.ns.cloudflare.com.

Das wichtigste Detail ist, dass jede der 3 IPv4- und 3 IPv6-Adressen aus einem anderen /8 IPv4- (/45 für IPv6) Block stammt. Damit Ihre Nameserver über IPv4 nicht mehr erreichbar sind, müsste das Routenleck also genau die entsprechenden Subnetze in allen drei /8-IPv4-Blöcken betreffen. Ein solches Ereignis ist zwar theoretisch möglich, aber in der Praxis praktisch unmöglich.

$ dig tom.ns.cloudflare.com a +short
173.245.59.147
108.162.193.147
172.64.33.147

$ dig tom.ns.cloudflare.com aaaa +short
2606:4700:58::adf5:3b93
2803:f800:50::6ca2:c193
2a06:98c1:50::ac40:2193

Kunden, die Foundation DNS nutzen, erhalten einen neuen Satz von erweiterten Nameservern, die auf foundationdns.com und foundationdns.net gehostet werden. Diese Nameserver werden noch stabiler sein als die Standard-Nameserver von Cloudflare. Wir werden zu Beginn des nächsten Jahres weitere Einzelheiten darüber bekannt geben, wie wir dies erreichen wollen, also bleiben Sie auf dem Laufenden. Alle externen Cloudflare-Domains (z. B. cloudflare.com) wird im neuen Jahr zu diesen Nameservern wechseln.

Wir freuen uns, Ihnen mitteilen zu können, dass wir zwei sehr gefragte Funktionen einführen werden:

• Unterstützung für ausgehende Zonentransfers für Sekundäres DNS

• Logpush für autoritative und sekundäre DNS-Anfragen

Beide werden als Teil von Foundation DNS und für Unternehmenskunden ohne zusätzliche Kosten verfügbar sein. Schauen wir uns jede dieser Optionen näher an und sehen wir, wie sie unser DNS-Angebot noch besser machen.

Was ist Secondary DNS, und warum ist es wichtig? Viele große Unternehmen müssen aus Gründen der Redundanz mehr als einen DNS-Anbieter nutzen, falls ein Anbieter nicht mehr verfügbar ist. Sie können dies erreichen, indem sie die DNS-Einträge ihrer Domain auf zwei unabhängigen Plattformen hinzufügen und die Zonendateien manuell synchron halten – dies wird als „multi-primäres“ Setup bezeichnet. Beim Secondary DNS gibt es zwei Mechanismen, wie dies mit einer „primär-sekundären“ Einrichtung automatisiert werden kann:

• DNS NOTIFY: Der primäre Nameserver benachrichtigt den sekundären über jede Änderung in der Zone. Sobald das sekundäre System das NOTIFY erhält, sendet es eine Zonentransferanfrage an das primäre System, um sich mit diesem zu synchronisieren.

• SOA-Abfrage: Hier fragt der sekundäre Nameserver regelmäßig den SOA-Eintrag der Zone ab und prüft, ob die Seriennummer, die im SOA-Eintrag zu finden ist, mit der neuesten Seriennummer übereinstimmt, die der sekundäre Nameserver in seinem SOA-Eintrag der Zone gespeichert hat. Wenn eine neue Version der Zone verfügbar ist, sendet sie eine Anfrage zur Übertragung der Zone an die primäre Stelle, um diese Änderungen zu erhalten.

Alex Fattouche hat einen sehr aufschlussreichen Blog-Beitrag darüber geschrieben, wie Sekundäres DNS im Hintergrund funktioniert, wenn Sie mehr darüber erfahren möchten. Eine andere Variante der primär-sekundären Einrichtung besteht darin, den primären Server zu verstecken, was als „verborgenes primäres“ bezeichnet wird. Der Unterschied dieser Einrichtung besteht darin, dass nur die sekundären Nameserver maßgebend sind, d. h. beim Domain-Registrar konfiguriert werden. Das folgende Diagramm veranschaulicht die verschiedenen Konfigurationen.

Seit 2018 unterstützen wir Primär-Sekundär-Setups, bei denen Cloudflare die Rolle des sekundären Nameservers übernimmt. Aus unserer Sicht bedeutet dies, dass wir eingehende Zonentransfers von den primären Nameservern akzeptieren.

Ab heute unterstützen wir nun auch ausgehende Zonentransfers, d.h. wir übernehmen die Rolle des primären Nameservers mit einem oder mehreren externen sekundären Nameservern, die Zonentransfers von Cloudflare erhalten. Genau wie bei den eingehenden Transfers unterstützen wir

• Zonentransfers über AXFR und IXFR

• automatische Benachrichtigungen über DNS NOTIFY zur Auslösung von Zonentransfers bei jeder Änderung

• signierte Übertragungen mit TSIG, um sicherzustellen, dass Zonendateien während der Übertragung authentifiziert werden

Wir bei Cloudflare lieben Protokolle. Im dritten Quartal 2021 verarbeiteten wir im Durchschnitt 28 Millionen HTTP-Anfragen pro Sekunde und 13,6 Millionen DNS-Anfragen pro Sekunde und blockierten täglich 76 Milliarden Bedrohungen. All diese Ereignisse werden für einen begrenzten Zeitraum als Logs gespeichert, um unseren Nutzern im Dashboard nahezu Echtzeit-Analysen zu bieten. Für Kunden, die diese Logs dauerhaft speichern wollen - oder müssen - haben wir 2019 Logpush entwickelt. Logpush ermöglicht es Ihnen, Protokolle nahezu in Echtzeit an einen unserer Analysepartner Microsoft Azure Sentinel, Splunk, Datadog und Sumo Logic oder an ein beliebiges Cloud-Zielspeicherort mit R2-kompatibler API zu streamen.

Heute fügen wir einen weiteren Datensatz für Logpush hinzu: DNS-Logs. Um Logpush zu konfigurieren und DNS-Logs für Ihre Domain zu streamen, gehen Sie einfach zum Cloudflare-Dashboard, erstellen Sie einen neuen Logpush-Job, wählen Sie DNS-Logs und konfigurieren Sie die Log-Felder, an denen Sie interessiert sind:

In unserer Dokumentation für Entwickler finden Sie detaillierte Anweisungen, wie Sie dies über die API tun können, und eine ausführliche Beschreibung der neuen DNS-Protokollfelder.

Bei der Betrachtung des gesamten DNS innerhalb Ihrer Infrastruktur ist es wichtig zu prüfen, wie der Traffic durch Ihre Systeme fließt und wie sich dieser Traffic verhält. Letztendlich ist nur eine bestimmte Menge an Verarbeitungsleistung, Speicher, Serverkapazität und allgemeinen Rechenressourcen verfügbar. Eines der besten und wichtigsten Werkzeuge, die uns zur Verfügung stehen, ist Load Balancing und Health Monitoring!

Cloudflare bietet seit 2016 eine Load-Balancing-Lösung, die Kunden dabei unterstützt, ihre vorhandenen Ressourcen auf skalierbare und intelligente Weise zu nutzen. Aber unser Load Balancer war auf A-, AAAA- und CNAME-Einträge beschränkt. Dies deckte zwar viele der wichtigsten Anwendungsfälle ab, die von Kunden benötigt werden, aber nicht alle. Viele Kunden haben weitere Anforderungen, wie z. B. den Lastausgleich von MX- oder E-Mail-Server-Traffic, SRV-Einträge, um anzugeben, über welche Ports und welche Gewichtung der jeweilige Traffic für einen bestimmten Dienst laufen soll, HTTPS-Einträge, um sicherzustellen, dass der jeweilige Traffic unabhängig vom Port das sichere Protokoll verwendet, und vieles mehr. Wir möchten sicherstellen, dass die Bedürfnisse unserer Kunden abgedeckt werden und unterstützen sie dabei, ihre Geschäftsziele mit der technischen Umsetzung in Einklang zu bringen.

Wir freuen uns, Ihnen mitteilen zu können, dass wir zusätzliche Health Monitoring-Methoden zur Unterstützung von Load Balancing MX-, SRV-, HTTPS- und TXT-Record-Traffic hinzugefügt haben, ohne dass eine zusätzliche Konfiguration erforderlich ist. Erstellen Sie Ihre entsprechenden DNS-Einträge in Cloudflare und legen Sie Ihren Load Balancer als Ziel fest...so einfach ist das! Durch den Einsatz von ICMP-Ping-, SMTP- und UDP-ICMP-Methoden haben die Kunden stets einen Überblick über den Zustand ihrer Server und können auf der Grundlage der jeweiligen Zustandsinformationen intelligente Steuerungsentscheidungen treffen.

Wenn es um intelligente Lenkung geht, gibt es keine pauschale Antwort. Unterschiedliche Unternehmen haben unterschiedliche Bedürfnisse, insbesondere wenn man bedenkt, wo sich Ihre Server weltweit befinden und wo Ihre Kunden ansässig sind. Eine gängige Faustregel lautet: Stellen Sie Ihre Server dort auf, wo Ihre Kunden sind. Dadurch wird sichergestellt, dass sie die bestmögliche Performance und Lokalisierung erhalten. Ein gängiges Szenario besteht darin, den Datenverkehr danach zu lenken, woher die Anfrage des Endbenutzers kommt, und eine Zuordnung zu dem Server zu erstellen, der diesem Gebiet am nächsten liegt. Die globale Lenkungsfähigkeit von Cloudflare (Geo-Steering) erlaubt unseren Kunden genau das zu tun – einfach ein Mapping von Regionen zu Pools zu erstellen, um sicherzustellen, dass wenn wir sehen, dass eine Anfrage aus Osteuropa kommt, diese Anfrage an den richtigen Server geschickt wird, um dieser Anfrage gerecht zu werden. Aber manchmal können Regionen recht groß sein und dazu führen, dass man die Zuordnung nicht so eng koppeln kann, wie man es gerne hätte.

Wir freuen uns sehr, heute die Länderunterstützung in unserer Geo Steering-Funktionalität ankündigen zu können. Jetzt können die Kunden entweder eine unserer dreizehn Regionen oder ein bestimmtes Land auswählen, das sie ihren Pools zuordnen möchten, um noch mehr Präzision darin und Kontrolle darüber zu erhalten, wie sich der Kunden-Traffic auf seinem Weg durch ihr System verhalten soll. Sowohl die Lenkung auf Länderebene als auch unsere neuen Methoden zur Überwachung des Zustands der DNS-Einträge zur Unterstützung der Lastverteilung werden im Januar 2022 verfügbar sein!

Darüber hinaus haben wir weitere spannende Neuigkeiten zu verkünden: Wir schließen die Arbeit an Multi-Signer DNSSEC (RFC8901) ab und planen, dies im ersten Quartal 2022 einzuführen. Warum ist das wichtig? Zwei häufige Anforderungen von Großunternehmen sind:

• Redundanz: Mehrere DNS-Anbieter, die für ihre Domains autoritativ antworten

• Authentizität: Einsatz von DNSSEC, um sicherzustellen, dass DNS-Antworten ordnungsgemäß authentifiziert werden können

Beides kann erreicht werden, indem der primäre Nameserver die Domain signiert und seine DNS-Datensätze sowie die Datensatzsignaturen an den sekundären Nameserver überträgt, der beide unverändert weiterführt. Dieses Setup wird heute von Cloudflare Secondary DNS unterstützt. Was bei der Übertragung von vor-signierten Zonen nicht unterstützt werden kann, sind nicht-standardisierte DNS-Features wie Country-Level Steering (länderbasierte Steuerung). Hier kommt Multi-Signer DNSSEC ins Spiel. Beide DNS-Anbieter müssen die Signierschlüssel des anderen Anbieters kennen und ihre eigene Online-Signierung (oder On-the-Fly-Signierung) durchführen. Wenn Sie mehr über die Funktionsweise von Multi-Signer DNSSEC erfahren möchten, lesen Sie diesen exzellenten Blog-Beitrag, der von APNIC veröffentlicht wurde.

Last but not least tritt Cloudflare dem DNS Operations, Analysis, and Research Center (DNS-OARC) als Gold-Member bei. Gemeinsam mit anderen Forschern und Betreibern von DNS-Infrastrukturen wollen wir die anspruchsvollsten Probleme angehen und kontinuierlich an der Implementierung neuer Standards und Funktionen arbeiten.

„Das DNS ist ein entscheidendes Instrument für die Verwaltung und Bereitstellung von Inhalten am Netzwerkrand, wo die Konsumenten Performance und Zuverlässigkeit erwarten. „Cloudflare ist ein wichtiges Mitglied der DNS-Community und nimmt seit vielen Jahren regelmäßig an den OARC-Workshops teil, bei denen sie ihre Innovationen und betrieblichen Ergebnisse unserem DNS-affinen Publikum vorstellen. Wir freuen uns, sie nun als vollwertige Mitglieder in unserer Community begrüßen zu dürfen, und wir freuen uns darauf, auf ihren einzigartigen Beiträgen als Gold-OARC-Mitglieder aufzubauen.“- Keith Mitchell, OARC-Präsident

Wir sind zwar seit dem ersten Tag von Cloudflare im DNS-Bereich tätig, aber wir stehen noch ganz am Anfang. Wir wissen, dass es noch präzisere und spezifischere Funktionen gibt, die unsere zukünftigen Kunden von uns verlangen werden, und das Lancieren von Foundation DNS ist uns ein erster Schritt; wir werden weiterhin in alle Ebenen von DNS investieren, während wir die funktionsreichste DNS-Plattform für Unternehmen auf dem Planeten entwickeln. Wenn Sie Ideen haben, lassen Sie uns wissen, was Sie sich von Ihrem DNS-Anbieter schon immer gewünscht haben. Wenn Sie bei der Entwicklung dieser Funktionen helfen wollen: Wir stellen neue Mitarbeiter ein.