PublicDNS Provider und Probleme

Eine Pressemeldung von Cloudflare zu ihrem neuen "sicheren" DNS-Service" unter der IP-Adresse 1.1.1.1 und 1.0.0.1 hat mich bewogen diese Seite zu schreiben. Es mag vielleicht aus Marketing-Aspekten interessant sein, aber technisch ist es sehr negativ für die Nutzung des Internets, solche "unabhängigen" DNS-Server zu nutzen. Dazu zählen auch die Google-DNS-Server 8.8.8.8 und 8.8.4.4 oder Quad9 unter 9.9.9.9. Bei IPv6 hat Google z.B.  2001:4860:4860::8888 und 2001:4860:4860::8844. Lesen Sie selbst.

In letzter Zeit häufen sich die Meldungen in meinem Monitoring, dass die öffentlichen DNS-Server immer mal wieder Aussetzer haben und keine Daten liefern. Das ist in Verbindung mit einem Verbindungsaufbau bei Microsoft Teams natürlich nicht angenehm. Wenn Sie solche DNS-Server nutzen, sollten Sie deren Erreichbarkeit prüfen und ihren Clients einen Fallback anbieten.

"Pizza"-Beispiel

Sie sitzen in Paderborn zuhause und möchten gerne bei einem Pizza-Bringdienst bestellen. Aber weil die Telefonauskunft in Paderborn ihnen vielleicht nicht freundlich genug ist, rufen Sie lieber in Frankfurt an und fragen nach einem guten lokalen Pizza-Restaurant, welches auch ausliefert. Die super-freundliche Stimme (oder KI?) gibt ihnen einen Namen und Rufnummer. Sie haben also schnell und freundlich eine Antwort bekommen. Aber ist die Antwort auch logisch korrekt und sinnvoll? Wie wahrscheinlich ist es, dass eine weit entfernte Auskunft ihnen die passende Antwort liefert?

 Und nun schauen wir uns das Thema mal technisch mit DNS an.

Negativbeispiel

Es gibt sehr viele DNS-Server im Internet, die eine super schnelle und vielleicht sogar gefilterte Namensauflösung (Spam, Malware etc.) versprechen. Als Beispiel nutze ich mal einen DNS-Server 114.114.114.114, der in Asien extrem weit weg steht, damit sie das Verhalten direkt sehen können. Starten Sie einen NSLOOKUP auf Google und dann einen Ping auf die gelieferte IP-Adresse.

nslookup www.google.de <dnsserver>
ping <ip-adresse>

Bei mir ergibt dies:

  Richtiger DNS Falsche DNS
Namenauflösung
C:\>nslookup www.google.de
Server:  fritz.box
Address:  fd00::2e91:abff:fe49:d7c9

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:400e:801::2003
          142.250.186.163
C:\>nslookup www.google.de 114.114.114.114
Server:  public1.114dns.com
Address:  114.114.114.114

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2607:f8b0:4009:805::2003
          172.217.4.67
PING
C:\>ping 142.250.186.163

Ping wird ausgeführt für 142.250.186.163 mit 32 Bytes Daten:
Antwort von 142.250.186.163: Bytes=32 Zeit=17ms TTL=117
Antwort von 142.250.186.163: Bytes=32 Zeit=16ms TTL=117
Antwort von 142.250.186.163: Bytes=32 Zeit=16ms TTL=117
Antwort von 142.250.186.163: Bytes=32 Zeit=16ms TTL=117

Ping-Statistik für 142.250.186.163:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 16ms, Maximum = 17ms, Mittelwert = 16ms
C:\>ping  172.217.4.67

Ping wird ausgeführt für 172.217.4.67 mit 32 Bytes Daten:
Antwort von 172.217.4.67: Bytes=32 Zeit=101ms TTL=114
Antwort von 172.217.4.67: Bytes=32 Zeit=100ms TTL=114
Antwort von 172.217.4.67: Bytes=32 Zeit=99ms TTL=114
Antwort von 172.217.4.67: Bytes=32 Zeit=99ms TTL=114

Ping-Statistik für 172.217.4.67:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 99ms, Maximum = 101ms, Mittelwert = 99ms
Antwortzeit

16-17ms

99-101ms

Das ist nun natürlich das "Worst Case"-Szenario, aber auch in der gleichen Region ist es ein Unterschied, ob Sie von ihrem Provider schnell zum Ziel kommen oder eine falsche DNS-Abfrage ihnen einen Server liefert. der eigentlich von einem anderen Provider besser erreichbar ist.

Umwege erhöhen die Latenzzeit, verringern den Durchsatz, belastet mehr WAN-Strecken, sind störempfindlicher. All das wollen Sie nicht.

Also weiter zu den Details.

So funktioniert DNS

