Einführung des DNS Resolver, 1.1.1.1 (kein Witz)

Cloudflare hat es sich zur Aufgabe gemacht, beim Aufbau eines besseren Internets mitzuwirken. Heute stellen wir unseren DNS Resolver, 1.1.1.1, vor – einen rekursiven DNS-Dienst. Wir entwickeln einen öffentlichen DNS-Resolver, der noch schneller, sicherer und datenschutzorientierter ist. So stärken wir das Fundament des Internets. Der DNS Resolver, 1.1.1.1, ist öffentlich für jedermann zugänglich – dies ist der erste kundenorientierte Dienst, den Cloudflare je herausgebracht hat.

Wir verwenden die folgenden IPv4-Adressen für unsere Resolver: 1.1.1.1 und 1.0.0.1. Leicht zu merken. Diese Adressen wurden Cloudflare von APNIC für die gemeinsame Forschung und für diesen Dienst zur Verfügung gestellt. Mehr über die Arbeit von APNIC erfahren Sie im APNIC-Blog.

DNS Resolver, 1.1.1.1, läuft auf Cloudflares globalem Anycast-Netzwerk.

Unsere Freunde von DNSimple haben dieses fantastische DNS-Tutorial erstellt, mit dem jeder seine Kenntnisse der Funktionsweise des DNS auffrischen kann. Darin werden Resolver, Root Name Server und vieles mehr in sehr informativer Weise erklärt.

Beim Auflösen eines Domainnamens wird eine Abfrage von Ihrem Endsystem (d. h. einem Web-Browser) an einen rekursiven DNS-Dienst gestellt. Wenn der DNS-Eintrag im lokalen Cache des Dienstes nicht vorhanden ist, wird vom Recursor die autoritative DNS-Hierarchie abgefragt, um die von Ihnen gesuchten IP-Adressinformationen ausfindig zu machen. Der DNS Resolver, 1.1.1.1, übernimmt hierbei die Rolle des Recursor. Es muss schnell und heutzutage auch sicher sein!

Unsere Ziele mit dem öffentlichen Resolver sind simpel: Cloudflare hat es sich zum Ziel gesetzt, den schnellsten öffentlichen Resolver der Welt zur Verfügung zu stellen und gleichzeitig den Datenschutzstandard für Nutzer zu heben. Um das Internet schneller machen, bauen wir bereits Rechenzentren auf der ganzen Welt auf, um den Abstand (d. h. die Latenz) von Nutzern und Inhalten zu reduzieren. Über kurz oder lang wollen wir, dass jeder maximal 10 Millisekunden von mindestens einem unserer Standorte entfernt ist.

Allein im März haben wir einunddreißig neue Rechenzentren weltweit eingerichtet (Istanbul, Reykjavík, Riad, Macau, Bagdad, Houston, Indianapolis, Montgomery, Pittsburgh, Sacramento, Mexiko-Stadt, Tel Aviv , Durban, Port Louis, Cebu City, Edinburgh, Riga, Tallinn, Vilnius, Calgary, Saskatoon, Winnipeg , Jacksonville, Memphis, Tallahassee, Bogotá, Luxemburg-Stadt, Chișinău) und genau wie jede andere Stadt in unserem Netzwerk betreiben die neuen Standorte den DNS Resolver, 1.1.1.1, vom ersten Tag an!

Auf unserem schnellen und hochgradig verteilten Netzwerk läuft jedes Protokoll. Wir sind derzeit der schnellste autoritative DNS-Provider im Internet, eine Leistung, die von mehr als 7 Millionen Internet-Standorten genutzt wird. Darüber hinaus bieten wir auf zwei der dreizehn Root-Nameserver bereits einen Anycast-Dienst an. Der nächste logische Schritt war, einen schnelleren rekursiven DNS-Dienst für Nutzer bereitzustellen. Unser Recursor kann die autoritativen Server nutzen, die sich ebenfalls an unseren Standorten befinden, was schnellere Lookups für alle Domainnamen ermöglicht.

