Offizielle Einführung von Foundation DNS: Verbesserung des autoritativen DNS-Diensts

Wir freuen uns sehr, die offizielle Einführung von Foundation DNS bekannt geben zu können. Das Produkt bietet neue, fortschrittliche Nameserver, eine höhere Ausfallsicherheit und erweiterte Analysen zur Erfüllung der in puncto Komplexität hohen Anforderungen unserer Firmenkunden. Foundation DNS stellt eine der größten Verbesserungen des autoritativen DNS-Diensts von Cloudflare seit dessen Einführung im Jahr 2010 dar. Wir wissen, dass sich unsere Kunden einen autoritativen DNS-Service für Unternehmen mit einem Höchstmaß an Performance, Zuverlässigkeit, Sicherheit, Flexibilität und vertieften Analysen wünschen.

Ab heute können bei jedem neu abgeschlossenen Enterprise-Vertrag, der einen autoritativen DNS-Dienst beinhaltet, die Funktionen von Foundation DNS genutzt werden. Enterprise-Bestandskunden erhalten im weiteren Jahresverlauf Zugang zu diesen Features. Wenn Sie schon Enterprise-Kunde sind, unsere autoritativen DNS-Dienste bereits nutzen und Foundation DNS schon jetzt in Anspruch nehmen möchten, wenden Sie sich einfach an Ihre Ansprechpartner bei Cloudflare, um die Lösung aktivieren zu lassen. Legen wir los …

Warum ist DNS so wichtig?

DNS macht das Web für Endanwender überhaupt erst nutzbar. Es fungiert als Telefonbuch des Internet, das Hostnamen wie www.cloudflare.com in IP-Adressen übersetzt, über die sich Browser, Anwendungen und Geräten mit Diensten verbinden. Ohne DNS müssten sich Nutzer, die eine Website auf ihrem Mobilgerät oder Desktop aufrufen wollen, anstelle von Adressen wie www.cloudflare.com jedes Mal IP-Adressen wie 108.162.193.147 oder 2606:4700:58::adf5:3b93 merken. DNS wird bei jeder Endnutzer-Anwendung im Internet verwendet – von sozialen Netzwerken über Online-Banking bis hin zu Gesundheitsportalen. Ohne DNS könnte der Mensch das Internet nicht nutzen.

Aus geschäftlicher Sicht ist das DNS der allererste Schritt, um Websites aufzurufen und sich mit Anwendungen zu verbinden. Geräte müssen wissen, wo sie sich verbinden müssen, um Dienste zu erreichen, Nutzer zu authentifizieren und die angeforderten Informationen bereitzustellen. Eine rasche Auflösung von DNS-Abfragen kann darüber entscheiden, ob eine Website oder Anwendung als reaktionsschnell wahrgenommen wird oder nicht. Dies kann großen Einfluss auf die Nutzererfahrung haben.

Die Auswirkungen von DNS-Ausfällen sind nicht zu übersehen – zum Beispiel, wenn eine E-Commerce-Website nicht lädt. So war es etwa bei dem Ausfall bei Dyn im Jahr 2016, durch den unter anderem die Webauftritte mehrerer beliebter Online-Händler lahmgelegt wurden. Wenn Kunden wegen eines DNS-Ausfalls auf die Website eines Unternehmens nicht zugreifen und somit die von diesem vertriebenen Waren oder Dienstleistungen nicht kaufen können, sorgt das für Umsatzverluste. DNS wird oft als selbstverständlich angesehen, doch wenn es nicht richtig funktioniert, ist das unübersehbar. Wenn Sie den autoritativen DNS-Dienst von Cloudflare verwenden, müssen Sie sich aber glücklicherweise in dieser Hinsicht keine großen Gedanken machen.

Es gibt immer Luft nach oben

Cloudflare bietet seit über einem Jahrzehnt autoritative DNS-Dienste an. Unser autoritativer DNS-Service hostet Millionen von Domains mit vielen verschiedenen Top-Level-Domains (TLD). Wir haben Kunden jeder Größe, von einzelnen Domains mit nur wenigen Einträgen bis hin zu Kunden mit Dutzenden Millionen Datensätzen, die auf mehrere Domains verteilt sind. Enterprise-Kunden erwarten von unserem DNS-Service zu Recht ein Höchstmaß an Performance, Zuverlässigkeit, Sicherheit und Flexibilität sowie detaillierte Analysen. Unsere Kunden sind zwar von unserem autoritativen DNS-Dienst durchaus angetan, aber uns ist bewusst, dass es in einigen Bereichen durchaus noch Luft nach oben gibt. Deshalb haben wir nun einige wichtige Verbesserungen an unserer DNS-Architektur vorgenommen. Dies umfasst sowohl neue Funktionen als auch strukturelle Veränderungen. Wir haben diesem optimierten Angebot den Namen Foundation DNS gegeben.