Die Zustellung von Datenpaketen im Internet (und Intranet) erfolgt über eindeutige IP-Adressen. Schon die IPv4-Adressen in der Form xxx.xxx.xxx.xxx ist für Menschen kaum zu merken und IPv6-Adressen schon mal gar nicht. Wie ziehen daher "Namen" wie eben www.msxfaq.de oder www.netatwork.de vor und der Computer kümmert sich um die Ermittlung der aktuell gültigen Adresse. Die Adresse muss also gar nicht für immer die gleiche Adresse bleiben und Namen haben länger bestand, können gesucht werden und per SSL-Zertifikat abgesichert werden.

Jeder Computer muss daher wissen, wo er aus einem Namen eine Adresse machen kann. Dafür sind DNS-Server, die der Computer zugewiesen bekommt. In den meisten Fällen erhält ihr Computer beim Aufbau einer Verbindung mit einem Netzwerk daher neben einer IP-Adresse samt Netzwerkmaske und der Adresse für ein "Default Gateway" auch noch die IP-Adresse der DNS-Server. Im Firmennetzwerk ist ihr Administrator dafür zuständig und im Heimnetzwerk erledigt dies ihr DSL-Router. Der DSL-Router seinerseits bezieht seine Daten vom Internet Provider. Eine "normal Kette" sieht daher wie folgt aus.

Sie sind aber nicht verpflichtet, den DNS-Server ihres Internet Providers zu nutzen. Sie können z.B. direkt die "Root-Server" befragen, die ihnen dann aber keine abschließende Antwort liefert sondern Sie per "Delegation" zu dem zuständigen DNS-Server für das Land und dann die Zone verweisen. Das macht DNS-Server aber normalerweise keine DNS-Clients. Es führt zu einer höheren Belastung der Root-Server, die darauf aber wohl eingestellt sind. Der Betrieb der Server wird mit durch die Kosten für eine "Domäne" finanziert.

Dennoch muss man sich frage, warum sie die Root-Server fragen sollten, wenn ein naheliegender DNS-Server die Antwort auch liefern könnte. Ein Grund ist die Aktualität. DNS-Server haben auch einen "Cache" und gerade die Provider nutzen diesen Cache um Anfragen zu reduzieren. Wenn Sie Nachbar also www.google.de fragt und sie dann auch die Auflösung anfordern, dann bekommen Sie meist die Antwort schon vom DNS-Cache. Das geht schnell aber hilft natürlich wenig, wenn die Adresse nicht mehr gelten sollte. Für gewisse Dinge sollte man direkt den zuständigen Nameserver fragen.

Sicherheit

Ein DNS-Server, der von Clients gefragt wird, liefert nicht nur die Daten an den Client sondern er kann natürlich auch erfassen, welche IP-Adresse welchen Namen anfragt und kann sogar die Antworten verfälschen. Das ist technisch einfach und wird auch von verschiedenen Staaten und Firmen genutzt. Das muss ihnen bewusst sein. Hier eine Anfrage meines Clients per DNS und die Antwort dazu im Wireshark.

Die Anfrage erfolgt per UDP und komplett unverschlüsselt und auch die Antwort sehen sie oben in der Liste  im Klartext. Es ist für Provider und staatliche Stellen also kein Problem zu ermitteln, welche Webseiten Sie ansurfen, selbst wenn die eigentliche Verbindung z.B. per HTTPS verschlüsselt ist. Selbst mit HTTPS kann jemand immer noch die Namen im Zertifikat ermitteln. Auch ist ist schon länger Stand der Technik. Ein Versuch per DNSSEC die DNS-Abfrage selbst zu verschlüsselt, hilft nicht weiter, da die meisten Clients gar kein DNSSEC können und das Protokoll meist zwischen DNS-Servern und Forwardern zum Einsatz kommt, um primär die Authentizität der Daten zu gewährleisten, d.h. Veränderungen und Fälschungen zu erkennen.

Damit können Sie nun natürlich auch leichter verstehen, warum ein Suchgigant wie Google nicht ganz selbstlos zwei DNS-Services unter 8.8.8.8 und 8.8.4.4 bereitstellt und die Werbetrommel rührt doch diese DNS-Server einzutragen, wenn Sie die vom Provider per DHCP-an den DSL-Router gesendeten Services umgehen wollen. Google bekommt im Gegenzug natürlich gleich mehrere Informationen:

  • Wer fragt was?
    Das sind sicher die wichtigsten Quelle, auf die es Google beim Betrieb der "freien" DNS-Server abgesehen hat. Wenn Sie ihren Clients diese Server direkt vorgeben, dann erhält Google sehr genau die Information, welche Namen ihr Client erfragt hat. Das ist ein sicheres Zeichen, dass Sie eine Information von dort abgefragt haben. Wenn Google dann ihre IP-Adresse aus der Google-Suche schon kenn, kann Google die Anfragen auch weitere DNS-Anfragen ziemlich gut zuordnen, auch wenn Sie nicht über die Google Suche dort hin gekommen sind. Zwar erschwert NAT die eindeutige Zuordnung aber bezogen auf Privatkundenanschlüsse mit wenige Clients ist ihre öffentliche IP des DSL-Routers zumindest auf ihren Haushalt verknüpfbar.
  • Welche IP-Subnetze landen auf welchem ihrer DNS-Server?
    Damit lässt sich schon eine erste "Map" der Verbindungen und Peering erstellen und wen man die TTL-Werte mit auswertet, die einen Hinweis auf die Entfernung eines Clients geben, kann der Anbieter sein eigenes Netzwerk optimieren.

