DNS QueryFailover

Jeder glaubt, er kennt DNS und dennoch finde ich bei Kunden immer wieder Fehlkonfigurationen. Wer auf einem Client mehrere DNS-Server einträgt oder auf einem DNS-Server mit Forwardern arbeitet, muss zwischen "Verfügbarkeit" und "Namensraum" unterscheiden.

Szenario

Ein Client bekommt statisch oder per DHCP auch DNS-Server und die DNS-Server selbst müssen wissen, wie sie Einträge auflösen, die sie nicht lokal als Zone vorhalten. Die Namensauflösung per DNS ist eine hierarchische Struktur, bei der ein Client die ihm zu gewiesenen DNS-Server (Schwarze Linie zu 1) abfragt und diese Server können nun auf mehrere Weg nichtlokale Informationen erhalten.

Der gefragt DNS-Server kann dann seinerseits entweder über die Konfiguration eines Forwarder z.B. einen DNS-Proxy auf der Firmen-Firewall, die DNS-Server des Zugangsproviders oder auch die Root-Server fragen. Die angefragten Server entscheiden dann selbst, ob die den Fragesteller an einen besseren DNS-Server verweisen (Referral) oder die Information selbst  rekursiv beschaffen und entsprechend antworten.

Client Auflösung

Der Client kann problemlos zwei oder mehr DNS-Server fragen. In den Eigenschaften der Netzwerkkarte können Sie dies statisch interlegen oder per DHCP zu weisen.

In der Regel fragt ein Client einfach die internen DNS-Server, welche alle den gleichen Wissenstand haben. Auf einem Windows Client gibt es eine Priorität und er fragt zu erst den Eintrag bei "bevorzugter DNS-Server" und dann den Eintrag bei "alternativer DNS-Server". Wenn Sie alle Clients statisch konfigurieren, sollten Sie die Einträge zufällig machen, damit nicht alle Clients immer nur den ersten Server fragen. Wenn Sie ihre DNS-Server per DHCP vorgeben, dann wird der DHCP-Server in der Regel die Reihenfolge würfeln.

Ich habe aber auch schon Konfigurationen gesehen, in denen ein Administrator dem Client neben den internen Servern auch externe Server konfiguriert hat.

DNS1 = 192.168.1.11  (Domaincontroller1 mit Informationen zum internen AD)
DNS1 = 192.168.1.12  (Domaincontroller2 mit Informationen zum internen AD)
DNS1 = 8.8.8.8  (Google DNS zur externen Auflösung)
DNS1 = 1.1.1.1  (Cloudflare DNS zur externen Auflösung)

Die Hoffnung des Administrator ist hier, dass der Client zuerst die internen DNS-Server fragt, um das lokale Active Directory und interne Server aufzulösen. Wenn dann eine Anfrage auf externe Adressen erfolgt, die vom lokalen DNS-Server nicht beantwortet werden können, dann erwartet der Administrator, dass der Client eben die weiteren DNS-Server durchprobiert. So funktioniert aber ein DNS-Client nicht. Es gibt vier mögliche Reaktionen eines DNS-Servers auf eine Anfragen und der entsprechenden Reaktion des Clients

Reaktion des DNS-Servers Verhalten des Clients

Antwort mit Daten

Der Client bekommt die Daten und nutzt diese. Das ist das Regelverhalten für gültige Namen

Antwort mit Umleitung

Der DNS-Server sagt dem Client, dass er für diesen Namen einen anderen DNS-Server fragen soll. Der Client stellt die Anfrage erneut an den anderen Server. Der Vorteil für den DNS-Server ist, dass er es nicht die Information beschaffen und an den Client geben muss, sonder den Client selbst fragt.

Antwort mit "Keine Daten"

Ein DNS-Server kann durchaus antworten und dem Client sagen, dass es den Namen nicht gibt. Der Client stoppt hier dann, denn der DNS-Server hat ja geantwortet. Der Client wird nun nicht die anderen DNS-Server in seiner Liste durchprobieren

Keine Antwort

Wenn die DNS-Antwort komplett ausbleibt, d.h. der DNS-Server nicht funktioniert, dann fragt der Client den nächsten DNS-Server in der Liste

Erwarten Sie also nicht, dass ein DNS-Client bei dem obigen Beispiel korrekt funktioniert, denn solange die internen DNS-Server auflösen, wird er die externen DNS-Server nicht fragen. Eine externe Namensauflösung hängt also davon ab, ob die internen DNS-Server auch externe Namen rekursiv auflösen oder eine Weiterleitung an den Client geben können.

DNS-Server

Eine ähnliche Einstellung gibt es auch auf dem DNS-Server. Alle DNS-Server haben eigentlich eine Liste der Root-Server statisch hinterlegt und sie können allgemeine Forwarder konfigurieren oder selektive Forwarder für bestimmte Zonen.

Die Rootserver werden bei Windows DNS-Servern nur genutzt, wenn die Liste der Forwarder leer ist oder sie dort die Checkbox "Use root hints.." aktivieren. Sie müssen sich, vereinfacht ausgedrückt, also entscheiden, ob und wie ihr DNS-Server auch externe Namen auflösen soll. Sie können die externe Auflösung nicht den Clients überlassen. Für die externe Auflösung gibt es auch beim DNS-Server mehrere Optionen:

