Dynamic DNS mit DJBDNS bei PING

Diese Seite beschreibt, wie man auf PINGs djbdns-Nameserver einen DNS-Namenseintrag (A-Record) für eine beliebige IP-Adresse vornehmen kann. Der Vorteil davon ist es, daß man so ständig wechselnde IPs unter immer demselben Hostnamen erreichen kann.

Wozu das alles?

Eigentlich ist die Namensvergabe für IP-Adressen die Aufgabe des Providers der IP-Adresse. Da aber nicht alle Provider die Möglichkeit einer statischen IP für ihre Kunden anbieten, bekommen die Kunden bei der Einwahl jeweils dynamisch eine IP zugewiesen, d. h. diese kann/wird sich von Einwahl zu Einwahl ändern. Manchmal wird die neue Einwahl ja auch erzwungen... (Wer hat da T-DSL gesagt? :-)

Auch der Namenseintrag fär die IP des sich einwählenden Hosts wird sich dabei jeweils ändern. Das jedoch hat ganz entscheidende Nachteile:

1. Wenn sich die IP nach der Neueinwahl geändert hat, können bestehende TCP/IP-Verbindungen nicht länger am Leben gehalten werden und müssen neu aufgebaut werden.
2. Wenn andere oder man selbst auf Dienste des sich einwählenden Hosts zugreifen wollen, haben sie Probleme die jeweils andere IP nach der erneuten Einwahl herauszufinden.
3. Sich IP-Adressen zu merken ist für Menschen schwer, vor allem wenn diese sich ständig ändern - Sich Namen zu merken, ist hingegen einfacher. Das ist die Rechtfertigung für die Existenz der DNS-Hierarchie an sich.
   Das ist aber bei so schönen Namen wie "pd90031ea.dip.t-dialin.net", "pD950A531.dip.t-dialin.net" oder "AC88AC44.ipt.aol.com" aus den dynamischen Einwahlpools vieler größerer Provider nicht mehr der Fall. Diese Namen bestehen sogar anteilig aus IP-Adressen in hexadezimaler Darstellung und man könnte sich ihre Eintragung im DNS eigentlich gleich sparen.

Gegen 1. läßt sich mit Namenseinträgen alleine nichts ausrichten, solange der Einwahl-Provider nicht garantiert, daß man seine vorherige IP wiedererhält, wenn man z. B. innerhalb einer bestimmten Zeitspanne erneut einwählt. (Bei PING ist das z. B. der Fall, zumal die Möglichkeit besteht, eine statische IP zu erhalten.)

Gegen 2. und 3. ist dagegen ein (Un-)kraut gewachsen: Genau wie die IP-Adressen bei der Einwahl bei einem Provider dynamisch vergeben werden, könnte man auch DNS-Einträge für diese IPs dynamisch vergeben!

Dynamic DNS

Damit das auch wie gewünscht, funktioniert, ist es notwendig, einige Optimierungen des DNS auszuhebeln, die auf den Vorraussetzungen beruhen, daß sich IP-Adressen nur sehr selten ändern und eine Änderung in einer Übergangsphase langsam geschehen kann.

Da DNS eine verteilte, hierarchische Datenbank ist, die nach den Prinzipien Authority und Delegation funktioniert, sollte jeder Nameserver wissen, worüber er mit Autorität Auskunft geben kann und falls er das nicht kann, welcher Nameserver es sonst kann oder weiß, wer es kann usw. rekursiv. Ein Client eines nicht zuständigen Nameservers wird so an den zuständigen Nameserver weitergeleitet.

Weil es sehr wahrscheinlich ist, daß eine Nameserver zeitnah die gleiche oder eine ähnliche Adresse auflösen muß, wurde dieses Verfahren bei Anwachsen der DNS-Hierarchie optimiert, indem jeder DNS-Eintrag mit einer Zeitmarke versehen wurde, wie lange er gültig sein soll (TTL). So ist es für einen Nameserver möglich, Einträge, nach denen er gefragt wurde, in einem Cache abzuspeichern, so daß er bei der nächsten Anfrage nach demselben Eintrag gleich selbst antworten kann, ohne die gesamte Hierarchie erneut durchzugehen.