Dürfen wir vorstellen: Foundation DNS

Foundation DNS ist unser neues autoritatives DNS-Angebot für Unternehmen. Es wurde entwickelt, um die Zuverlässigkeit, Sicherheit, Flexibilität und Analysemöglichkeiten unseres bestehenden autoritativen DNS-Diensts zu verbessern. Bevor wir näher auf die Merkmale von Foundation DNS eingehen, folgt ein kurzer Überblick darüber, wie Foundation DNS unser bisheriges autoritatives DNS-Angebot ergänzt:

• Fortschrittliche Nameserver sorgen für noch größere DNS-Zuverlässigkeit.
• Neue DNS-Einstellungen auf Zonenebene ermöglichen eine flexiblere Konfiguration von DNS-spezifischen Einstellungen.
• Eindeutige DNSSEC-Schlüssel für jedes Konto und jede Zone bieten zusätzliche Sicherheit und Flexibilität für DNSSEC.
• GraphQL-basierte DNS-Analysen liefern noch aufschlussreichere Erkenntnisse zu DNS-Abfragen.
• Ein neues Release-Verfahren gewährleistet größtmögliche Stabilität und Zuverlässigkeit für Enterprise-Kunden.
• Übersichtlichere DNS-Preisgestaltung mit großzügigeren Kontingenten für reine DNS-Zonen und DNS-Einträge.

Nun schauen wir uns die neuen Features von Foundation DNS genauer an:

Fortschrittliche Nameserver

Mit Foundation DNS führen wir fortschrittliche Nameserver ein, die speziell auf eine Erhöhung der Zuverlässigkeit ausgerichtet sind. Vielleicht sind Sie mit der Standardversion unserer autoritativen Nameserver vertraut, die pro Zone paarweise eingesetzt werden und Namen innerhalb der Domain cloudflare.com verwenden. Hier ein Beispiel:

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	kelly.ns.cloudflare.com.
mycoolwebpage.xyz.	86400	IN	NS	christian.ns.cloudflare.com.

Werfen wir jetzt einen Blick auf dieselbe Zone mit den fortschrittlichen Nameservern von Foundation DNS:

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.com.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.net.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.org.

Fortschrittliche Nameserver erhöhen die Zuverlässigkeit auf verschiedene Weise. Die erste Verbesserung ergibt sich daraus, dass die autoritativen Server von Foundation DNS über mehrere Top Level Domains (TLD) verteilt sind. Dies bietet Schutz vor größeren DNS-Ausfällen und DDoS-Angriffen, die möglicherweise die DNS-Infrastruktur auf höherer Ebene – etwa bei den TLD-Nameservern – beeinträchtigen könnten. Die autoritativen Nameserver von Foundation DNS sind jetzt in mehreren Zweigen der globalen DNS-Baumstruktur angesiedelt. Dadurch sind unsere Kunden noch besser vor entsprechenden Ausfällen und Angriffen geschützt.

Vielleicht haben Sie auch bemerkt, dass bei Foundation DNS ein zusätzlicher Nameserver aufgelistet ist. Das stellt zwar eine Verbesserung dar, aber nicht aus dem Grund, den Sie vielleicht vermuten. Wenn wir jeden dieser Nameserver nach seinen jeweiligen IP-Adressen auflösen, können wir dies etwas verständlicher machen. Beginnen wir zunächst mit unseren Standard-Nameservern:

$ dig kelly.ns.cloudflare.com. +noall +answer
kelly.ns.cloudflare.com. 86353  IN      A       108.162.194.91
kelly.ns.cloudflare.com. 86353  IN      A       162.159.38.91
kelly.ns.cloudflare.com. 86353  IN      A       172.64.34.91

