Geo-DNS / Pinpoint DNS

Hinweis:
Diese Seite dürfte ziemlich irrelevant sein, wenn sie genau einen Standort haben oder Server nicht geografisch verteilt sind. Wir sprechen also wirklich hier von "großen" Firmen mit mehreren Rechenzentren in den Regionen der Welt, bei denen Nähe zu Services relevant ist.

Diese Seite beleuchtet etwas genauer die Möglichkeiten durch DNS-Besonderheiten die Zugriffe von Clients gezielt zu lenken. Vielleicht haben Sie technisch noch nicht genauer nachgeschaut aber im Internet ist es bewährte Praxis über "Geo-DNS"-Funktionen die Clients an einen netztechnisch "naheliegenden" Server zu leiten. Stellen Sie sich vor große Seiten wie Google.com oder youtube.com wären an einer Stelle gehostet und alle Zugriffe aus der Welt würden zentralisiert bedient. Undenkbar und auch uneffektiv.

Wege zur Optimierung

Wenn man aber nun die Server und die Daten geografisch verteilt, dann bleibt dennoch die Frage, wie man die Anwender auf das richtige Ziel lenkt. Denn eine Verteilung der Daten durch Replikation ist eher einfach. Viele Webinhalte sind ja doch statisch, so dass diese recht einfach verteilt werden können. Hier ein paar Optionen, mit denen man Clients auf lokale Server lotsen kann:

  • Länderdomänen
    Warum auf google.com gehen, wenn man auf google.de die gleichen Informationen sogar in der eigenen Sprache finden kann ?. Länderdomänen sind tatsächlich ein einfacher Weg, Kunden von hochfrequentierten Seiten auf eine lokale Seiten zu leiten. Selbst wenn der erste Zugriff auf
    Es kostet allerdings einige DNS-Domänen, die alle zu kaufen und zu pflegen sind. Und nicht in jedem Land will man vielleicht Server aufbauen von den SSL-Zertifikaten gar nicht zu sprechen.
  • Redirect auf andere FQDNs
    Ein weiterer praktikabler Weg besteht darin, den ersten zugriff weiter auf einer zentralen Site zu erhalten, aber dann entweder nur die Inhalte z.B. von einer Subsite (de.example.com) zu beziehen. In die HTML-Seite müssen also dynamisch von der Source-IP des Clients andere Referenzen zu Bildern, Videos, CSS und Skripten gelegt werden. Oder der Client wird komplett auf die andere Site umgelenkt. Übrigens machen auch Exchange und Lync von dieser Möglichkeit gebrauch. Wenn sich ein Client mit dem "falschen" Server verbindet, dann wird er zum richtigen Server gesendet.
    Allerdings muss eben der zentrale Server erreichbar sein.
  • optimierte DNS-Antworten
    Wenn Sie aber schon den ersten Zugriff optimieren wollen, dann geht dies nur durch entsprechende Antworten auf die DNS-Anfragen. Und tatsächlich gibt es DNS-Server, die abhängig von der Client-IP eine passende Adresse zurück geben. Dazu muss der DNS-Server natürlich eine Zuordnung von Client Netzwerken zu den Servern vornehmen. Idealerweise weiß der DNS-Server auch noch, dass der ausgegebene Dienst verfügbar ist zu dem er den Client dann sendet. So könnten DNS-Antworten auch ein Teil einer Verfügbarkeitsstrategie sein. Allerdings ist dies mit Vorsicht zu genießen, zumindest solange DNS-Antworten länger im Cache gehalten werden. Ein DNS-TTL von einigen Stunden hilft hier also nicht.
  • Proxy und Cache
    Auch die Zugangsprovider können Hilfsmittel einsetzen, um die Datenmengen zu mindern. Dazu zählen zuerst natürlich Proxy-Server, die zwischen Client und Zielsystem freiwillig oder erzwungen geschaltet werden können. in Firmen kann das natürlich einfach auf dem Client konfiguriert werden. So ein Proxy kann zudem auch Malware filtern und die Authentifizierung durchführen. Aber auch Provider können z.B. HTTP-Anfragen erkennen und über einen Proxy leiten, selbst wenn der Client davon gar nichts merkt. Solange der Verkehr unverschlüsselt ist, ist das eine gängige Praxis und hat auch nichts negatives. Bei HTTPS geht dies natürlich zumindest im öffentlichen Internet nicht mehr. Bei Firmen hingegen können entsprechende Proxies auch in HTTPS-Traffic schauen. Ein Caching kann hier also auch den Webserver und WAN-Leitungen entlasten.

