Dynamisches DNS

Dynamisches DNS, DDNS oder DynDNS (nicht zu verwechseln mit DynDNS von Dyn, Inc.) ist eine Technik, um Domains im Domain Name System (DNS) dynamisch zu aktualisieren. Der Zweck ist, dass ein Computer (bspw. ein PC oder ein Router) nach dem Wechsel seiner IP-Adresse automatisch und schnell den dazugehörigen Domaineintrag ändert. So ist der Rechner immer unter demselben Hostnamen erreichbar, auch wenn die aktuelle IP-Adresse für den Nutzer unbekannt ist.

Es sind zwei verschiedene Mechanismen verbreitet, die unterschiedlichen Anwendungsfällen entspringen. Zum einen kann die Aktualisierung über HTTP oder HTTPS erfolgen. Dies ist populär durch Anbieter wie z. B. DynDNS. Außerdem kann die Aktualisierung über ein an DNS angelehntes Nachrichtenprotokoll erfolgen. Dieses Protokoll ist in RFC 2136[1] und RFC 3007[2] spezifiziert und wird beispielsweise vom Programm nsupdate verwendet, welches Teil des weitverbreiteten Open-Source-DNS-Programmpaketes BIND ist.

DDNS über HTTP

Ein typischer Anwendungsfall für dynamisches DNS über HTTP oder HTTPS ist der Rechner eines Heimnutzers, der Zugang zum Internet über eine dynamische IP-Adresse des Internet Service Providers hat. Möchte der Nutzer zum Beispiel einen Gameserver betreiben oder per Remote-Desktop auf den Rechner von außen zugreifen, so müsste er die ständig wechselnde IP-Adresse kennen. Mit dynamischem DNS kann er stattdessen bei einem DDNS-Anbieter einen Domainnamen registrieren und dem Namen automatisch die jeweils aktuelle IP-Adresse zuweisen. Der Clou ist also, dass der Rechner/Router, der (z. B. vom Internet Service Provider) alle paar Stunden mit einer neuen IP-Adresse versorgt wird, sich regelmäßig selbständig bei einem DDNS-Anbieter meldet und die gerade aktuelle IP-Adresse bekannt gibt. Der DDNS-Anbieter wird so zu einem Referenzpunkt, bei dem man immer "nachschauen" kann, welche IP gerade aktuell ist.

Funktionsweise

Um einen DDNS-Eintrag beim Nameserver des Betreibers zu aktualisieren, kann entweder eine Client-Software auf dem Rechner installiert werden, oder eine entsprechende Funktion im Heimrouter genutzt werden. Sobald der Client eine geänderte IP-Adresse erkennt, übermittelt er diese über eine HTTP- oder HTTPS-Schnittstelle an den Anbieter. Die Authentifizierung erfolgt über Benutzername und Passwort. Die Implementierung eines Clients ist wenig aufwendig, da das Netzwerkprotokoll simpel ist und viele Software-Bibliotheken für HTTP/HTTPS-Verbindungen verfügbar sind.

Ständig wechselnde Einträge waren im Domain Name System ursprünglich nicht vorgesehen. Um Netzressourcen zu sparen, werden DNS-Einträge zwischengespeichert. Die Lebensdauer eines Eintrags (Time to Live) wird dabei vom Nameserver vorgegeben. Beim dynamischen DNS wird üblicherweise eine Time to Live von einer Minute verwendet, um kurzfristig vom DNS-Caching zu profitieren, ohne dass veraltete Einträge über einen längeren Zeitraum auf eine falsche IP-Adresse verweisen.

Einschränkungen

Wird ein Rechner heruntergefahren oder vom Netz getrennt, so bleibt seine IP-Adresse dem Domainnamen zugeordnet. Falls die IP-Adresse offline ist, führen Verbindungsversuche erst mit mehreren Sekunden Verzögerung zu einem Timeout-Fehler. Wurde die IP-Adresse zwischenzeitlich einem anderen ISP-Kunden zugeordnet, so könnte dieser versuchen, die Identität des vorherigen DDNS-Nutzers zu missbrauchen. Als Lösungsansatz kann ein Client bei einigen DDNS-Anbietern den Domainnamen beim Herunterfahren vorübergehend löschen. Ein anderer Ansatz ist die Verwendung von Heartbeats, um zu erkennen, sobald ein Rechner offline ist und dann den Domainnamen automatisch zu entfernen.

Dynamisches DNS ist kein vollwertiger Ersatz für eine statische IP-Adresse. Offene Netzwerkverbindungen bleiben bei der Trennung vom Internet oder beim Wechsel der IP-Adresse hängen und brechen nach einem Timeout zusammen. Innerhalb der Time to Live des DDNS-Eintrags kann die alte IP-Adresse zwischengespeichert sein, sodass keine neue Verbindung aufgebaut werden kann.