DNSSEC gewährleistet zwar die Integrität von Daten zwischen einem Resolver und einem autoritativen Server, bietet aber keinen Datenschutz auf der „letzten Meile“ zu Ihnen. DNS Resolver, 1.1.1.1, unterstützt beide neuen DNS-Datenschutzstandards: DNS-over-TLS und DNS-over-HTTPS. Beide bieten eine sogenannte „Letzte Meile-Verschlüsselung“ an, um Ihre DNS-Abfragen privat zu halten und vor Manipulation zu schützen.

Bisher wurde der vollständige Domainname auf dem Weg zur Root- oder autoritativen DNS vom Recursor an irgendeinen Vermittler gesendet. Dies bedeutete, dass bei Ihrem Besuch auf www.cloudflare.com sowohl beim Root-Server als auch beim .com-Server die vollständigen Domainnamen abgefragt wurden (d. h. die www-, die Cloudflare- und die com-Teile), obwohl Root-Server lediglich rekursiv an „.com“ weiterleiten müssen (unabhängig vom ganzen Rest des vollqualifizierten Domainnamens). Dieser leichte Zugang zu persönlichen Browsing-Daten über DNS stellt für viele ein ernstes Datenschutzproblem dar. Dieses Problem wurde durch mehrere Resolver-Softwarepakete angegangen, aber nicht alle Lösungen wurden auf breiter Basis angepasst oder eingesetzt.

Der DNS Resolver, 1.1.1.1, bietet bereits am ersten Tag alle definierten und empfohlenen DNS-Datenschutzmechanismen für den Einsatz zwischen dem Stub-Resolver und dem rekursiven Resolver. Sollten Sie mit diesen Begriffen nicht vertraut sein: ein Stub-Resolver ist eine Komponente Ihres Betriebssystems, die mit dem rekursiven Resolver kommuniziert. Da der DNS Resolver, 1.1.1.1, ausschließlich mit DNS Query Name Minimisation arbeitet, wie in RFC7816 definiert, reduziert er den Informationsumfang, der an zwischengeschaltete DNS-Server durchsickert, zum Beispiel Root und TLDs. Das bedeutet, dass der DNS Resolver, 1.1.1.1, nur gerade so viel vom Namen sendet, dass die Authority dem Resolver mitteilen kann, wo er sich weiter durchfragen muss.

Der DNS Resolver, 1.1.1.1, unterstützt zudem datenschutzfähige TLS-Abfragen auf Port 853 (DNS über TLS), so dass wir Abfragen vor neugierigen Netzwerken verborgen halten können. Darüber hinaus verbessert das experimentelle DoH-Protokoll (DNS over HTTPS) sowohl den Datenschutz als auch eine Reihe von zukünftigen Beschleunigungen für Endanwender, da Browser und andere Anwendungen nun DNS- und HTTPS-Traffic in einer einzigen Verbindung mischen können.

Mit aggressivem negativem DNS-Caching, wie unter RFC8198 beschrieben, können wir die Last auf dem globalen DNS-System weiter verringern. Bei dieser Technik wird zunächst versucht, den negativen Cache der vorhandenen Resolver zu verwenden, welcher negative (oder nicht vorhandene) Informationen für einen bestimmten Zeitraum speichert. Für DNSSEC-signierte Zonen und mithilfe der NSEC-Einträge im Cache kann der Resolver ohne weitere Abfragen herausfinden, ob der angeforderte Name NICHT vorhanden ist. Wenn Sie also wwwwwww Punkt soundso und dann wwww Punkt soundso eingeben, kann die zweite Abfrage mit einem sehr schnellen „Nein“ (NXDOMAIN in der DNS-Welt) beantwortet werden. Aggressives negatives Caching funktioniert nur mit DNSSEC-signierten Zonen. Dies umfasst die Root und die 1400 von 1544 TLDs, die bereits heute signiert sind.

Wir nutzen soweit möglich DNSSEC-Validierung, um sicherzugehen, dass die Antworten präzise und unverfälscht sind. Die Kosten für die Signatur-Verifikationen sind gering und werden durch die potenziellen Einsparungen aus aggressivem negativem Caching mehr als ausgeglichen. Wir möchten, dass unsere Nutzer unseren Antworten vertrauen, und nehmen daher alle möglichen Kontrollen vor, um fehlerhafte Antworten zu verhindern.