$ dig christian.ns.cloudflare.com. +noall +answer
christian.ns.cloudflare.com. 86353 IN   A       108.162.195.247
christian.ns.cloudflare.com. 86353 IN   A       162.159.44.247
christian.ns.cloudflare.com. 86353 IN   A       172.64.35.247

Für die beiden Nameserver gibt es insgesamt sechs IP-Adressen. Wie sich herausgestellt hat, ist das alles, was für die DNS-Auflösung bei Abfragen, die an autoritative Nameserver gerichtet sind, wirklich wichtig ist. Bei der DNS-Auflösung werden in der Regel nicht die tatsächlichen Domainnamen autoritativer Server nachverfolgt, sondern es wird einfach eine unsortierte Liste von IP-Adressen geführt, anhand derer Abfragen für eine bestimmte Domain aufgelöst werden können. Mit unseren autoritativen Standard-Nameservern nennen wir den Resolvern also sechs IP-Adressen, die sie zur Auflösung von DNS-Abfragen verwenden können. Schauen wir uns nun die IP-Adressen der fortschrittlichen Nameserver von Foundation DNS an:

$ dig blue.foundationdns.com. +noall +answer
blue.foundationdns.com. 300     IN      A       108.162.198.1
blue.foundationdns.com. 300     IN      A       162.159.60.1
blue.foundationdns.com. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.net. +noall +answer
blue.foundationdns.net. 300     IN      A       108.162.198.1
blue.foundationdns.net. 300     IN      A       162.159.60.1
blue.foundationdns.net. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.org. +noall +answer
blue.foundationdns.org. 300     IN      A       108.162.198.1
blue.foundationdns.org. 300     IN      A       162.159.60.1
blue.foundationdns.org. 300     IN      A       172.64.40.1

Wie Sie sehen, stellt Foundation DNS für jeden autoritativen Nameserver dieselben IP-Adressen bereit, die wir auch für eine Zone anbieten. In diesem Fall haben wir daher den Resolvern für die Auflösung von DNS-Abfragen nur drei IP-Adressen genannt. Sie fragen sich vielleicht: „Sind sechs nicht besser als drei? Stellt das nicht eine Verschlechterung dar?“ Tatsächlich bedeutet Masse nicht immer Klasse. Warum das so ist, schauen wir uns jetzt genauer an.

Sie wissen wahrscheinlich, dass Cloudflare Anycast verwendet. Wie Sie vielleicht schon vermutet haben, nutzen auch unsere DNS-Services Anycast, damit unsere autoritativen DNS-Server weltweit verfügbar und in größtmöglicher Nähe zu unseren Nutzern und Resolvern im Internet angesiedelt sind. Unsere Standard-Nameserver werden alle von jedem Cloudflare-Rechenzentrum aus durch eine einzige Anycast-Gruppe angekündigt. Ein genauerer Blick auf Europa zeigt, dass bei einer Standard-Nameserver-Bereitstellung beide Nameserver von jedem Rechenzentrum aus angekündigt werden.

Wir können eine Suche nach dem TXT-Eintrag „hostname.bind“ dieser sechs IP-Adressen von unseren oben genannten Standard-Nameservern durchführen. Dies verrät uns den Flughafencode oder den physischen Standort des nächstgelegenen Rechenzentrums, von dem aus unsere DNS-Abfragen aufgelöst werden. Diese Ergebnisse verdeutlichen, warum Masse nicht immer Klasse bedeutet.

$ dig @108.162.194.91 ch txt hostname.bind +short
"LHR"

$ dig @162.159.38.91 ch txt hostname.bind +short
"LHR"

$ dig @172.64.34.91 ch txt hostname.bind +short
"LHR"

$ dig @108.162.195.247 ch txt hostname.bind +short
"LHR"

$ dig @162.159.44.247 ch txt hostname.bind +short
"LHR"

$ dig @172.64.35.247 ch txt hostname.bind +short
"LHR"

Wie Sie sehen können, leiten alle sechs IP-Adressen eine Abfrage aus der Nähe von London an dasselbe Londoner Rechenzentrum (LHR) weiter. Wenn ein Resolver also in London DNS-Abfragen für eine Domain mit dem autoritativen Standard-DNS von Cloudflare auflöst, stellt er immer eine Verbindung mit demselben physischen Standort her – unabhängig davon, welche Nameserver-IP-Adresse abgefragt wird.