Da kommt natürlich das Angebot von Cloudflare in einem anderen Licht daher. Zum einen sind die Adressen 1.1.1.1und 1.0.0.1 natürlich sehr einprägsam und daher eine sehr leicht zu merkende Adressen. Zum anderen Schreibt Cloudfare ja auch, dass Sie als Content Dienstleister die technische Plattform zum stabilen und skalierbaren Betrieb haben. Allerdings behauptet Cloudflare diesmal, dass sie sich als "sichere Alternative" zu den "unsicheren" oder zumindest nicht vertrauenswürdigen DNS-Servern verschiedener Länder und Provider positionieren.

Das Problem dabei wird aber sein, dass genau diese Staaten und Stellen nun erst recht dafür sorgen, dass Anfragen an 1.1.1.1 entweder plump geblockt oder intelligent auf eigene DNS-Services umgeleitet werden. Schließlich haben sich diese Nutzer ja absichtlich dafür entschieden, diesen Service zu nutzen und machen sich damit damit verdächtig. Der Weg zu den 1.1.1.1-Servern wird per IP-Routing bekannt gegeben und für einen Provider ist es eher ein Aufwand von Minuten einen eigenen DNS-Forwarder mit der Adresse aufzubauen und zumindest in seinem Netzbereich die Router zu überstimmen.

Interessant ist natürlich der Ansatz, dass eine Abfrage per HTTPS unter https://1.1.1.1 möglich sein soll. Am 3- April 2018 13:55 MESZ bekam ich aber erst mal ein "Connection Refused". Dieser Weg einer Namensauflösung funktioniert natürlich nur, wenn die Clients auch diesen Weg nutzen würde. Aktuell ist mir keine Umsetzung für Windows oder Linux bekannt, die schon "DNS over HTTPS" unterstützt.

Geo-DNS und Office 365

Wenn wir nun aber mal das Thema Sicherheit außen vor lassen, gibt es einen ganz anderen Aspekt, der die Anwendung dieser freien DNS-Server verschlechtert. Die Auflösung wird für Dienste sicher gut funktionieren, die nur an einem Ort in der Welt bereitgehalten werden. Das sind aber hinsichtlich der Datenmenge eher kleine Anteile. Die großen Services wie Google, YouTube, Netflix, FaceBook, Apple, Microsoft Office 365, u.a. sind geografisch verteilt und nutzen ausgefeilte Techniken wie Geo-DNS / Pinpoint DNS oder Anycast-Routing, um den Weg vom Client zum Service kurz und effektiv zu halten. Diese Dienste "wollen" ja was von ihnen in Form von Daten (Facebook und Co) oder monatliche Zahlungen (Netflix, Office 365) und bauen zum einen eigene Netzwerke auf und verbinden sich regional mit den Providern. Es ist doch viel besser, wenn ich von meinem DSL-Anschluss über meinen Zugangsprovider direkt zum Serviceanbieter gelange ohne über andere Transferprovider oder Public Peerings (DeCIX etc.) zu gehen.

Das funktioniert natürlich nur, wenn mein Client bei einer Anfrage nach einem DNS-Namen auch eine "naheliegende" IP-Adresse genannt bekommt. Solange der Anbieter also weltweit viele Server mit unterschiedlichen IP-Adressen betreibt, muss der Anbieter anhand der anfragenden IP-Adresse ermitteln, welche IP-Adresse aus Sicht des "Netzwerks" am günstigsten ist. Das funktioniert aber nur, wenn ich als Anbieter auch eine passende DNS-Anfrage bekommt, die aus dem Netzbereich ist. Wenn ich also den DNS-Server meines Providers frage, dann wird beim Anbieter eben dieser DNS-Server als Source-IP erscheinen und der Anbieter kann die IP-Adressen liefern, die zu diesem Provider den kürzesten Pfad haben.

Wenn ich nun aber einen ganz anderen DNS-Service nutze und dieser dann entweder beim Anbieter nachfragt oder die Daten aus seinem Cache liefert, dann ist es nicht unwahrscheinlich, dass ich eine suboptimale Zieladresse. Am Beispiel von Office 365 lässt sich das ganz schnell ermitteln, indem ich einmal den Namen "outlook.office365.com" über meinen DSL-Router auflöse, der aktuell den Telekom-DNS-Server fragt und eine zweite Anfrage an die 1.1.1.1 geht.