Da übliche TTL-Werte einige Tage betragen, dauert es auch so lange, bis Änderungen zu allen Nameservern propagiert werden: Erst wenn ein gecachter Eintrag abgelaufen (expired) ist, wird der Nameserver bei einer erneuten Anfrage wieder einen Nameserver mit Autorität befragen. Das ist natürlich für sich ständig ändernde IP-Adressen völlig ungeeignet!

Stattdessen kann man den TTL-Wert auf sehr kleine Werte oder Null setzen, so daß sie nicht oder nicht mehr sehr lange im Cache gehalten werden. Der Nachteil ist eine erhöhte Belastung für das DNS-System, das jetzt entlang eines Hierarchiepfades mehr Anfragen bearbeiten muß, als wenn einige davon direkt aus den Nameserver Caches beantwortet werden könnten.

Dynamic DNS in der Subdomain dyna.ping.de

Trotz des oben geschilderten Nachteils durch weniger Cache Hits, habe ich ein Client-Server-System gebastelt, daß es jedem Mitglied ermöglicht von PING ermöglicht, dynamische DNS-Einträge unter einer Subdomain "dyna.ping.de" vorzunehmen. Wenn jemand (z. B. ich selbst) die Site "nixe" besitzt, kann er eine beliebige IP-Adresse unter "nixe.dyna.ping.de" erreichen. Die TTL ist im Moment fest auf eine Minute eingestellt, d. h. nach spätestens einer Minute sollte die neue IP für euren A-Record propagiert worden sein.

Benötigt wird der Client dyna_client, den man sich von meiner Homepage herunterladen kann. Die Module Digest::MD5 und Digest::SHA1, der eigene Sitename und das PING Admin Passwort der eigenen Site werden ebenfalls benötigt. Für den Namen "nixe.dyna.ping.de" und die IP-Adresse 3.141.59.26 lautet der Aufruf so:

 dyna_client nixe supergeheim 3.141.59.26

Wenn man den Client von dem entsprechenden Host bzw. einem Host hinter einem maskierenden Host seines LANs aufruft, kann man auch "local" statt der IP angeben:

 dyna_client nixe supergeheim local

Der Server, der auf Port 5353 von "lilly.ping.de" lauscht, verwendet dann die IP-Adresse, von der die Verbindung kam, für den A-Record.

Wenn man den A-Record wieder löschen will, kann man dyna_client so aufrufen:

 dyna_client nixe supergeheim 0.0.0.0

/usr/local/bin/dyna_client nixe supergeheim local

Vielleicht noch offene Fragen:

Hilfe! Ich kann doch nicht einfach mein Passwort über feindliche Netzwerke verschicken!

Stimmt. Darum implementieren dyna_client und dyna_server ein Challenge Response-Protokoll, d. h. das Passwort wird nicht übertragen, sondern nur durch Kryptographische Hashfunktionen erzeugte digitale Signaturen des Passwortes und anderer Werte:

Server -> Client: CHA=[168bit Number]
Client -> Server: RES=sha1,sha1(sha1,SITE,PASS,CHA,IPAD),SITE,IPAD
Server -> ACK|NAK

Zur Zeit werden nur MD5 (128-bit) und SHA1 (168-bit) unterstützt, Default ist die längere SHA1-Hashfunktion. Durch das Protokoll werden auch Replay-Attacken verhindert, falls jemand die Verbindung belauschen sollte.

Toll. Läuft aber wahrscheinlich nicht unter M-Betriebssystemen.

Jein. Obwohl ich natürlich unter Linux entwickelt habe, lief der Client ohne weitere Anpassungen z. B. unter Windows. Wenn man sich Active Perl von www.activestate.com herunterlädt und den Anweisungen dort folgt und es installiert, kann man mit perl im Pfad jeweils "perl dyna_client ..." aufrufen. Die Digest-Module muß man sich nicht selbst herunterladen, sie sind in dem Paket von Active State schon enthalten.

Ich bin leider ignorant, wie man unter Windows, automatisch ein bestimmtes Programm nach der PPP-Einwahl startet. Falls jemand dazu etwas weiß und es hier stehen soll, soll er bitte ein kurze Mail an mich schreiben. Alles andere verhält sich genauso, wie oben erklärt.

Downloads

• Das dyna_client Script gibt es auf meiner Homepage zum Herunterladen.
• Die Digest-Module:
  • Digest::MD5 und
  • Digest::SHA1.
  
  
• Die Perl Distribution von Active State: Active Perl.