Sie fragen sich vielleicht: „Na und? Was heißt das für mich?“ Schauen wir uns zur Verdeutlichung ein Beispiel an. Nehmen wir an, Sie wollen eine Domain mit Cloudflare-Standard-Nameservern von London aus auflösen und ich verwende einen sich ebenfalls in London befindlichen öffentlichen Resolver. Dann wird der Resolver immer eine Verbindung zu dem LHR-Rechenzentrum von Cloudflare herstellen, unabhängig davon, welchen Nameserver er erreichen möchte. Aufgrund der Verwendung von Anycast besteht in diesem Fall gar keine andere Möglichkeit.

Sollte das LHR-Rechenzentrum vollständig offline gehen, wird dank Anycast der gesamte für LHR bestimmte Traffic an andere nahe gelegene Rechenzentren weitergeleitet. Die Resolver würden weiterhin ordnungsgemäß funktionieren. In dem unwahrscheinlichen Fall, dass das LHR-Rechenzentrum online ist, unsere DNS-Dienste aber nicht auf DNS-Abfragen antworten können, hätte der Resolver diese DNS-Abfragen nicht auflösen können, da er kein anderes Rechenzentrum kontaktieren kann. Selbst das Vorhandensein von 100 IP-Adressen würde bei dieser Konstellation keinen Unterschied machen. Früher oder später verfallen Cache-Antworten und der Domainname wird irgendwann nicht mehr aufgelöst.

Die fortschrittlichen Nameserver von Foundation DNS verändern die Art und Weise, in der wir Anycast verwenden. Da sie zwei Anycast-Gruppen nutzen, unterlaufen sie das bisher angewandte Prinzip, jede IP-Adresse eines autoritativen Nameservers von jedem Rechenzentrum aus anzukündigen. Weil zwei Anycast-Gruppen verwendet werden, sind die autoritativen Nameserver von Foundation DNS tatsächlich an unterschiedlichen physischen Standorte angesiedelt. Somit werden sie nicht alle von jedem Rechenzentrum aus angekündigt. Mit zwei Anycast-Gruppen würde dieselbe Region folgendermaßen aussehen:

Da wir nun klargestellt haben, dass Foundation DNS zwei Anycast-Gruppen für Ankündigungs-Nameserver verwendet, kommen wir jetzt noch einmal auf den Vergleich zwischen sechs autoritativen IP-Adressen für das autoritative Standard-DNS und drei IP-Adressen für Foundation DNS zurück. Bezogen auf unser Beispiel schauen wir uns an, wo die Server von Foundation DNS angekündigt werden:

$ dig @108.162.198.1 ch txt hostname.bind +short
"LHR"

$ dig @162.159.60.1 ch txt hostname.bind +short
"LHR"

$ dig @172.64.40.1 ch txt hostname.bind +short
"MAN"

Wer hätte das gedacht! Eine unserer drei Nameserver-IP-Adressen wird von einem anderen Rechenzentrum, Manchester (MAN), angekündigt. Das sorgt dafür, dass Foundation DNS im Fall des zuvor besprochenen Ausfallszenarios zuverlässiger und robuster ist. Erwähnenswert ist, dass Cloudflare in einigen Städten mehrere Rechenzentren nutzt, sodass alle drei Abfragen mit demselben Flughafencode beantwortet werden. Wir garantieren zwar, dass mindestens eine dieser IP-Adressen von einem anderen Rechenzentrum aus angekündigt wird, aber wir verstehen, dass einige Kunden dies selbst testen möchten. In diesen Fällen kann eine zusätzliche Abfrage zeigen, dass die IP-Adressen von verschiedenen Rechenzentren aus angekündigt werden.

$ dig @108.162.198.1 +nsid | grep NSID:
; NSID: 39 34 6d 33 39 ("94m39")

In dem fettgedruckten Text steht die Zahl vor dem „m“ für das Rechenzentrum, das die Abfrage beantwortet hat. Solange sich diese Nummer in einer der drei Antworten von den anderen unterscheidet, wissen Sie, dass die Ankündigung von einem Ihrer autoritativen Foundation DNS-Nameserver an einem anderen physischen Standort erfolgt.

Da Foundation DNS zwei Anycast-Gruppen nutzt, lässt sich der im bisherigen Szenario angenommene Ausfall mühelos meistern. DNS-Resolver überwachen die Anfragen an alle autoritativen Nameserver für eine bestimmte Domain, verwenden aber in erster Linie den Nameserver, der die schnellsten Antworten liefert.