Vielleicht fragen Sie sich nun, warum ich ihnen das alles aufzähle. Bei den verschiedenen Optionen ist eine Option dabei, die durchaus interessante Aspekte für den internen Gebrauch aufzeigen kann.

DNS, Zonen und Replikation

Ohne alles von der Pike auf erklären zu müssen sollten wir ein paar Grundbegriffe wiederholen:

  • DNS-Zone
    Darunter verstehe ich im UNIX-Bereich eine "Datei", in der die komplette Zoneninformationen abgespeichert ist. Wird gerne mit der "Domäne" verwechselt. Bei AD-Integrierten Zonen ist es natürlich keine Datei
  • DNS-Domäne
    Dies ist ein Teilbaum in einer Zone. Wenn also die Zone "msxfaq.de" heißt, dann kann ich darin quasi einen "Ordner" anlegen. "test.netatwork.de" wäre so eine DNS-Domain, die weitere Hosts enthalten kann.
  • Replikation
    Im klassischen Primary/Secondary-Konzept wird immer die komplette Zonendatei repliziert.
  • Pinpoint-Zone
    Auch wenn es eine Zone "msfaq.de" gibt, habe ich die Wahl, ob ich z.B.: eine TestUmgebung als Domäne "test.msxfaq.de" in der Zone "msxfaq.de" anlege oder ob ich eine eigene Zone "test.msxfaq.de" anlege. Eine eigene Zone hat den Vorteil, dass ich andere DNS-Server zur Bereitstellung definieren kann.
  • Delegation
    Wenn man eine Zone unterhalb einer anderen Zone anlegt, dann sollte man auch die Verbindung von der darüber liegenden Hierarchie zur neuen unterzone bauen. Das Konzept ist Standard, dass z.B. beim DENIC, welches die Zone "de." hostet, natürlich keine Kopie der "msxfaq.de"-Zone liegt aber ein Stub-Eintrag vorhanden ist, der Anfragen zum DNS-Server meines Providers weiter leitet. Der hat dann die Zone für "msxfaq"
  • Forwarder und Referral
    Die Delegation ist eine besondere Art des Referral, bei dem eine anfragender Client zu einem anderen DNS-Server geleitet wird. Der Client muss aber selbst anfragen. Anders ist es, wenn ein DNS-Server als Forwarder agiert und eine Anfrage, die er nicht selbst aus lokalen Informationen beantworten kann, an andere Server weiter leitet. Auch dies ist eine gängige Konfiguration, wenn z.B.: interne Clients einen internen DNS-Server fragen um externe Namen aufzulösen. So erspart man sich die Regel, dass alle Clients ANY:53/UDP erreichen müssen.

Hier einmal als Muster:

Das DENIC als Hoheit über den Namensraum "DE" betreibt (Stand 25. Apr 2013) 5 DNS-Server, die die Zone "de." bereit stellen. In der Zone gibt es ganz sicher einen Eintrag, der "msxfaq.de" auf die DNS-Server von Schlund (mein Provider) delegiert. Wenn also ein Client über seinen Zugangsprovider letztlich beim DeNic landet, wird der anfragende Client an die beiden Nameserver ns7.schlund.de und ns8.schlund.de verwiesen. Das DeNic macht in der Regel keinen "Forward" um die Antwort selbst zu liefern. Der Provider fragt dann den Hosting Provider und bekommt die Antwort. der Hosting Provider stellt die Zone in der Regel auf mehr als einem DNS-Server bereit und repliziert die Daten zwischen den Servern oder nutzt einen anderen Provisioning-Prozess.

Als Firma betreibe ich in dem Beispiel meine eigenen internen DNS-Server die direkt oder über ein DNS-Forwarder in der DMZ z.B.: meinen Provider als "Forwarder" nutzen. So können interne System auch externe Namen auflösen

