DynDNS auf eigenen Server betreiben

Vor einiger Zeit hat der Dienst DynDNS, den ich lange Zeit genutzt habe, seine Allgemeinen Geschäftsbedingungen verändert. Die neuen Bedingungen sehen nur noch sehr eingeschränkten kostenlosen Zugang vor. Nun habe ich aber Zugriff auf einen Linux Root-Server im Internet. Entsprechend wollte ich probieren selbst einen entsprechenden Dienst als Alternative zu den kommerziellen Anbietern zu entwickeln. Natürlich nur für mich und mit entsprechend eher geringeren Sicherheitsanforderungen bzw. die Lösung muss nur für maximal 10 User entworfen sein. Für den Anfang begnüge ich mich sogar mit einen User. Wenn der Dienst stabil läuft wird das System entsprechend auf mehrere User erweitert. Dennoch bleibt die Lösung eine für den normalen Hausgebrauch.

Folgende Voraussetzungen sind nötig um so einen Dienst selbst aufzusetzen:

  • Zugriff auf einen Linux Server mit fester IP (im Text unten IPv4 1.1.1.1 und IPv6 fd12::1234)
  • Auf dem Server muss BIND verfügbar/installiert sein
  • Eine öffentliche Domain (im Text unten domain.de)
  • Zugriff auf die DNS Einstellungen dieser Domain inkl. der Möglichkeit einen NS Record anzulegen

Im Anschluss die einzelnen Schritte der Konfiguration des Servers.

Schritt 1 – Domain vorbereiten

Um mehrere DynDNS-Hosts verwalten zu können ist es als erstes notwendig eine Subdomain anzulegen in der diese Hosts zusammengefasst werden. DNS Anfragen die diese Subsdomain betreffen sollen von unserem Server beantwortet werden. Schließlich kennt nur der Server die jeweilige Zuordnung zwischen dynmischer IP-Adresse und festem Hostnamen. Entsprechend wird ein NS-Rekord angelegt. In meinem Fall habe ich diese Subdomain über das Webfrontend meines DNS-Hosters angelegt.

Mit den obigen Einstellungen für die Domain landen nun alle Anfragen die die Subdomain dyndns.domain.de betreffen bei unserem Server. Im nächsten Schritt müssen wir dafür sorgen, dass der Server sie auch beantworten kann.

Schritt 2 – Bind konfigurieren

Um dynamische Änderungen in einer DNS-Zone durchzuführen wird ein Key benötigt. Anhand diesem Key entscheidet BIND ob eine Update-Anfrage erlaubt ist oder nicht. Zuerst müssen wir also einen entsprechenden Key anlegen.

Der so erzeugte Key ist symmetrisch (sprich: Der Client der einen DNS Eintrag ändern will verwendet die gleiche Zeichenkette wie der verwaltende BIND Server). Zum Anzeigen des Keys reicht folgendes Kommando:

Im nächsten Schritt müssen wir auf unserem Server die DNS-Zone dyndns.domain.de anlegen und updates entsprechend mit dem obigen Key absichern. Dazu wird folgende Datei angelegt:

Nun muss die Zonen-Datei noch in die generelle BIND-Konfiguration eingefügt werden:

Damit ist die hälfte des Setups geschaft. Als nächsten Schritt brauchen wir ein Skript um die updates tatsächlich durchzuführen.

Schritt 3 – Update-Skript einrichten

Um DynDNS-Updates durchzuführen hab ich ein kleines PHP-Skript entwickelt. Es funktioniert bisher nur für einen Host und hat nur eine sehr rudimentäre Benutzerkontrolle. Für meinen kleinen Einsaztzweck ist es ausreichend. Es gibt aber durchaus Ideen wie es noch verbessert werden könnte (siehe auch die Gedanken am Ende von diesem Artikel).

Das Skript läuft bei mir auf einem Apache Webserver mit PHP Erweiterung. Es sollte aber auch jeder andere PHP-Fähige Webserver funktionieren.

Im letzten Schritt muss noch der Router konfiguriert werden.

Schritt 4 – Router einrichten

Bei mir steht eine Fritzbox als Internet-Router. Unter Freigaben befindet sich ein Punkt „Dynamic DNS“ der wie folgt auszufüllen ist:

Fritzbox DynDNS Freigabe

Fritzbox DynDNS Freigabe

Die Update-URL ist in dem Bild nicht ganz sichtar. Komplett lautet sie

  • http://dyndns.domain.net/ddns_update_stefan.php?username=&pass=&domain=&ip4=&ip6=

Wobei der letzte Teil „&ip6=“ weg gelassen werden kann wenn an dem Anschluss kein IPv6 verfügbar ist.

Weitere Punkte

Beim schreiben der obigen Anleitung hab ich folgende Quellen verwendet:

Im nächsten Schritt wird das PHP-Skript auf Mulituser-Unterstüzung erweitert. Das mache ich aber erst wenn ich wirklich konkreten Bedarf an weiteren dynamischen Hostnamen habe. Des weiteren wäre es vermutlich eine sehr gute Idee HTTPS statt HTTP zu verwenden und zu prüfen ob eine Authentifizierung per HTTP-AUTH möglich ist. Es gibt also durchaus noch Verbesserungspotential an dem fertigen Skript.