Bei dieser Konfiguration können DNS-Resolver Anfragen an zwei verschiedene Cloudflare-Rechenzentren senden, sodass bei einem Ausfall an einem physischen Standort die Anfragen automatisch an das zweite Rechenzentrum geschickt werden, wo sie ordnungsgemäß aufgelöst werden können.

Die fortschrittlichen Nameserver von Foundation DNS stellen im Hinblick auf die Zuverlässigkeit für unsere Firmenkunden einen großen Fortschritt dar. Deshalb würden wir uns freuen, wenn diese noch heute fortschrittliche Nameserver für bestehende Zonen aktivieren. Die Migration zu Foundation DNS ist nicht mit Ausfällen verbunden, denn die vorherigen autoritativen DNS-Nameserver funktionieren auch nach der Aktivierung der fortschrittlichen Foundation DNS-Nameserver für eine Zone weiter und beantworten Abfragen für die Zone. Kunden müssen sich nicht auf einen Wechsel oder andere den Dienst beeinträchtigende Maßnahmen vorbereiten, um zu den fortschrittlichen Nameservern von Foundation DNS zu migrieren.

Neue DNS-Einstellungen auf Zonenebene

Unsere Firmenkunden haben uns bisher regelmäßig gebeten, bestimmte DNS-Einstellungen anzupassen, die nicht über unsere API oder unser Dashboard offengelegt wurden – verlangt wurde etwa die Aktivierung einer sekundären DNS-Überbrückung. Wenn Kunden diese Einstellungen anpassen wollten, mussten sie sich bislang für die Änderung von Konfigurationen an ihre Account-Teams wenden. Mit Foundation DNS legen wir die am häufigsten angeforderten Einstellungen über die API und das Dashboard offen, um unseren Kunden bezüglich ihrer autoritativen DNS-Lösung von Cloudflare mehr Flexibilität zu ermöglichen.

Ab sofort können Enterprise-Kunden die folgenden DNS-Einstellungen in ihren Zonen konfigurieren:

Eindeutige DNSSEC-Schlüssel für jedes Konto und jede Zone

Mit DNSSEC (Domain Name System Security Extensions) kann überprüft werden, ob die auf eine DNS-Abfrage zurückgegebene Antwort authentisch ist und nicht verändert wurde. Dadurch wird höhere Sicherheit für eine Domain oder Zone gewährleistet. DNSSEC verhindert DNS-Cacheangriffe (DNS -Spoofing). So wird sichergestellt, dass DNS-Abfragen von den DNS-Resolvern mit den richtigen IP-Adressen beantwortet werden.

Seit der Einführung von Universal DNSSEC im Jahr 2015 haben wir eine Reihe von Verbesserungen vorgenommen. Unter anderem werden nun vorsignierte DNSSEC für sekundäre Zonen und DNSSEC mit mehreren Unterzeichnern unterstützt. Standardmäßig signiert Cloudflare den DNS-Eintrag sofort (Live-Signing), wenn wir auf DNS-Abfragen antworten. Dadurch kann Cloudflare eine durch DNSSEC abgesicherte Domain hosten und gleichzeitig IP-Adressen für die hinter dem Proxy befindlichen Ursprungsserver dynamisch zuweisen. Es werden auch bestimmte Anwendungsfälle im Bereich Lastverteilung abgedeckt, da sich die in diesen Fällen in der DNS-Antwort verwendeten IP-Adressen je nach Steuerung ändern.

Cloudflare verwendet den Elliptic Curve-Algorithmus ECDSA P-256, der stärker ist als die meisten heute verwendeten RSA-Schlüssel. Dieser beansprucht weniger Rechenleistung zur Generierung von Signaturen, sodass sich diese im laufenden Betrieb effizienter generieren lassen. Normalerweise werden bei DNSSEC zwei Schlüssel verwendet, der Zone Signing Key (ZSK) und der Key Signing Key (KSK). Auf der einfachsten Ebene wird der ZSK zum Signieren der DNS-Einträge benutzt, mit denen Abfragen beantwortet werden. Mit dem KSK werden die DNSKEY signiert, einschließlich des ZSK zur Gewährleistung von dessen Authentizität.