Allerdings ist DNSSEC sehr gnadenlos. Durch Fehler in der DNSSEC-Konfiguration seitens autoritativer DNS-Betreiber können solche falsch konfigurierten Domains unauflösbar werden. Um dieses Problem zu umgehen, konfiguriert Cloudflare „Negative Trust Anchors“ auf Domains, die erkannte und geprüfte DNSSEC-Fehler enthalten, und entfernt diese, sobald die Konfiguration durch autoritative Betreiber korrigiert wird. Dies begrenzt die Auswirkung fehlerhafter DNSSEC-Domains, denn die DNSSEC-Validierung für eine bestimmte, falsch konfigurierte Domain wird vorübergehend deaktiviert und der Zugang für den Endanwender wiederhergestellt.

Zunächst zogen wir in Erwägung, einen eigenen Resolver zu entwickeln. Allerdings haben wir diesen Gedanken aufgrund der Komplexität und aufgrund von Markteinführungsaspekten wieder verworfen. Dann sahen wir uns alle Open-Source-Resolver auf dem Markt an. Aus dieser langen Liste trafen wir eine Vorauswahl von zwei oder drei Resolvern, die für die Erreichung der meisten Projektziele geeignet wären. Letztendlich beschlossen wir, das System um den Knot Resolver von CZ NIC herum zu entwickeln. Dies ist ein moderner Resolver, der ursprünglich vor etwa zweieinhalb Jahren eingeführt wurde. Durch die Auswahl des Knot Resolver erhöhen wir zudem die Softwarevielfalt. Ausschlaggebend für diesen Schritt war, dass dieser Resolver mehrere Kernfunktionen besaß, die wir wollten, sowie eine modulare Architektur, ähnlich wie OpenResty. Der Knot Resolver wird aktiv genutzt und weiterentwickelt.

Die neuesten erweiterten Funktionen, um die es uns ging, waren:

• Query Minimization RFC7816,

• DNS-over-TLS (Transport Layer Security) RFC7858,

• DNS-over-HTTPS-Protokoll DoH,

• Aggressive negative Antworten RFC8198,

Kleiner Hinweis: der ursprüngliche Hauptentwickler des Knot Resolver, Marek Vavruša, gehört seit über zwei Jahren zum DNS-Team bei Cloudflare.

Es gibt viele Faktoren, die die Geschwindigkeit eines Resolvers beeinflussen. Der erste und wichtigste ist: kann er aus dem Cache heraus antworten? Wenn dies möglich ist, ist die Antwortzeit lediglich die Umlaufzeit eines Pakets vom Client zum Resolver.

Wenn ein Resolver eine Antwort von einer Authority benötigt, wird es etwas komplizierter. Um einen Namen aufzulösen, muss ein Resolver der DNS-Hierarchie folgen. Dies bedeutet, dass er mit mehreren autoritativen Servern kommunizieren muss, beginnend mit der Root. Beispielsweise dauert es für unseren Resolver in Buenos Aires (Argentinien) länger, einer DNS-Hierarchie zu folgen, als für unseren Resolver in Frankfurt (Deutschland), weil dieser sich näher an den autoritativen Servern befindet. Um dieses Problem zu umgehen, befüllen wir unseren Cache bei beliebten Namen vorab. So können beim Eingang einer Abfrage Antworten aus dem Cache geholt werden, was viel schneller ist. In den nächsten Wochen bringen wir Blogbeiträge über einige weitere Maßnahmen, mit denen wir den Resolver noch schneller und besser machen, z. B. unser Fast-Caching.