Option Bedeutung

Forwarder zum ISP

Wenn ihr Internet Provider einen DNS-Server anbietet, dann können Sie diesen als Forwarder direkt im DNS-Server eintragen. Einige Kunden zwingen die internen DNS-Server einen Forwarder auf der Firewall oder in einer DMZ zu fragen, der dann seinerseits den ISP-Server fragt. Solange die Kette alle Namen auflösen kann, ist das erlaubt.

Problematisch wird dies, wenn sie mehrere parallele Internetprovider haben und die Auflösung über ISP1 läuft während der Verkehr dann doch über ISP2 geht. Cloud-Dienste, die per Geo-DNS und Source-IP eine optimale Adresse liefern, haben hier keine Chance.

Root-Server

Wenn sie keinen Forwarder nutzen wollen, dann fragt der DNS-Server die statisch hinterlegten Root-Server. Auch das ist erlaubt, aber die Root-Server antworten nicht mit der gewünschten Information sondern verweisen den DNS-Server zu dem DNS-Anbieter für die gewünschte Zone. In Deutschland sind das die DNS-Server des DENIC, die dann die Anfrage wieder weiter auf den DNS-Server für die Zone verweisen. Der DNS-Server muss also mehrfache Anfragen zu unterschiedlichen Servern stellen. In der Firewall sollten Sie also ausgehende DNS-Anfragen (53/UDP und 53/TCP) zulassen.

Der Vorteil ist hier, dass kein Cache auf dem Weg ihnen alte Daten liefert und der Zielprovider ihnen anhand der anfragenden IP-Adresse eine optimierte Antwort liefern kann (Geo-DNS)

Forwarder zu Google, Cloudflare, Quad9 o.a.

Es gibt Anbieter, die aus ihrer Sicht "bessere" DNS-Server anbieten, die auch sehr schnell die Antwort ausliefern und teilweise Mehrwerte wie Filterung von Malware-Hosts enthalten und nichts kosten. Sie bezahlten allerdings durch die Preisgabe von Metadaten. Wenn z.B. Google all ihre DNS-Anfragen sieht, dann lässt sich schon ein Benutzerprofil oder Firmenprofil erstellen. Wenn dann eine Partnerseite noch individuelle Hostnamen als "Identifikation" einbindet, dann sind sie recht gläsern.

Störender finde ich aber die suboptimale Auflösung bei Geo-DNS. Wenn ich beim ISP1 bin und einen DNS-Server beim ISP2 frage, der dann beim Hoster3 nachfragt, dann bekomme ich den besten Zugang für einen Client, der bei ISP2 steht. Mein Routing von ISP1 zu dieser IP-Adresse muss nicht optimal sein.

Wenn Sie einen Forwarder konfigurieren, dann sehen Sie aber die Optionen zur Reihenfolge:

Windows 2016 DNS-Server nutzt als Forwarder immer den ersten Server. Wenn dieser aber nicht mehr antwortet (Timeout ca. 4 Sekunden), dann wechselt der DNS-Server auf den den nächsten Eintrag und bleibt auch dabei. Er wechselt also nicht mehr zurück und verifiziert auch nicht mehr, ob der vorherige Server vielleicht wieder "online" ist.

Das ist wichtig, wenn Sie z.B. zwei primäre interne Server angeben und einen dritten Server als "Backup/Notfall"-System. Sollten nacheinander die beiden Hauptserver dann erst ausgefallen und wieder da sein, dann bleibt dennoch der dritte durchgelaufene DNS-Server nun aktiv.

Ein Failover zu einem anderen Forwarder passiert nur, wenn der gefragte Forwarder überhaupt nicht antwortet. Wenn ein Forwarder aber mit einem "Adresse nicht gefunden" antwortet, dann wird der eigene DNS-Server dies genauso an den Client weitergeben. Bei DNS-Server kommt aber RoundRobin zum Einsatz und sehr oft habe ich in Niederlassungen die folgende Konfiguration gefunden:

DNS1 = 192.168.3.3 (DNS-Server der Firmenzentrale)
DNS2 = ISP1DNS  (DNS-Server des Internet Serivce Provider)
DNS3 = 8.8.8.8  (Google DNS zur externen Auflösung)
DNS4 = 1.1.1.1  (Cloudflare DNS zur externen Auflösung)

Der Admin hatte wohl die Hoffnung, dass der DNS-Server nicht auflösbare Namen über die Zentrale auflöst und wenn dies nicht möglich ist, dann soll der DNS-Server des ISPs genutzt werden und als weitere Failover-Option eben Google. So funktioniert aber ein DNS-Server nicht. Wenn in dem Beispiel der 192.168.3.3 nicht erreichbar ist, dann fragt der DNS-Server den ISP und bleibt dabei, selbst wenn 192.168.3.3 wieder online wäre.