Aktuell verwendet Cloudflare weltweit einen gemeinsamen ZSK und KSK für alle DNSSEC-Signaturen. Weil wir einen so starken kryptografischen Algorithmus einsetzen, wissen wir, wie sicher dieser Schlüsselsatz ist. Wir halten es deshalb nicht für nötig, den ZSK oder den KSK regelmäßig zu ändern – zumindest nicht aus Sicherheitserwägungen. Allerdings ist bei manchen Kunden die Änderung dieser Schlüssel in bestimmten zeitlichen Abständen vorgeschrieben. Deshalb können nun bei unseren neuen fortschrittlichen Nameservern von Foundation DNS sowohl der ZSK als auch der KSK nach Bedarf für jedes Konto oder jede Zone regelmäßig geändert werden. Dies wird zunächst über die API und später über das Cloudflare-Dashboard möglich sein. Das erlaubt es Kunden, deren Richtlinien eine regelmäßige Änderung der DNSSEC-Schlüssel vorgeben, diese Anforderungen mit Foundation DNS von Cloudflare zu erfüllen.

GraphQL-basierte DNS-Analysen

Für diejenigen, die damit nicht vertraut sind: GraphQL ist eine Abfragesprache für API und eine Laufzeitumgebung für die Ausführung dieser Abfragen. So kann der Kunde immer genau das anfordern, was er benötigt (nicht mehr und nicht weniger). Er hat außerdem damit die Möglichkeit, Daten aus verschiedenen Quellen über einen einzigen API-Aufruf zu aggregieren und Echtzeit-Updates über Abonnements zu unterstützen.

Wie Sie vielleicht wissen, verfügt Cloudflare schon seit einiger Zeit über eine GraphQL-API. Doch im Rahmen von Foundation DNS fügen wir dieser API einen neuen DNS-Datensatz hinzu, der nur mit den neuen fortschrittlichen Nameservern von Foundation DNS verfügbar ist.

Mit dem neuen DNS-Datensatz in unserer GraphQL-API können Informationen über die von einer Zone erhaltenen DNS-Abfragen abgerufen werden. Diese schnellere und leistungsfähigere Alternative zu unserer aktuellen DNS-Analyse-API ermöglicht Ihnen eine zügige und effiziente Abfrage von Daten für große Zeiträume ohne Einschränkungen oder Timeouts. Die GraphQL-API ist flexibler im Hinblick darauf, welche Abfragen sie akzeptiert, und legt mehr Informationen offen als die DNS-Analyse-API.

Sie können diese Abfrage beispielsweise ausführen, um die durchschnittliche Verarbeitungszeit für Ihre Abfragen und deren Verarbeitungszeit im 90. Perzentil gruppiert nach Quell-IP-Adresse in Intervallen von 15 Minuten abzurufen. Das wäre hilfreich, um in Erfahrung zu bringen, von welchen IP-Adressen Ihre Einträge während eines bestimmten Zeitraums am häufigsten abgefragt werden:

{
  "query": "{
    viewer {
      zones(filter: { zoneTag: $zoneTag }) {
        dnsAnalyticsAdaptiveGroups(
          filter: $filter
          limit: 10
          orderBy: [datetime_ASC]
        ) {
          avg {
            processingTimeUs
          }
          quantiles {
            processingTimeUsP90
          }
          dimensions {
            datetimeFifteenMinutes
            sourceIP
          }
        }
      }
    }
  }",
  "variables": {
    "zoneTag": "<zone-tag>",
    "filter": {
      "datetime_geq": "2024-05-01T00:00:00Z",
      "datetime_leq": "2024-06-01T00:00:00Z"
    }
  }
}

Bisher wäre eine solche Abfrage aus mehreren Gründen nicht möglich gewesen. Erstens haben wir neue Felder wie sourceIP hinzugefügt. Damit können wir Daten danach filtern, welche Client-IP-Adressen DNS-Abfragen stellen (in der Regel handelt sich um Resolver). Zweitens kann die GraphQL-API-Abfrage Daten für viel größere Zeitspannen verarbeiten und liefern. Eine DNS-Zone mit ausreichend vielen Abfragen konnte bisher nur den Traffic weniger Tage abfragen, während die neue GraphQL-API Daten für einen Zeitraum von bis zu 31 Tagen bereitstellen kann. Wir wollen diese Zeitspanne noch weiter erhöhen und auch den rückwirkenden Zeitraum verlängern, für den Altdaten gespeichert und abgefragt werden können.