Es gibt Firmen, die eine solche externe Auflösung nicht zulassen. Ein Schutz ist das nicht, da jemand natürlich mit der IP-Adresse und HOSTS-Einträgen immer noch die Server erreichen könnte. Wer einen Zugriff unterbinden will, sollte dies auf der Firewall aktiv tun. Übertragen aus das Telefon: Ich nehme ihnen das Telefonbuch weg, damit sie nicht ins Amt telefonieren. Da würden Sie auch den Kopf schütteln. Allerdings sollte eine Firewall auch die DNS-Anfragen prüfen, nicht dass jemand über den DNS-Kanal einen "Tunnel" aufbaut, was durchaus möglich ist.

In der internen Zone "msxfaq.local" habe ich aber noch eine Domäne angelegt, weil ich eine Spiel und TestUmgebung "test.msxfaq.local" betreibe. Das ist aber im gleichen Zonen-File und auch Bestandteil der Replikation und auf allen DNS-Servern vorhanden. Da komme ich später noch mal drauf zurück.

Zudem habe ich eine violette Zone angelegt, die ich als "Pinpoint"-Zone bezeichne. Es ist eine ganz normale Zone, nur dass Sie quasi ein Stück aus der offiziellen "msxfaq.de" heraus schneidet. Genau genommen ist jede Zone so eine Sonderform, denn die Zone "msxfaq.de" beim Hostingprovider ist ja auch aus Sich der "DE."-Zone eine Teilmenge. Der unterschied hierbei ist, dass in der Zone nun keine weiteren Hosts gepflegt werden, sondern dass die Zone quasi einen Hostnamen darstellt. Ich kann so einen einzelnen Host abweichend von der Default Zone konfigurieren. Ich muss also nicht wie beim klassischen Split-DNS intern manuell eine Kopie der offiziellen Zone pflegen. 

Lokale DNS Antworten von Windows

Unser Ziel dieser Seite sind aber nun Ortsoptimierte Antworten eines DNS-Servers auf die Anfragen eines Clients. Wenn Sie also z.B. die Anfrage "autodiscover.<maildomain>" an einen lokalen Exchange Server, dann ist das mit dem klassischen Bild nicht möglich. Folgende passiert:

  1. Der Client bekommt per DHCP eine IP-Adresse und einen DNS-Server zugewiesen
    Hier ist es noch einfach, dass der Client einen "netznahen" DNS-Server fragt. Die Zuweisung kann pro DHCP-Subnetz getrennt erfolgen, so dass der Client immer einen "lokalen" DNS-Server bekommt.
  2. Autodiscover-Suche
    Z.B. Durch einen Start von Outlook wird der Client nach "autodiscover" suchen und dabei vom DNS-Server beide Adressen des Exchange Server bekommen. Schließlich möchte man ja verfügbar sein. Die meisten DNS-Server liefern nun die beiden IP-Adressen immer im wechsel aus, so dass hier mit zwei Standorten eine 50% Wahrscheinlichkeit besteht, dass der Client die Autodiscover-Verbindung zum entfernten ungünstigen Standort aufbaut.

Das möchte man gerne vermeiden.

Übrigens ist das beim Active Directory mit den Anfragen ach _gc._tcp.<dnsdomain> auch so, dass der Client quasi alle IP-Adressen aller DCs der Domäne bekommt. Allerdings ist der Windows Active Directory Client dann so programmiert, dass er alle Server per ICMP anpingt und den DC für die initiale Verbindung nutzt, der zuerst auf den PING geantwortet hat. So löst der Client elegant das Problem, einen "nahen" DC zu nutzen, der auch zumindest per ICMP (PING) erreichbar ist. Nur ungeschickt, wenn ein voreiliger Firewall-Admin ein ICMP-Ping blockiert

