Anycast DNS
Was hat es mit IP-Adressen wie 1.1.1.1, 8.8.8.8, 9.9.9.9 u.a. auf sich, warum sind die weltweit schnell und dennoch mit Vorsicht zu genießen?
Welcher DNS -Server?
In der heutigen Zeit geht nichts mehr über die Namensauflösung über DNS. Es geht dabei nicht nur um die Auflösung eines Namens in einer Adresszeile ihres Browsers zu einer IP-Adresse, zu der letztlich die Verbindung aufgebaut wird oder wie ein Mailserver seine Gegenstelle findet. DNS liefert noch viel mehr Informationen, z.B. wo der Kerberos-Service steht etc. Es ist unbestritten, dass Sie als verantwortlicher Netzwerkadministrator ihrem Client den "richtigen DNS-Server" zuweisen sollten. Dazu kennen die meisten Administratoren zwei Wege:
- Statisch an der Netzwerkkarte
Diese Konfiguration wird gerne bei Servern genutzt, die einen festen Standort haben und damit eigentlich immer die gleichen DNS-Server haben. Diese Konfiguration können und sollten sie natürlich nicht nutzen, wenn der Computer in wechselnden Umgebungen eingesetzt wird. - DHCP
Die zweite und dynamische Option ist eine Konfiguration mittels DHCP. Der Client fragt per Broadcast im Netzwerk nach den gültigen Einstellungen und bekommt u.a. auch die DNS-Server. Hier obliegt es dann dem DHCP-Server die passende Konfiguration zu liefern. Dies kann auch für Server eine sinnvolle Option sein
Bei den meisten Firmen ist der DNS-Server aber im gleichen Netzwerk oder im gleichen Standort während es im Homeoffice dann meist der DSL-Router ist, welcher den DNS-Dienst bereitstellt. In Verbindung mit dem Active Directory liefert der lokalen DNS-Server sogar die Namen zuerst zurück, die im gleichen Subnetz sind.
Virtuelle IP-Adresse
Die statische Konfiguration von DNS-Servern hat aber das Problem, wenn der alte DNS-Server abgebaut und durch einen neuen Server ersetzt werden soll. Das kann ein Betriebssystemupdate sein oder auch ein Produktwechsel beim DNS-Dienst. Daher gibt es immer wieder Netzwerke, bei denen die IP-Adresse eines DNS-Servers nicht zugleich dir primäre IP-Adresse des Server ist, welcher den Dienst bereitstellt.
Es ist schon immer möglich, dass ein Computer mehrere IP-Adressen aus dem gleichen Netzwerk hat und Dienste nur auf bestimmten IP-Adressen Verbindungen annehmen. Der große Vorteil dabei ist, dass mit dem Umzug eines Dienstes auf einen anderen physikalischen Server auch einfach die eine IP-Adresse mit umgezogen werden kann. Es müssen also nicht immer alle Dienste eines Servers auf den neuen Server umgezogen werden.
Eine "virtuelle IP" kann auch über Loadbalancer bereitgestellt werden, d.h. die IP-Adresse zum DNS-Server verweist auf einen Netzwerkdienst, der die Anfragen an die entsprechenden "realen Server" weiterreicht und damit eine Hochverfügbarkeit ermöglicht. Die ist aber DNS aber nicht sonderlich wichtig, denn ein Client kann problemlos auch mehrere DNS-Server erhalten und schwenkt alleine auf den nächsten Server, wenn eine Antwort ausbleibt.
Er schwenkt aber nicht, wenn der genutzte DNS-Server mit einem "Host not Found" o.ä. antwortet sondern nur, wenn die Antwort komplett ausbleibt.
Virtuelle IP-Adressen funktionieren natürlich auch über mehrere Subnetze und bei IPv6 sind solche virtuellen Adressen sogar üblich. IPv6 setzt hier auf Anycast-Adressen im gleichen Subnetz. Es gibt ja mit 64bit "genug" Adressen in jedem einzelnen IPv6-Subnetz und genug IPv6-Subnetze, so dass man das Netzwerk "FEC0:0:0:FFFF" einfach als DNS-Servernetz festlegt und es da drin dann unter 1,2 und 3 die Dienste geben kann.
FEC0:0:0:FFFF::1 FEC0:0:0:FFFF::2 FEC0:0:0:FFFF::3
Es ist sehr eng mit "DHCP" verbunden, denn bei IPv6 gibt es auch nicht mehr zwingend einen DHCP-Server. Der Client wartet einfach auf ein empfangenes Paket, z.B. das zyklische "Router Advertisement" eines IPv6-Routers im LAN. Davon kann der Client das Netzwerkprefix beziehen und die Wahrscheinlichkeit bei 2^64 Hostadressen einen Konflikt zu haben, ist doch recht gering.
- IPv6-Labor / Pilot
- IPv6 Stichpunkte
- IPv6 Stateless DNS Discovery
https://www.ietf.org/proceedings/52/I-D/draft-ietf-ipngwg-dns-discovery-03.txt - Stateless DHCPv6
https://www.networkacademy.io/ccna/ipv6/stateless-dhcpv6 - IPv6-Autokonfiguration
https://www.elektronik-kompendium.de/sites/net/2004011.htm
AnyCast Adresse für DNS
Nach den einleitenden Informationen können Sie sich die Frage stellen, warum eine IP-Adresse im Internet immer eindeutig sein muss. Auf der Seite Anycast-Routing habe ich beschrieben, dass dies nicht zwingend der Fall sein muss und das Routingprotokoll sich ja darum kümmern kann, die Pakete der Clients zum nächsten Server mit der Adresse zu routen. Genau das passiert auch im Internet und einige öffentlichen DNS-Server machen davon mächtig gebrauch. Bekannt sind sicher die Adressen wie:
1.1.1.1 CloudFlare 8.8.4.4 Google 8.8.8.8 Google 9.9.9.9 Quadnine 45.90.28.20 NextDNS.io
Diese Adressen unterscheiden sich auf den esrsten Blick natürlich nicht von "normalen" IP-Adressen, da sie ganz klassisch im Class-A/Class-B/Class-C-Bereichen liegen und damit auch keine Multicast-Adressen (Class-E, 224.x.x.x.x und höher) sind. Sie sind aber dennoch "besonders" und das merken Sie, wenn Sie die Adressen z.B. per PING von unterschiedlichen Standorten auf der Welt ansprechen oder eine Namensauflösung machen und die Antwort scher schnell kommt.
Würden diese Server z.B. bei Google in Kalifornien stehen, dann müssen wir aus Deutschland allein aufgrund der Entfernung eine Latenzzeit von über 100ms messen. Sie können dies gerne prüfen.
(measure-command {resolve-dnsname teams.microsoft.com -Server 8.8.8.8}).totalMilliseconds
Ich erhalten über verschiedene Clients (z.B. VMs auf Azure oder Amazon oder Kundenclients mit Rimscout gemessen) rund um die Welt immer Antwortzeiten unter 50ms, meist sogar unter 25ms. Ich lasse nun "Caching" und "WAN-Optimierer außen vor, die so eine unverschlüsselte DNS-Abfrage natürlich auch sehen und stattdessen beantworten könnten. Aber im Grund bedeutet das, dass diese DNS-Server alle "nahe" zu dem entsprechenden Clients stehen. Es gibt also viele Server auf der Welt, die dann die gleiche IPv4-Adresse haben müssen.
Wenn Sie wissen wollen, wie Router und das Netzwerk damit umgehen, dann sollten Sie die Seite Anycast-Routing lesen.
Anycast im internen LAN?
Was das "Internet" nutzt kann ja nicht so schlecht oder falsch sein. Ehe Sie nun aber voller Elan auch in ihrem Firmennetzwerk mit Anycast experimentieren, sollten sie noch einmal genau nachdenken:
- Haben Sie Dienste in verschiedenen
Ländern mit gleichen Inhalt
Nur dann macht es nämlich sinn, pro Standort per DNS und IP-Routing die Clients zum "naheliegenden" Dienst zu lenken. - Ist das Protokoll "Anycast-IP"
tauglich?
HTTP, SMTP etc. sind kompatibel, wenn die Software mitspielt. Exchange kann dies problemlos machen. Allerdings ist es fraglich, welchen Mehrwert sie davon habe, wenn ein Client sich zu einem lokalen Frontend verbindet, der dann doch zum entfernten "Postfach-Server" muss. Da kann der Client doch besser selbst zum Homeserver und den lokalen Server umgehen. Exchange Online macht dies ja, um die Clients über das interne Microsoft-Netz zu routen.
Interessant kann die Funktion aber tatsächlich als Abstraktionsschicht für generische Dienste sein. Es gibt im Netzwerk immer Dienste, die von vielen Clients genutzt werden und in großen Firmen auch dezentrale Empfänger haben. Ich denke da z.B. an:
- Uhrzeit (NTP)
- SMTP-Einlieferung
- Syslog
- SNMP-Traps
- Monitoring
- ProxyServer
Natürlich können Sie für jeden dieser Dienste einen DNS-Namen definieren und per GeoDNS auch an einen naheliegenden Server routen. Was machen Sie aber mit Geräten, die keine DNS-Auflösung können (IoT) oder die Anpassung der Konfiguration eher aufwändig ist? Dann könnte es eine Lösung sein, einfach eine IP-Adresse pro Dienst zu definieren, die aber alle nichts mit dem realen lokalen Netzwerk zu tun haben. Die Clients senden das Paket einfach an das Default-Gateway und hier können Sie als Netzwerker pro Router bestimmen, wohin die Pakete geroutet werden.
Das kann ein lokales direkt angebundenes VLAN sein, in dem die Dienste erreichbar sind oder über das WAN zum nächsten System gehen. Mit Routingprotokollen wie OSPF/RIP/BGP können Sie sogar Netzausfälle kompensieren, von denen der DNS-Server gar nichts mitbekommt.
Ich sage nicht, dass dies die beste Lösung aller Probleme ist. Es ist eine Möglichkeit die Verbindung zu speziellen Diensten auch ohne GeoDNS effektiver erreichbar zu machen und die Redundanz im Netzwerk zu nutzen. Alle anderen Optionen wie Loadbalancer, Cluster, NLB, GeoDNS, IP-Failover etc. sind natürlich weiterhin möglich.
Anycast-DNS-Analyse
Anycast-IP-Adressen unterscheiden sich nicht von normalen Unicast-IP-Addressen. Sie sehen also einer Adresse erst einmal nicht an, ob es mehrere Server an verschiedenen Standorten gibt. Aber es gibt Hinweise, mit denen Sie solchen Adressen auf die Schliche kommen können. Der Schlüssel dazu sind mehrere Clients, die überunterschiedliche Internetprovider an verschiedenen Standorten im Internet verbunden sind. Wobei wir hier schon von „großräumigen“ Abmessungen sprechen, d.h. zwei Clients in Deutschland oder sogar Europa werden vermutlich schnell beim gleichen Endpunkt landen. Dazu sind die Bandbreiten und Laufzeiten so gering. Interessant wird es beim Wechsel der Kontinente. Wenn ein Anbieter wirklich mehrere Server mit der gleichen IP-Adresse in der Welt verteilt hat, dann sollte ein Tracert mit dem Fokus auf die vorletzte Zeile hoffentlich den Router ausgeben, der das Paket dann an den Server weiter leitet. Wenn sich hier dann unterschiede zeigen, dürfte das als sehr starker Hinweis auf Anycast-IP-Adressen zu deuten sein. Eine Garantie ist es aber nicht.
| Service | Traceroute zum Service |
|---|---|
GoogleDNS |
Leider kann ich mit meinen beiden deutschen Zugängen aktuell nicht beweisen, dass die Google-DNS Server über Anycast Routing angeschlossen sind. Google dokumentiert das aber selbst auf: How does Google Public
DNS know which data center
to send me to? Google Public
DNS uses anycast routing to
direct all packets to the
closest DNS server. For more
information on anycast
routing, see the Wikipedia
entry (https://en.wikipedia.org/wiki/Anycast). Passend dazu der Auszug aus der englischen Wikipedia: Google Public DNS
operates recursive name
servers for public use at
the two following IP
addresses:[5] 8.8.8.8
and 8.8.4.4 for IPv4 service,
as well as
2001:4860:4860::8888 and
2001:4860:4860::8844, for IPv6 access.[6] The
addresses are mapped to the
nearest operational server
by anycast routing
C:\>racert 8.8.8.8 Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8] über maximal 30 Abschnitte: 1 16ms 21ms 16ms fritz.box [192.168.178.1] 2 57ms 39ms 39ms loopback1.90.brun.0001-01.dus.de.net.telefonica.de [62.52.200.184] 3 29ms 39ms 19ms ae14-0.0001.dbrx.02.dus.de.net.telefonica.de [62.53.5.36] 4 25ms 24ms 22ms ae1-0.0001.corx.01.dus.de.net.telefonica.de [62.53.0.10] 5 22ms 23ms 22ms ae5-0.0001.corx.01.fra.de.net.telefonica.de [62.53.0.5] 6 23ms 20ms 20ms bundle-ether15.0001.dbrx.02.fra.de.net.telefonica.de [62.53.25.254] 7 23ms 21ms 21ms ae7-0.0001.prrx.13.fra.de.net.telefonica.de [62.53.2.57] 8 21ms 21ms 21ms de-cix.fra.google.com [80.81.193.108] 9 21ms 21ms 21ms 108.170.251.193 10 21ms 21ms 21ms 108.170.237.239 11 29ms 27ms 28ms google-public-dns-a.google.com [8.8.8.8]
C:\>tracert 8.8.8.8 Routenverfolgung zu google-public-dns-a.google.com [8.8.8.8] über maximal 30 Abschnitte: 1 3ms 2ms 1ms fritz.box [192.168.178.1] 2 10ms 9ms 11ms 87.186.225.45 3 20ms 12ms 11ms 217.0.92.86 4 11ms 9ms 11ms pb-sa2-i.PB.DE.NET.DTAG.DE [62.154.107.113] 5 17ms 17ms 16ms 217.5.116.90 6 17ms 16ms 15ms 80.150.170.30 7 16ms 16ms 16ms 108.170.251.193 8 18ms 18ms 16ms 108.170.237.239 9 17ms 16ms 17ms google-public-dns-a.google.com [8.8.8.8] Man sieht hier bei beiden Traceroute-Ausgaben, dass die letzten Hops gleich sind. Dies ist also kein Beweis. Wenn Sie aber etwas suchen, dann finden sie acuh Webbasierte Traceroute-Dienste aus der ganzen Welt. Hier mal ein Trace aus den USA: Host Loss Sent Recv Best ms Avg ms worst ms tantale.home.fifi.org 0% 1 1 0.47 0.47 0.47 173-228-89-1.dsl.static.fusionbroadband.com 0% 1 1 24.83 24.83 24.83 gig1-29.cr1.lsatca11.sonic.net 0% 1 1 24.60 24.60 24.60 ??? 100% 0 1 0.00 0.00 0.00 50.ae4.gw.pao1.sonic.net 0% 1 1 21.83 21.83 21.83 152.ae4.gw.equinix-sj.sonic.net 0% 1 1 34.73 34.73 34.73 209.85.172.186 0% 1 1 21.73 21.73 21.73 108.170.243.1 0% 1 1 24.81 24.81 24.81 74.125.37.41 0% 1 1 24.83 24.83 24.83 google-public-dns-a.google.com 0% 1 1 24.56 24.56 24.56 Der Router vor dem Ziel ist unterschiedlich und die Laufzeit der Pakete belegt quasi, dass der Client in Deutschland und der Client in den USA auf jeden Fall ihre |
Quad9 DNS Service |
Der Name ist Programm, mit dem Quad9 Mitte November 2017 an den Start gegangen ist. Das nicht gewinnorientierte Konsortium betreibt geografisch verteilt DNS-Services, die angeblich keine Daten protokollieren, wer welche Adresse auflöst. Quad9 is
a free, recursive, anycast
DNS platform that provides
end Users robust security
protections,
high-performance, and
privacy. Unter den folgenden IP-Adressen bietet Quad9 ähnlich wie Google DNS-Dienste an
Auf deren Webseite gabt es mal ein Bild der physikalischen Standorte. Alle Server sind unter 9.9.9. erreichbar
Beachten Sie aber bitte, dass die Verwendung die "Optimierung" von Microsoft bezüglich Office 365-Routing torpediert. Siehe dazu auch Office 365 DNS-Routing
|
OpenDNS |
Gestartet als freier DNS-Server, der aber schon von Anfang ab die erhaltenen Daten auswertet und früher unbekannte Domains auf Werbeseiten geleitet hat, ist der Dienst mittlerweile von Cisco aufgekauft und kommerzialisiert worden. Die DNS-Dienste sind mit Anycast-IP-Adressen erreichen. |
NextDNS.IO |
Auch hier gibt es eine ganze Menge von DNS-Servern weltweit, die zumindest zum Teil per Anycast erreichbar sind.
|
Als Gegenprobe habe ich mal einen Tracert aus die msxfaq.de aus zwei Netzwerken gemacht. Schon anhand der Laufzeiten sieht man, dass die MSXFAQ nur in Deutschland liegt und nicht geografisch verteilt wird, so dass man mit Geo-DNS Auflösungen oder Anycast-Routing etwas bewirken könnte.
| Deutschland T-DSL | USA |
|---|---|
|
Routenverfolgung zu www.msxfaq.de [217.160.0.234] über maximal 30 Abschnitte: 1 3ms 1ms 2ms fritz.box [192.168.178.1] 2 10ms 9ms 17ms 87.186.225.45 3 15ms 12ms 12ms 217.0.92.86 4 10ms 9ms 9ms pb-sb2-i.PB.DE.NET.DTAG.DE [62.154.107.117] 5 18ms 16ms 16ms f-ee5-i.F.DE.NET.DTAG.DE [62.154.14.238] 6 19ms 24ms 62ms 80.157.204.170 7 22ms 29ms 21ms ae-11.bb-c.bs.kae.de.oneandone.net [212.227.120.18] 8 23ms 20ms 21ms 217-160-0-234.elastic-ssl.ui-r.com [217.160.0.234] |
http://www.fifi.org/services/traceroute?hostname=www.msxfaq.de&nprobes=1&resolved=yes&submit=Traceroute tantale.home.fifi.org 0% 1 1 0.43 0.43 0.43 173-228-89-1.dsl.static.fusionbroadband.com 0% 1 1 21.87 21.87 21.87 gig1-29.cr1.lsatca11.sonic.net 0% 1 1 21.85 21.85 21.85 ??? 100% 0 1 0.00 0.00 0.00 50.ae4.gw.pao1.sonic.net 0% 1 1 21.82 21.82 21.82 palo-b22-link.telia.net 0% 1 1 21.84 21.84 21.84 nyk-bb4-link.telia.net 0% 1 1 96.81 96.81 96.81 prs-bb4-link.telia.net 0% 1 1 167.83 167.83 167.83 prs-b7-link.telia.net 0% 1 1 171.91 171.91 171.91 1o1internet-ic-309320-prs-b7.c.telia.net 0% 1 1 172.33 172.33 172.33 ae-8-0.bb-a.bap.rhr.de.oneandone.net 0% 1 1 182.15 182.15 182.15 217-160-0-234.elastic-ssl.ui-r.com 0% 1 1 181.75 181.75 181.75 |
Kleine Erfahrung am Rand: Ich wollte einfach eine VM in den verschiedenen Azure-Datacenter starten und von dort einen Traceroute machen. Das Ergebnis war aber ernüchternd:
Tracing route to 13.107.8.20 over a maximum of 30 hops 1 * * * Request timed out. 2 * * * Request timed out. ...... 12 * * * Request timed out. 13 * * * Request timed out. 14 1 ms 1 ms 1 ms 13.107.8.20
Microsoft blockiert ICMP zu und vom Internet komplett. Man kann wohl einen PING machen aber der ICMP-not reachable kommt nicht zurück.
"ICMP support in Azure is blocked
externally but you can allow ICMP on firewall rules in the
VM and ping between VMs in the same cloud service or virtual
network. If you wish to ping between Azure VMs and on-prem
machines; then you can setup Point to Point IPsec tunnels or
a Site to Site VPN, enable ICMP on both ends and ensure
gateway-device firewall (or software VPN gateway) rules
allow ICMP traffic (and have necessary routing table entries"
Quelle: Ping and Tracert commands on Azure VM
https://blogs.msdn.microsoft.com/gsamant/2015/02/16/ping-and-tracert-commands-on-azure-vm/