DNS-Server Telekom Endkunden-DSL Cloudflare Google 8.8.8.8 9.9.9.9

Antwort

Es fällt nicht nur der Unterschied in der Anzahl der Antworten auf sondern auch der Name des Ziels. Ganz aus der Rolle fällt am 3. April 2018 z.B. Quad9 (9.9.9.9). Aus Deutschland einen Zugriff auf "Nordamerika South" zu nutzen, wenn mein Tenant in Amsterdam liegt, ist ziemlich daneben.

Aber selbst wenn die Antwort "in der Nähe" scheint, ist es immer noch kein Garant für eine optimale Wegewahl. Als Telekom-Client bekomme ich "outlook-emeaeast2.office365.com".Das ist mit einem Tracert sehr nahe. bei einem Traceroute ist interessant zu sehen, dass Microsoft seine Subnetze anscheinend alle richtig zur Telekom meldet, da zu allen drei Zielen der Weg zum Microsoft Netzwerk der Gleiche ist.

Allerdings ist natürlich intern das Routing von Microsoft dann nicht mehr optimal. Beim letzten Tracert sieht man schon, dass die Pakete über New York/Washington gehen und dort auf den Exchange Frontend, der natürlich nichts besseres zu tun hat als als Proxy die Daten dann aus Amsterdam anzufordern.

Selbst ein einfacher "Ping" zeigt den Unterschied, wenn man den DNS-Eintrag umsetzt:

REM Ping mit einer Auflösung gegen 9.9.9.9
ping outlook.office365.com

Ping wird ausgeführt für outlook.office365.com [40.97.51.66] mit 32 Bytes Daten:
Antwort von 40.97.51.66: Bytes=32 Zeit=150ms TTL=237

REM
ping outlook.office365.com
Ping wird ausgeführt für outlook.ms-acdc.office.com [40.101.124.34] mit 32 Bytes Daten:
Antwort von 40.101.124.34: Bytes=32 Zeit=18ms TTL=243

Nur nur die Antwortzeit ist mit 18ms zu 150ms deutlich schneller. Auch der TTL ist mit 243 höher als die 237. Ds Paket zur IP-Adresse, die z.B. 9.9.9.9 geliefert hat, ist deutlich mehr Hops und länger unterwegs.

Microsoft macht schon einen sehr guten Job die Pakete trotz falscher IP-Adresse schon sehr schnell zum nächsten Übergang zu leiten. Zukünftig wird das noch weiter optimiert, wenn jeder Server nur noch mit einer Anycast-IP-Adresse im Internet bekannt ist und die Clients damit nicht nur den nächsten Übergang sondern auch ersten Server dahinter erreichen werden.

Aber nicht jeder Anbieter hat ein großes eigenes Netzwerk mit vielen Peerings. Wer also noch Geo-DNS nutzt um anhand der Client-IP einen naheliegenden Server anzugeben, wird mit solchen vergifteten DNS-Forwardern zwar kein technisches Problem haben aber die Anwender hat eine schlechtere Leistung.

Meine Empfehlung

So nett die Angebote von Google, Quad9 und nun auch Cloudflare sind, so kritisch sehe ich deren Aufbau und Einsatz. Es gibt sicher Anwendungsszenarien, bei denen der Wechsel auf einen der Resolver interessant sein kann aber in der Regel sind Sie besser dran, wenn Sie den DNS-Resolver ihres Providers als Forwarder oder die Root-Server für Verweise zu den richtigen DNS-Servern fragen.

Die Nutzung der fremden DNS-Server funktioniert zwar auf den ersten Blickt und oft scheint die Antwort sogar schneller zu sein. Aber was interessiert mich die einmalige erste Antwort, wenn Sie die falschen IP-Adressen liefert und daher der Datenzugriff auf Google, Facebook, Twitter und insbesondere auf Office 365 dann langsamer ist.

Die versprochene "Sicherheit" und "Zensurumgebung" ist bei der Nutzung von DNS over UDP sowieso nicht haltbar und wägt die in einer trügerischen Sicherheit, die nicht die Hintergründe verstehen. Provider und Geheimdienste können sehr einfach die Provider und Router-Betreiber zwingen, genau diese Anfragen auszuleiten.

Die DNS-Anbieter bekommen anhand der Anfragen aber nicht nur die Information ,welche Quelle-IP welche Hostnamen im Internet abfragen sondern sehen sehr oft auch Abfragen auf interne Namen wie z.B. SRV-records auf "_ldap._tcp<domain>" oder "_sipinternaltls._tcp.<sipdomain>" und können so auch den Client zu einer Firma zuordnen.

Weiterer Links