Ab er nicht umsonst habe habe ich noch einen Client2 in das Bild eingebaut, der in einem anderen Subnetz hängt. Denn Windows DNS-Server sind durchaus in der Lage, bei der Antwort eine Präferenz zu liefern. Der DNS-Server "sieht" in der Anfrage ja nur die IP-Adresse des Clients. Ehe der DNS-Server die Antwort ausliefert, prüft er die IP-Adressen in der Antwort ab und sortiert diese gegebenenfalls um. Ein Client bekommt daher immer die IP-Adresse zuerst, die im gleichen Subnetz wie der Client ist. Das funktioniert natürlich nur, wenn der Service und der Client im gleichen Subnetz sind. So ist aber zumindest in kleinen Standorten die Wahrscheinlichkeit groß, dass ein Client "lokal" bleibt. Dies ist aber keine Lösung für Firmen, bei denen die Clients in anderen Subnetzen als die Server sind, so dass diese Übereinstellung nicht zum Tragen kommt. Es ist ebenfalls nicht nutzbar, wenn der DNS-Server keine Informationen über die Subnetzmaske hat. Wenn also Service und Client in einem 10.x.x.x Netzwerk sind, die aber als Netmask 255.255.255.0 nutzen, dann sind sie aus Sicht des DNS-Servers immer noch im "gleichen Subnetz". Da hilft es auch nicht, wenn ich im Beispiel 10.49.x.x. für Deutschland und 10.1.x.x für USA vorgesehen habe.

Tricksen mit Pinpoint DNS

Und das ist nun die Change, mit einer PinPoint-Zone für diese Einträge zu arbeiten. Das folgende Bild soll es deutlich machen. Hier habe ich nun einfach eine Zone "autodiscover.msxfaq.de" angelegt, die aber nicht klassische "Active Directory integriert" ist, sondern einfach eine normale "primäre Zone" ist. Das ist aber nicht schlimm, da sie sowieso nur statisch gepflegt wird und keine dynamischen Updates benötigt. Insofern sind auch keine Berechtigungen hierfür erforderlich.

Sollte es in der jeweiligen geografischen Region weitere DNS-Server geben, so kann diese Zone dort ebenfalls als "Sekundäre Zone" eingerichtet werden und so entsprechend verfügbar gestaltet werden. Über DHCP wird der Client natürlich zu einem "nahen" DNS-Server geführt der dann in seiner standortbezogenen Zone für Autodiscover einen nahen Exchange Server liefern wird.

Die Lösung klingt nicht schlecht aber was ist das Problem ?

  • Komplett
    Durch das Ausklammern von "autodiscover" aus der normalen Zone ist in der normalen Zone der Eintrag nicht mehr vorhanden. Sie müssen also selbst dafür sorgen, dass ALLE DNS-Server auch eine Pinpoint-Zone mit passendem Inhalt bekommen.
  • "Ungewöhnliche Konfiguration" = Dran Denken
    Diese Konfiguration ist nicht sehr "geläufig". Gehen Sie also nicht davon aus, dass Dienstleister, Supporter etc. diese "kennen" und damit umgehen können. Insbesondere bei umbauten im Bereich Exchange (bezogen auf Autodiscover) müssen Sie die Einträge dann in allen Zonen entsprechend anpassen.
  • SRV-Records
    Aktuell erlaubt die Windows DNS-Management Console nicht, einen SRV-Record ohne Hostnamen einzutragen. Technisch ist es erlaubt aber die GUI blockiert. Tragen Sie einfach einen beliebigen Namen mit ein. Danach stoppen Sie die Zone und editieren die Textdatei manuell mit Notepad. Der DNS-Server kann die Datei problemlos dann wieder lesen und liefert SRV-Records aus. Oder sie nutzen gleich die Kommandozeile
dnscmd . /zoneadd sip.msxfaq.de. /dsprimary
dnscmd . /recordadd sip.msxfaq.de.com. @ A 10.49.0.1
dnscmd . /zoneadd _sipinternaltls._tcp.msxfaq.de. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.msxfaq.de. @ SRV 0 0 5061 sip.msxfaq.de.
  • Komplexität
    Es gibt sehr viele DNS-Namen, die geografisch optimiert werden können. Wenn Sie für all diese die Funktion umsetzen wollen, dann werden das unter umständen sehr viele Zonen.

Wenn Sie nun immer noch glauben, dass ihre Firma groß genug ist, diese Besonderheiten berücksichtigen zu müssen, dann könnte dies eine Lösung sein. es ist aber nicht die einzige Variante. Sie könnten natürlich auch einen anderen DNS-Server einsetzen, der direkt Antworten anhand der IP-Adresse des Clients liefern kann.

DNS Pinpoint und Exchange

