Benutzer:Apc00-tony/Dynamisches DNS
Update 2023: Ich habe die Verwaltung über Befehlszeile durch eine PHP-Web-Oberfläche ersetzt; Details irgendwo ... ah, hier. Meine Hostsharing-DDNS-Lösung läuft übrigens schon lange einwandfrei; ich benutze sie dazu, ein VPN zwischen meinen Fritz!Box-LANS zu Hause und im Büro zu realisieren sowie um auf ein Backup- und Music-Server (ein Raspberry Pi) zu Hause von unterwegs zuzugreifen.
((Provisorischer Vorspann: Auf Grund einer Mailing-Listen-Diskussion habe ich angefangen, Dynamisches DNS über einen CGI-Skript bei Hostsharing zu realisieren. Meine Lösung habe ich dann vorgestellt; sie wurde für nicht ausreichend selbsterklärend befunden und fand wenig Akzeptanz. Hier also der Versuch, die Sache zu dokumentieren.))
Mit der regelmäßigen Aufnahme von benutzerspezifischen Zonefiles in seiner DNS-Konfiguration bietet Hostsharing alles, was man braucht, um „dynamisches DNS“ in Eigenregie zu realisieren.
Das heißt, wenn ich mindestens eine Domain bei Hostsharing verwalte, und mindestens eine Einwahlverbindung (oder DSL-Verbindung) ins Internet mit wechselnder IP-Adresse über irgendeinen ISP für meinen Arbeitsplatzrechner zu Hause betreibe, dann kann ich dem Arbeitsplatzrechner über die DNS-Server von Hostsharing einen vollqualifizieren Domainnamen zuweisen, der der jeweiligen IP-Adresse meiner Einwahlleitung zugeordnet ist.
(ASCII-Art-Diagramm der beschriebenen Konstellation)
Im Folgenden wird eine real existierende Implementierung von Dynamischem DNS („DDNS“) beschrieben. Die verschiedenen Elemente könnten durchaus anders realisiert werden; die beschriebene Implementierung könnte durchaus verbessert werden. Sie dient hier der Illustration.
In der folgenden Beschreibung werden diese Beispielwerte benutzt:
- Ein Hostsharing-Mitglied hat ein Account als Paket-Admin mit Kennung xyz00.
- Im Paket xyz00 gibt es einen Domain-Admin namens xyz00-benutzername.
- Dieser Domain-Admin verwaltet bei Hostsharing die Domains example.com und beispiel.de.
- Ein Benutzer hat zu Hause (oder im Büro) einen Arbeitsplatzrechner hinter der marktüblichen DSL-Leitung, die von seinem ISP bereitgestellt wird.
- Dieser Arbeitsplatzrechner (oder der Router, der seine Internetverbindung steuert) bekommt vom ISP immer wechselnde IP-Adressen zugewiesen.
- Dennoch möchte der Benutzer seinen Arbeitsplatzrechner aus dem Internet unter dem Hostnamen einwahl.example.com ansprechen können.
Dazu kann ein System wie Hostsharing, das authoritative DNS-Informationen für viele Domains bereitstellt, auch veränderliche DNS-Information über dynamisch verbundene Rechner verwalten – sofern das ressourcenschonend gemacht werden kann ohne andere Funktionen zu stören.
Aufgaben des Servers
Um einem Rechner mit wechselnder IP-Adresse einen DDNS-Eintrag zu bieten, muß der Hostsharing-Server folgendes leisten (in ungefährer Reihenfolge der Ereignisse):
- Eine Anfrage entgegennehmen, beispielsweise über HTTPS, von einem entfernten Rechner, der einen DNS-Eintrag für seine momentane IP-Adresse wünscht.
- Prüfen, ob die Anfrage einen berechtigten DDNS-Dienst-Usernamen mit zugehörigem Paßwort enthält.
- Prüfen, ob die Anfrage einen gültigen Domainnamen betrifft, den der Server bieten darf.
- Prüfen, ob die Domain example.com demselben Benutzer gehört, unter dessen Namen der Dynamisches-DNS-Server läuft.
- Eine gültige Zonefile mit – neben dem bisherigen Inhalt – einem A-Eintrag für einwahl.example.com in /home/pacs/xyz00/users/benutzername/doms/example.com/pri.example.com schreiben.
- Dem Client eine Bestätigung oder ggf. eine Fehlermeldung als Antwort senden.
- In irgendeiner Datenbank den momentan eingestellter Status all seiner DDNS-Einträge speichern.
- In einer Logdatei protokollieren, daß obiges getan wurde, oder ggf. welche Fehler traten auf.
Aufgaben des Clients
Bevor ich anfange, meinen Arbeitsplatzrechner so zu konfigurieren, daß er bei welchem Server auch immer einen DDNS-Eintrag anfordert, muß ich mich als verantwortlicher Benutzer dieses Rechners und der dazugehörigen Internetverbindung – das heißt, als Mensch – mit dem Betreiber des dynamisches-DNS-Servers vereinbaren, daß ich das darf und welchen Eintrag ich bekommen kann. Im Folgenden wird vorausgesetzt, daß solche Vereinbarungen getroffen und die Parameter geklärt wurden.
Der DDNS-Client muß aus Server-Sicht nur wenig leisten:
- Eine Anfrage senden, beispielsweise über HTTPS, an einen entfernten Rechner, der einen Eintrag ins DNS für die momentane IP-Adresse des Clients vornehmen kann.
Diese Anfrage muß einem festgelegten Format entsprechen und muß gültige Werte für die Authorisation des Clients, den gewünschten Domainnamen, und eventuell andere Parameter enthalten. - Eine Antwort des Servers entgegennehmen und als Erfolgs- oder Fehlermeldung auswerten.
- Von überflüssigen Anfragen absehen: das heißt bei Erfolg, nicht wiederholt den gleichen Eintrag erneut wünschen; bei Fehlern, nicht die gleiche fehlerhafte Anfrage erneut schicken.
Kommunikation zwischen Client und Server
Ein einziges Nachrichtenpaar von Anfrage und Antwort genügt, um einen DDNS-Eintrag einzurichten: Der Client teilt die IP-Adresse und den Domainnamen mit, die in einem DNS-Eintrag verbunden werden sollen; der Server bestätigt den Auftrag.
In der Beispielimplementierung erfolgt die Kommunikation über HTTP, und die Anfrage des Clients könnte so aussehen:
GET /cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21 HTTP/1.1 Host: ddns.beispiel.de User-Agent: Fritz!Box DDNS/1.0.1 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Bei Erhalt dieser Anfrage ruft Apache das CGI-Programm .../doms/ddns.beispiel.de/cgi-ssl/ddns auf. Das Fragezeichen trennt den Programmnamen von einem "Query-String", in dem zwei Metavariablen definiert und übergeben werden. Die erste Metavariable, hostname, hat den Wert "einwahl.example.com"; die zweite, myip, hat den Wert "87.65.43.21".
Das Server-Programm, hier ddns, prüft diese Informationen auf Form und Berechtigung, und schreibt gegebenenfalls einen entsprechenden Eintrag in einer Zonefile. Es schreibt auch verschiedene Informationen in die Standardausgabe. Wenn es die Standardausgabe geschlossen wird – also spätestens bei Programmende – schickt Apache diese Informationen als Antwort an den anfragenden Rechner zurück.
Im Falle unserer Beispielimplementierung sieht die Antwort bei Erfolg so aus:
HTTP/1.1 200 OK Date: Wed, 22 Apr 2020 08:35:15 GMT Server: Apache Content-Length: 17 Content-Type: text/plain; charset=ISO-8859-1 good 87.65.43.21
Das DDNS-Protokoll von DynDNS.org
In den 90er Jahren, bevor das Internet so durchgehend vergeschäftlicht wurde, boten einige Organisationen kostenlose DDNS-Dienste an. Ein sehr beliebtes Angebot war das von DynDNS.org. Das DDNS-Protokoll von diesem Dienst wurde sogar in Einwahl-Routern einprogrammiert und der Dienst wurde von ISPs und Router-Herstellern als Leistungsmerkmal beworben.
DynDNS.org gehört inzwischen Oracle und bietet keine kostenlose Dienste mehr. Dennoch wird das DDNS-Protokoll von DynDNS.org in der vorliegenden Beispielimplementierung übernommen in der Hoffnung, daß die Kompatibilität mit einigen gängigen Einwahl-Routern von Vorteil sein kann. Es gibt noch eine kurze Online-Dokumentation der Anfrage und Antwortnachrichten.
Das gesammte Protokoll sieht einen einzigen Nachrichtenaustausch aus Anfrage und Antwort vor. Die Anfrage kann mehrere Argumente enthalten; die Antwort kann verschiedene Code-Wörtern enthalten. Übrigens können in einer einzigen Anfrage mehrere DNS-Einträge gewünscht werden. In diesem Fall kann die Antwort mehrzeilig ausfallen.
Das Verhalten von Server und Client bei künftigen Kommunikationsvorgängen wird unter Umständen von vorangegangenen Kommunikationsergebnissen beeinflußt: nach wiederholten fehlerhaften oder redundanten Anfragen kann der Server weitere Anfragen des Benutzers verweigern; nach wiederholten Fehlermeldungen sollte ein Client aufhören, immer dieselbe Anfrage zu schicken. Und für den Fall, daß mehrere Clients dynamische DNS-Einträge in derselben Domain example.com bestellen, muß der Server den Stand aller Client-Einträge intern speichern, damit er nicht mit einer neuen Zonefile einen früher erstellten Eintrag löscht. Zu diesen Fragen siehe den Abschnitt #Sukzessive_Kommunikationsabläufe nach der Beschreibung von Anfragen und Antworten unten.
Anfrage
Die Anfrage in Form eines URL übergibt dem DDNS-Programm in einem 'Query-String' einige Metavariablen. Das heißt, in einem URL der Form
https://benutzername:passwort@ddns.beisiel.de/cgi-bin/ddns?hostname=einwahl.example.com&myip=87.65.43.21
signalisert das Fragezeichen, daß ein Query-String folgt. In einem solchen Query-String können in der Beispielimplementierung folgende Metavariablen definiert werden:
| Variable | Beispiel | Bemerkungen |
|---|---|---|
| hostname | hostname=einwahl.example.com hostname=eins.example.com,zwei.example.com[,...] |
Muß ein vollständig qualifizierter Domain-Name ("FQDN") sein; example.com muß eine vom Besitzer des DDNS-Programms verwaltete Domain sein. Genaugenommen kann der Wert eine durch Kommata gegliederte Liste mehrerer gültiger Domainnamen sein, falls mehrere Einträge mit derselben IP-Adresse gewünscht werden. |
| myip | myip=87.65.43.21 |
Kann entfallen; kann vom Server ignoriert werden. Maßgeblich ist dann die IP-Adresse des Absenders, wie sie vom Web-Server mitgeteilt wird. |
| mx | mx=87.65.43.21 mx=NOCHG |
Neben dem A-Eintrag möchte der Client auch einen MX-Eintrag. Der Wert NOCHG (für „no change“) bedeutet, der bestehende MX-Eintrag (oder seine Abwesenheit) soll nicht geändert werden. |
| backmx | backmx=YES backmx=NOCHG backmx=NO |
Falls YES, wird ein zweiter MX-Eintrag erzeugt, der einwahl.example.com als Mail-Server für einwahl.example.com nennt. Dieser Eintrag hat eine niedrigere Präferenzzahl (also eine höhere Priorität) als der mit mx angeforderten Eintrag. |
| wildcard | wildcard=ON wildcard=NOCHG wildcard=OFF |
Neben dem A-Eintrag für den Domainnamen einwahl.example.com wünscht der Client auch einen Eintrag für beliebige Subdomains, also *.einwahl.example.com, mit der gleichen IP-Adresse. |
| offline | offline=YES offline=NOCHG |
Falls YES, wird ein DNS-Eintrag für einwahl.example.com aus der Zonefile getilgt. Gegebenenfalls wird der Hostname dann auf Grund eines parallelen Wildcard-Eintrags für *.example.com einer anderen IP-Adresse zugeordnet werden. |
Alle Parameter bis auf hostname können entfallen. Bei nichtdokumentierten Argumenten ist das Verhalten undefiniert™.
Antwort
Die Antwort auf eine erfolgreiche HTTP-Anfrage besteht im häufigsten Fall aus einigen Header-Zeilen, gefolgt vom Inhalt der gewünschten Text- oder andere Datei. Ein Status-Code in der ersten Header-Zeile gibt an, ob die Anfrage bedient werden kann oder kreist andernfalls den Grund für die Enttäuschung ein.
Die vorliegende Beispielimplementierung von DDNS schickt einen der üblichen HTTP-Status-Codes "200 OK" oder "500 Internal Server Error", gefolgt von einer kurzen Textnachricht nach dem HTTP-Header. Bei diesem Programm ist – laut Gebrauchshinweise von DynDNS.org – nicht der Status-Code im Header, sondern der Inhalt der Nachricht die definierte, maßgebliche Ergebnismeldung des Programms.
| Meldung | Bedeutung | Bemerkungen |
|---|---|---|
| good <IP number> |
Der gewünschte DNS-Eintrag wurde erfolgreich in einer Zonefile eingetragen. |
Es kann natürlich noch einige Minuten dauern, bis die Zonefile vom Hostsharing-Roboter abgelesen wird und der Inhalt in die BIND-Konfiguration übernommen. |
| good 0.0.0.0 |
Das Argument offline=YES wurde empfangen und verarbeitet. |
Der Domainname hat also keinen dynamischen DNS-Eintrag mehr. |
| nochg <IP number> |
Der gewünschte DNS-Eintrag war bereits vorhanden. |
Der Server selbst macht keine DNS-Abfrage, um das zu vermitteln: die „no change“-Antwort besagt nur, daß eine Anfrage für diesen Eintrag bereits mit Erfolg quittiert wurde. |
| notfqdn |
Fehlschlag: der gewünschte Domainname ist nicht gültig, oder es wurde keiner angegeben. |
... |
| nohost |
Fehlschlag: der gewünschte Domainname ist gehört nicht zu denen, die für diesen Benutzer des DDNS-Dienstes konfiguriert sind. |
Siehe den Abschnitt Administration weiter unten. |
| badauth |
Fehlschlag: Die Kombination von Benutzernamen und Paßwort entsprach keinem DDNS-Account, oder das Account ist momentan gesperrt. |
Ein gesperrtes Account kann nur der Domain-Admin mittels des Administrationswerkzeugs wieder freigeben: siehe den Abschnit Administration weiter unten. |
| abuse |
Fehlschlag: der gewünschte Domainname ist wegen vorangeganger Fehlschläge oder überflüssiger Aufrufe gesperrt. |
Siehe den Abschnitt Sukzessive Kommunikationsabläufe unten. |
| 911 |
Fehlschlag: Das Server-Programm hat einen internen Fehler festgestellt. |
Das Problem liegt nicht in der Anfrage an sich. |
Man kann sich durchaus eine sinnreichere Kommunikation zwischen Client und Server vorstellen, doch das hier beschriebene Protokoll ist eben von DynDNS.org verwendet worden und wird in gängigen Routern implementiert, also wird es in der vorliegenden DDNS-Implementierung nachgebildet.
Sukzessive Kommunikationsabläufe
Der Server muß sich zwischen einzelnen Aufrufen einiges merken, um Ressourcen zu schonen und um zu verhindern, daß einmal vergebene DDNS-Einträge von neuen Anfragen, die dieselbe übergeordnete Domain betreffen, durch Überschreiben verlorengehen.
Mißbrauch und Benutzersperrung
Zur Schonung von Ressourcen muß sich die Implementierung weigern, sich mit zuvielen fehlerhaften oder auch nur überflüssigen Anfragen zu beschäftigen. Dazu führt der Server eine Strichliste über solche Anfragen jedes Clients und sperrt nach einer bestimmten Anzahl solcher Anfragen den Benutzernamen oder einzelne Domainnamen gegen die weitere Nutzung des Dienstes.
Mißbrauchspunkte gegen einen einzelnen Domainnamen gibt es für:
- eine Anfrage, die keinen neuen DNS-Eintrag (und keine Änderung oder Löschung eines Eintrags) erfordert, sondern bestehende Merkmale nur wiederholt
Mißbrauchspunkte gegen einen Benutzernamen gibt es für:
- die Angabe eines Domainnamens, der in der Dienstkonfiguration dem anfragenden Benutzernamen nicht zugeordnet ist
- die Angabe eines Domainnamen in einer Domain, die nicht demselben Hostsharing-Domain-Admin gehört, der den DDNS-Dienst anbietet
- die Angabe eines Domainnamens, der in der Dienstkonfiguration bereits wegen mißbräuchlicher Anfragen gesperrt ist (siehe oben)
Um eine Sperrung aufzuheben, wird in der Regel eine Handlung durch den Administrator erforderlich sein.
Mehrere dynamische Subdomains in derselben Domain
Sobald zwei verschiedene DDNS-Einträge in derselben Domain verlangt werden – beispielsweise home.example.com und office.example.com – wird es notwendig, bei jeder neuen Zonefile für example.com eventuell frühere Einträge zu konservieren. Der Rechner zu Hause weiß beim Bestellen seines DDNS-Eintrags nichts vom Rechner im Büro und umgekehrt. Der Server muß in irgendeiner Form über bereits vergebene Einträge Buch führen und bei einer neuen Anfrage, die example.com betrifft, alle bereits aktiven DDNS-Einträge für example.com mit in die neue Zonefile aufnehmen &ndash auch wenn sie auf Anfragen verschiedener Benutzer zurückgehen.
Datenbank
In der Beispielimplementierung werden diese Informationen in einer SQLite-Datenbank gespeichert.
Sicherheit
Rechte
Die Benutzerrechte werden durch das Hostsharing-System kontrolliert. Sowohl das CGI-Programm als auch das Administrationswerkzeug werden mit den Rechten des Domain-Admins (xyz00-benutzername in unserem Beispiel) ausgeführt, also kann dieses Programm nur die Domains bearbeiten, die von xyz00-benutzername verwaltet werden.
Authentifizierung
In der Beispielimplementierung (wie auch seinerzeit bei DynDNS.org) wird das CGI-Programm durch einen .htaccess-Eintrag geschützt, der HTTP-Basic-Authentication vorschreibt. Also wird das Programm eigentlich mit einem URL der form
https://ddnsaccount:passwort@ddns.example.com/cgi-bin/ddns?hostname=...
aufgerufen.
Verschlüsselung
Das CGI-Programm sollte nur in example.com/cgi-ssl/ installiert werden, nicht in example.com/cgi/. Damit ist die Kommunikation zwischen Client und Server durch SSL verschlüsselt.
Administration
Der Verwalter des DDNS-Programms trägt berechtigte Benutzer und die ihnen zugeteilten Domainnamen in die Datenbank des Programms ein mit Hilfe eines kleinen Hilfsprogramms. Das ist im vorliegenden Fall ein menügesteuertes Programm für die Befehlszeile, daß die naheliegenden Funktionen anbietet: Account hinzufügen, löschen, sperren, entsperren, Paßwort setzen, ändern; Domainnamen hinzufügen, ändern, entsperren, löschen; Accounts und Domainnamen mit aktuellem Status auflisten. Die Funktionen sind auch über Befehlszeilenargumente verfügbar, also skriptfähig.
Eine Übersicht der Funktionen des Administrationswerkzeugs gibt dieses selbst aus:
Achtung, veraltet: inzwischen ist die Verwaltungsoberfläche für die hier beschriebene Implementierung web-basiert.
xyz00-benutzername@h02:~$ bin/ddnsadmin -h
ddnsadmin.pl: Verwaltungswerkzeug für ddns
Verwendung:
ddnsadmin -A{[ahlusf]} [<Account>] [-f <DB-Datei>]
ddnsadmin -D{[ahlsf]} [<Domain>] -A <Account> [-f <DB-Datei>]
ddnsadmin -E <Einstellung> <Wert> [-f <DB-Datei>]
ddnsadmin [-f <DB-Datei>] [-n]
Wenn keine Option oder nur -f <DB-Datei> angegeben wird, bietet
ddnsadmin.pl eine interaktive Menüoberfläche.
Optionen:
-f <DB-Datei> Angegebene Datenbankdatei verwenden
-n Neue, leere Datenbank erzeugen
-Aa [<Account>] Account(s) auflisten
-Ah <Account> <Paßwort> Account hinzufügen
-A{lsf} <Account> Account löschen, sperren, freigeben
-Au <Account> <Name> Account umbenennen
-A <Account> -Da [<Domain>] Domain(s) auflisten
-A <Account> -D{hlsf} <Domain> Domain hinzufügen,
löschen, sperren, freigeben
-E <Einstellung> <Wert> Einstellung ändern
-h Diese Übersicht ausgeben
Einstellungen:
maxacctabuse Anzahl der mißbräuchlichen Aufrufe,
bevor ein Account gesperrt wird
maxhostabuse Anzahl der mißbräuchlichen Aufrufe,
bevor ein Domainname gesperrt wird
safeinterval Mindestabstand zwischen redundanten Aufrufen
(in Sekunden)
cgihost Server, der das DDNS-Skript bereithält
xyz00-benutzername@h02:~$
Eine Auflistung des momentanen Inhalts der DDNS-Datenbank durch das Administrationswerkzeug könnte beispielsweise so aussehen:
xyz00-benutzername@h02:~$ bin/ddnsadmin.pl -Aa 1. papst Mißbrauch: 0; gesperrt: nein avignon.example.com zuletzt aktiv am Sun Apr 26 22:24:49 2020 mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein; Subdomains: nein; Mißbrauch: 0; gesperrt: nein vatican.beispiel.de zuletzt aktiv am Sun Apr 26 22:24:49 2020 mit IP-Nr. 87.65.43.21; MX: 0; Backup-MX: nein; Subdomains: nein; Mißbrauch: 0; gesperrt: nein 2. kaiser Mißbrauch: 4; gesperrt: ja augsburg.beispiel.de zuletzt aktiv am Fri Apr 24 16:13:49 2020 mit IP-Nr. 64.82.31.75; MX: 0; Backup-MX: nein; Subdomains: nein; Mißbrauch: 0; gesperrt: ja 3. luther Mißbrauch: 1; gesperrt: nein wittenberg.example.com zuletzt aktiv am Mon Apr 27 10:12:49 2020 mit IP-Nr. 78.56.34.12; MX: 0; Backup-MX: nein; Subdomains: nein; Mißbrauch: 1; gesperrt: nein xyz00-benutzername@h02:~$
Das DDNS-Account „kaiser“ in dieser Auflistung ist wohl auf Grund fehlerhafter Anfragen automatisch gesperrt worden. Der Inhaber wird sich wohl bald melden, um nach Korrektur seiner Client-Konfiguration die Aufhebung der Sperre zu wünschen.
Log
Alle Anfragen werden in einer täglich wechselnden Log-Datei protokolliert, entweder schlicht oder ausführlich, je nachdem, ob eine Variable verbose wahr ist. Ein ausführlicher Log-Eintrag sieht so aus:
Sun Apr 26 20:21:45 2020 ddns aufgerufen von papst unter 84.185.97.8 URL: https://ddns.example.com/cgi-bin/ddns.cgi?hostname= avignon.example.com,vatican.beispiel.de& myip=84.185.97.8 Verwende IP 84.185.97.8 (= 1421435144) DB-Version: 1 Skript und DB exklusiv geöffnet avignon.example.com: IP: 84.185.97.8; MX: 0; Backup-MX: nein; Wildcard: nein; Mißbrauch: 0; gesperrt: nein vatican.beispiel.de: IP: 84.185.97.8; MX: 0; Backup-MX: nein; Wildcard: nein; Mißbrauch: 0; gesperrt: nein Betroffene Zonen: example.com, beispiel.de Temporärdatei example.com_hxNa.new geschrieben Zonendatei /home/pacs/xyz00/users/benutzername/doms/example.com/ etc/pri.example.com eingestellt Temporärdatei beispiel.de_6HcO.new geschrieben Zonendatei /home/pacs/xyz00/users/benutzername/doms/beispiel.de/ etc/pri.beispiel.de eingestellt Abgeschlossen: Fertig
Wenn verbose auf falsch gesetzt ist, sind die Log-Einträge einzeilig.