Durch unausgereifte DDNS-Client-Software kann es vorkommen, dass der DDNS-Eintrag über eine längere Zeit nicht aktualisiert wird. Dies geschieht zum Beispiel, wenn der Client nur einmal beim Einwählen den DDNS-Eintrag zu aktualisieren versucht, es jedoch bei einem vorübergehenden Fehler nicht erneut versucht. Auch der umgekehrte Fall kann problematisch sein: versucht ein Client die Aktualisierung häufiger als eigentlich nötig, so verstößt dies bei einigen DDNS-Anbietern gegen die Nutzungsbedingungen, was zur Sperrung des Benutzerkontos führen kann. Dies tritt zum Beispiel bei Heimroutern auf, die die zugewiesene IP-Adresse nicht speichern und daher bei jedem Neustart, zum Beispiel nach der Trennung vom Stromnetz, eine Aktualisierung senden. Wird vom ISP nach dem Neustart dieselbe IP-Adresse erneut zugeteilt, wird eine solche unnötige DDNS-Aktualisierung durchgeführt. Deshalb kann es mitunter sehr lange dauern, bis dieses Problem in Erscheinung tritt. Vom Router könnte dies aber dadurch verhindert werden, dass dieser vorher eine DNS-Abfrage für den zu aktualisierenden dynamischen Domainnamen durchführt und auf diese Weise die zuletzt verwendete IP-Adresse ermittelt.

DDNS über RFC 2136
1. Der Client fordert vom DHCP-Server eine IP-Adresse an.
2. Der DHCP-Server weist dem Client eine IP-Adresse zu.
3. Die IP-Adresse und der Hostname werden vom DHCP-Server dem DNS zur Registrierung übergeben.

RFC 2136[1] spezifiziert ein Verfahren für dynamisches DNS, das als DNS Update bekannt ist. Ein typischer Anwendungsfall für DNS-Update ist ein DHCP-Server, der nach der Vergabe einer IP-Adresse den Namen des Clients beim Nameserver im lokalen Netz registriert. DNS Update verwendet UDP oder TCP und das normale Nachrichtenformat im DNS, aber mit anderen Inhalten, was im Header angekündigt wird.[1]

Ein Nameserver, der einen Dynamic Update Request empfängt, speichert diesen zunächst ab, bevor er die Einträge in der Zonendatei modifiziert. Dadurch werden zum einen Inkonsistenzen beim Absturz des Servers vermieden, zum anderen können so Aktualisierungen zunächst gesammelt werden, wodurch der Durchsatz verbessert wird. Beim BIND-Nameserver wird dazu pro Zonendatei eine Journal-Datei angelegt, die eine ähnliche Funktion wie ein Journaling-Dateisystem hat. Die Sammelphase kann mehrere Minuten dauern, so dass dynamische Aktualisierungen nicht sofort an eventuell vorhandene Slave-Nameserver weitergegeben werden, die eine Kopie der Zonendatei vorhalten. DNS Update dient nur zum Ändern des Datenbestands auf dem Master-Nameserver. Um Änderungen an Slave-Nameserver zu übertragen, sollen die gebräuchlichen Mechanismen zum Zonentransfer verwendet werden.

RFC 2137[3] und die Neufassung RFC 3007[2] ergänzen DNS Update um Authentifizierung durch digitale Signaturen. Zur Wahl steht ein symmetrisches Kryptosystem, TSIG, bei dem beide Seiten den geheimen Schlüssel haben, und ein asymmetrisches Kryptosystem, SIG(0) nach RFC 2931,[4] bei dem der DNS-Server nur den öffentlichen Schlüssel und nur der DNS-Client den geheimen Schlüssel hat. Ohne zuverlässige Authentifizierung sind Nameserver mit Update-Funktion ein Sicherheitsrisiko, besonders im Internet.

Das Programm nsupdate, das Teil des BIND-Pakets ist, erlaubt Client-seitige Aktualisierungen von DNS-Einträgen. Zusätzlich besteht noch die Möglichkeit der Authentifizierung über TSIG oder SIG(0). Microsoft verwendet GSS-TSIG, eine TSIG-Variante, die Kerberos benutzt.

Einzelnachweise
  1. RFC 2136 – Dynamic Updates in the Domain Name System (DNS UPDATE). April 1997, S. 3 (englisch). “The Header Section specifies that this message is an UPDATE, … An update transaction may be carried in a UDP datagram, if the request fits, or in a TCP connection …. UPDATE uses the same fields, and the same section formats, but the naming and use of these sections differs …”
  2. RFC 3007 – Secure Domain Name System (DNS) Dynamic Update. November 2000 (englisch).
  3. RFC 2137 – Secure Domain Name System Dynamic Update. April 1997 (aktualisiert durch RFC 1035, englisch).
  4. RFC 2931 – DNS Request and Transaction Signatures ( SIG(0)s ). September 2000 (englisch).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.