Ein Problem unseres weitreichenden Netzwerks besteht darin, dass sich die Cache-Trefferquote umgekehrt proportional zu der Anzahl der in jedem Rechenzentrum konfigurierten Knoten verhält. Gäbe es nur einen Knoten in einem Rechenzentrum in Ihrer Nähe und würden Sie eine Abfrage wiederholen, würden Sie bei der zweiten Abfrage garantiert eine zwischengespeicherte Antwort erhalten. Da es in jedem unserer Rechenzentren jedoch Hunderte von Knoten gibt, erhalten Sie möglicherweise eine nicht zwischengespeicherte Antwort und bezahlen den Latenz-Preis für jede Anforderung. Eine häufige Lösung ist der Einsatz eines Caching Load Balancer, also eines zwischenspeichernden Lastenausgleichsmoduls, vor allen Ihren Resolvern. Das führt aber leider zu einem „Single-Point-of-Failure“. Auf einen Single-Point-of-Failure lassen wir uns nicht ein.

Anstatt auf einen zentralen Cache zu vertrauen, verwendet der DNS Resolver, 1.1.1.1, einen innovativen verteilten Cache, worauf wir in einem späteren Blogbeitrag zurückkommen werden.

Hier ist der Deal: wir speichern niemals Client-IP-Adressen und verwenden nur Abfragenamen für Dinge, die die DNS-Resolver-Leistung verbessern (z. B. Vorfüllen aller Caches für beliebte Domains in einer Region und/oder nach Verschleierung, APNIC-Recherche).

Cloudflare speichert niemals Informationen in Protokollen, die einen Benutzer identifizieren. Des Weiteren werden alle von unserem öffentlichen Resolver gesammelten Protokolle innerhalb von 24 Stunden gelöscht. Wir werden weiterhin unsere Datenschutzerklärung einhalten und sicherstellen, dass keine Nutzerdaten an Werbetreibende verkauft oder dazu verwendet werden, Verbraucher gezielt anzusprechen.

Siehe https://1.1.1.1/ . So einfach ist das!

Wir danken unserem Partner APNIC für die IPv4-Adressen 1.0.0.1 und 1.1.1.1 (die offensichtlich wahnsinnig leicht zu merken sind). Ohne APNICs jahrelange Forschungs- und Testarbeiten wäre es unmöglich, diese Adressen zu nutzen. Allerdings haben wir noch einen langen Weg vor uns. Verfolgen Sie unsere Abenteuer mit diesen IP-Adressen auf unserem Blog.

Für IPv6 haben wir 2606:4700:4700::1111 und 2606:4700:4700::1001 für unseren Dienst ausgewählt. Es ist nicht so einfach, tolle IPv6-Adressen zu bekommen. Allerdings haben wir eine Adresse ausgewählt, die nur Ziffern verwendet.

Aber warum Adressen verwenden, die leicht zu merken sind? Was ist besonders an öffentlichen Resolvern? Wir arbeiten zwar bei fast allem mit Namen, aber in diesem Prozess gibt es immer einen ersten Schritt, und für diesen braucht man diese Zahlen. In den Computer oder das angeschlossene Gerät, das Sie verwenden, muss eine Zahl eingegeben werden, um einen Resolver-Dienst zu finden.

Unser öffentlicher Resolver kann von jedermann im Internet verwendet werden. Für weitere Informationen hierzu gehen Sie auf https://1.1.1.1/ und klicken Sie auf LOSLEGEN.

Für die meisten Menschen auf der Welt ist Sonntag der 01.04.2018 (in Amerika ist der Tag/Monat umgekehrt, nämlich 04.01.2018). Sehen Sie die 4 und die 1? Wir schon und deshalb findet die Bekanntgabe von 1.1.1.1 heute statt. Vier Einsen! Wenn diese Ihnen dabei helfen, sich an 1.1.1.1 zu erinnern, dann ist das eine gute Sache!

Klar, es ist auch Tag des Aprilscherzes und für viele Menschen ist dies ein Tag, an dem Witze und Scherze gemacht oder harmlose Streiche gespielt werden. Dies ist kein Witz, dies ist kein Scherz, dies ist kein Streich. Dies ist DNS Resolver, 1.1.1.1 ! Folgen Sie ihm auf #1dot1dot1dot1

Tags: DNS, 1.1.1.1, Datenschutz, Resolver, Produkt-Neuigkeiten