Alle Forwarder müssen daher immer auch das gleiche Wissen aber auch gleiche Performance haben. Es gibt hier kein "Überlauf" oder Fallback.

Eine Anfrage des Clients nach einem Namen einer Zone, die der DNS-Server selbst hostet, wird natürlich nicht zum Forwarder gesendet:

Name Server Ergebnis Ergebnis

Interner Name ohne lokale Zone

DNS1

OK

Forwarder sollte die korrekte Antwort liefern

Interner Name ohne lokale Zone

DNS2, DNS3, DNS4

Fehler

Kein DNS-Server im Internet wird hoffentlich ihre internen Server kennen. Sie antworten mit einem "Name not Found"

Externer Name

DNS1

Schlecht

Es hängt davon ab, ob der zentrale DNS-Server seinerseits eine Namensauflösung nach extern hinbekommt und dann eine Antwort liefert. Wenn aber z.B. ein Server in den USA den zentralen DNS-Server in Deutschland fragt, dann bekommt er mit Geo-DNS eine IP-Adresse aus Europe. Der USA-Client verbindet sich höchstwahrscheinlich mit dem weit entfernten Server und nicht einem geografisch näheren Server

Externer Name

DNS2

OK

Der Provider-DNS-Server wird die Anfrage entweder direkt aus seinem Cache oder über eine rekursive Anfrage auflösen und eine korrekte Antwort liefert, die auch unter Geo-DNS-Aspekten optimiert ist

Externer Name

DNS3, DNS4

Ja, aber

Der Provider-DNS-Server wird die Anfrage entweder direkt aus seinem Cache oder über eine rekursive Anfrage auflösen und eine Antwort liefert, die hoffentlich unter Geo-DNS-Aspekten passend ist. Sie ist aber nicht zwingend Provider-optimiert.

Nur in einem Fall schlägt die Auflösung komplett fehlt und in den anderen vier Fällen kommt zumindest eine Antwort. Aber nur wenn der DNS-Server die Root-Server oder entlang dem IP-Routing den Provider-DNS fragt, kommt sicher die korrekte Antwort zurück.

Delegation / selektive Forwarder

Neben den Standardauflösungen können mittlerweile wohl alle DNS-Server auch mit selektiven Forwardern arbeiten und Zonen delegieren. Relativ unbekannt ist die Funktion von Windows Clients, bestimmte DNS-Zonen zu abweichenden DNS-Servern zu senden. (Siehe Direct Access Namensauflösung - NRPT). Dies sind erweiterte Funktionen, wie Sie die Auflösung besonderer Namensräume gezielt steuern können. Sie könnten z.B. die standardmäßige Auflösung durchaus über Google, Cloudflare u.a. leiten, wenn Sie mit der "Erfassung ihrer Namen einverstanden sind und diese für die meisten Dienste tatsächlich eine sehr schnelle Antwortzeit und auch passende Gegenstelle liefern. Für bevorzugte Domains sollten Sie aber besser entweder direkt den Anbieter, die Root-Server oder ihren Provider fragen.

Wer Office 365/Microsoft 365 nutzt, kann dies ja auch die Domain "*.microsoft.com", "*.office.com","*.azure.com" beschränken. Wenn ihr Client oder DNS-Resolver diese Adressen nicht zu einem "fremden" DNS-Server außerhalb ihres IP-Routing sendet, kann der Anbieter anhand ihrer Quell-IP-Adresse eine optimierte Antwort liefern.

Diese Logik funktioniert auch für interne DNS-Domains, die Sie einfach immer zu ihren eigenen DNS-Servern leiten können. Dies ist insbesondere bei Split-VPN interessant, um "nicht interne" Adressen über den lokalen DNS-Service im Homeoffice aufzulösen während die Firmenadressen immer durch den Tunnel zu den privaten IP-Adressen der Firmen-DNS-Server geleitet werden.

Zusammenfassung

Achten Sie bei der Einrichtung von DNS immer genau darauf, dass ein Client erst dann den sekundären DNS-Server fragt, wenn der erste nicht mehr erreichbar ist und nicht wechselt, wenn der erste einfach ein "Name not Found" sendet. Bei DNS-Servern hingegen werden alle Forwarder im Wechsel gefragt und dann sollten alle eingetragenen DNS-Server auch die gleiche Information liefern können. Das ist eigentlich immer eine Grundregel:

Alle konfigurierten DNS-Server müssen das gleiche Wissen haben. Keine Anfrage wir an einen anderen Server gestellt, nur weil der vorherige ein "Name not Found" liefert sondern nur, wenn der vorige Server nicht antwortet.

Aber selbst wenn alle Server antworten liefern, gilt insbesondere für weltweit agierende Provider wie Microsoft, Google, Amazon, Zoom, Cisco u.a., dass es viele Gegenstellen gibt und sie per Geo-DNS und vielleicht auch AnyCast-IP einen netztechnisch in der Nähe liegenden Zugangspunkt auflösen sollten.

Was hilft ihnen die Aussage der Telefonauskunft einer anderen Stadt, wenn Sie ein lokales Restaurant oder Taxi-Unternehmen suchen?

Weitere Links