Dank der GraphQL-API können wir außerdem das Cloudflare-Dashboard um einen neuen Bereich für DNS-Analysen erweitern. Damit werden sich die am häufigsten abgefragten Datensätze ermitteln lassen. Außerdem ist dort unter anderem einsehbar, welche Rechenzentren diese Abfragen beantworten und wie viele Abfragen gestellt werden.

Der neue DNS-Datensatz bei unserer GraphQL-API erleichtert unseren DNS-Kunden im Zusammenspiel mit der neuen DNS-Analyse-Seite bei ihren Foundation DNS-Implementierungen die Überwachung, Bewertung und Fehlerbehebung.

Neues Release-Verfahren

Für das autoritative DNS-Produkt von Cloudflare werden ungefähr einmal pro Woche Software-Updates veröffentlicht. Cloudflare wendet ein ausgeklügeltes Release-Verfahren an, das verhindert, dass Regressionen den regulären Datenverkehr beeinträchtigen. Es ist möglich – wenn auch ungewöhnlich –, dass Probleme erst zutage treten, wenn die neue Version dem Umfang und der Einzigartigkeit des Produktiv-Traffics ausgesetzt ist.

Da unsere Enterprise-Kunden größeren Wert auf Stabilität als auf neue Funktionen legen, werden neue Versionen einem zweiwöchigen Soak-Test mit unseren Standard-Nameservern unterzogen. Wenn vierzehn Tage lang keine Probleme aufgetreten sind, werden auch die fortschrittlichen Nameserver von Foundation DNS aktualisiert.

Zonen, die fortschrittliche Nameserver von Foundation DNS verwenden, gewinnen an Zuverlässigkeit, weil sie bei neuen Softwareversionen besser vor Regressionen geschützt sind.

Einfachere DNS-Preisgestaltung

Bisher hat Cloudflare die Kosten für autoritative DNS-Dienste anhand der monatlichen DNS-Abfragen und der Anzahl der Domains des Kontos berechnet. Unsere DNS-Firmenkunden sind oft an reinen DNS-Zonen interessiert. Damit sind DNS-Zonen gemeint, die von Cloudflare gehostet werden und nicht unsere Reverse-Proxy (Layer 7)-Dienste wie unser CDN, unsere WAF oder unser Bot-Management nutzen. Mit Foundation DNS vereinfachen wir die Preisgestaltung für die überwiegende Zahl dieser Kunden, da davon standardmäßig 10.000 reine DNS-Domains abgedeckt sind. Aufgrund dieser Änderung zahlen die meisten Kunden nur für die DNS-Abfragen, die sie tatsächlich durchführen.

Abgedeckt sind außerdem 1 Million DNS-Einträge für alle einem Konto zugeordneten Domains. Wir unterstützen bei Bedarf aber auch eine größere Anzahl. Tatsächlich verfügt die größte Einzelzone auf unserer Plattform über 3,9 Millionen Einträge und unser größtes DNS-Konto umfasst knapp 30 Millionen DNS-Einträge, die sich über mehrere Zonen verteilen. Der DNS-Service von Cloudflare kann selbst die umfangreichsten Bereitstellungen problemlos bewältigen.

Wir haben noch viel vor

Das ist aber noch lange nicht alles. Wir werden Foundation DNS um zusätzliche exklusive Funktionen ergänzen. Ein Beispiel ist eine häufig nachgefragte Funktion: API-Token und Nutzerberechtigungen je Datensatz. Damit werden Sie Berechtigungen künftig noch präziser konfigurieren können. Damit lässt sich dann beispielsweise festlegen, dass ein bestimmter Nutzer Ihres Kontos nur Einträge des Typs TXT und MX erstellen und verwalten darf. So wird verhindert, dass dieser versehentlich Adressdatensätze löscht oder in einer Weise bearbeitet, die den an Ihre Domain gerichteten Web-Traffic beeinträchtigen würde. Ein anderes Beispiel wäre die Festlegung von Berechtigungen auf Grundlage von Subdomains, um den Aktionsradius bestimmter Nutzer weiter einzuschränken.

Wenn Sie bereits Enterprise-Kunde sind und Foundation DNS verwenden möchten, wenden Sie sich an Ihr Account-Team. Dieses kümmert sich gern darum, dass Foundation DNS für Ihr Konto freigegeben wird.