Eigentlich muss man für Exchange nicht mit Pinpoint-DNS arbeiten, da Outlook intern per LDAP den Service Connection Point findet und nur von Extern nach "autodiscover.<smtpdomain>" sucht. Aber es gibt ja auch Lync Clients und andere Systeme, die nicht Mitglied der Domäne sind und daher auch von intern nach "autodiscover.<smtpdomain>" suchen. Hier hilft dann eine PinPoint-Zone für diesen Namen, um die Anfragen von innen auch intern an die CAS-Server zu leiten statt sie über den Proxy zum Internet wieder zurück zu bekommen.

Mit Outlook und Exchange 2013 RTM gibt es aber noch einen zweiten Grund. Hier gibt es einen Bug, dass Exchange per Autodiscover die internal und External-URLs zurück liefert. Mit Exchange 2013 muss Outlook aber immer RPC/HTTP nutzen, da Exchange 2013 kein RPC/TCP mehr unterstützt. Bis Exchange 2010 ist das Problem niemandem aufgefallen, da Outlook intern TCP genutzt at. Mit Exchange 2013 und RPC/HTTP-Only überspringt Outlook 2007/2010/2013 aber den ersten Block und versucht stattdessen die externe Adresse zu erreichen.

  • 2839517 Outlook is unable to connect to Exchange 2013 public folder or auto mapped mailbox

Als Workaround könnten Sie nun eine HOSTS-Datei auf jedem Client pflegen, so dass der Zugriff auf den externen Namen auch auf die internen CAS-Server geht. Allerdings würde das auch den Zugriff aus dem Internet blockieren. Gesucht wird also eine Auflösung eines externen Hostnamens auf die internen CAS-Adresse, die aber nicht den externen Einsatz unterbindet. Genau das ist ein weiterer Einsatzzweck für PinpointDNS-Zonen.

DNS Pinpoint und Lync

Für Exchange habe ich oben am Beispiel "Autodiscover" schon die entsprechenden Beschreibungen geliefert. Lync muss dem nicht nachstehen. Hier gibt es sogar mehrere Einträge, die eigentlich "global" für die SIP-Domäne sind aber mehrere Einträge enthalten können.

  • _sipinternaltls._tcp.<sipdomain>
  • lyncdiscover.<sipdomain>
  • lyncdiscoverinternal.<sipdomain>
  • join.<sipdomain>

Clients, die nicht per Gruppenrichtlinie direkt auf "ihren" Poolserver eingestellt werden, nutzen diese (und andere) DNS-Einträge um den Weg zu einem funktionierenden Pool oder Director zu finden. Wer nun auch hier mehrere Server in verschiedenen Pools über die Welt verteilt, der kann über Pinpoint-DNS die Anfragen der "Autokonfiguration-Clients"

Ein Nebeneffekt bei der gezielten Antwort auf die "_sipinternaltls._tcp"-Anfragen ist natürlich, dass die Clients immer gleich bei einem geografisch nahestehenden Pool landen. Mal abgesehen von den umherreisenden Mitarbeitern dürften die meisten Anwender damit auch immer an ihrem "Homepool" landen und werden maximal noch auf den jeweiligen Homeserver innerhalb des Pools verwiesen. Wenn nicht noch andere Faktoren dazu kommen, ist hierfür ein Lync Director nicht mehr erforderlich.

3rd Party DNS Hosting

Nun könnten Sie ja die Technik auch im Internet nutzen. Stellen Sie sich vor sie betreiben eine Webseite an mehreren Standorten und möchten die Clients immer zum "naheliegenden" Server leiten. Auch das ist möglich, Sie müssen aber im Internet einen DNS-Provider finden, der z.B. Abhängig von dem Quell-Land die richtige DNS-Antwort liefert. Und sie müssen natürlich auch mindestens zwei Dienste in unterschiedlichen Regionen betreiben.

Aber genau das macht z.B. auch Office 365. Die Office 365 Namen sind weltweit immer die gleichen Namen, egal ob ihr Tenant und in Europa, Asien oder Amerika liegt. ,Aber abhängig von ihrem Standort werden Sie per DNS zu dem nächsten Übergang in das Microsoft Delivery Network geleitet, so dass die Daten einen möglichst kurzen Weg über das nicht QoS-Gesicherte Internet laufen und möglichst schnell nach "innen" kommen, wo sie dann quasi über eine private Weitverkehrsverbindung geroutet werden.

Weitere Links