Und tschüss, liebe Dynamic-DNS-Anbieter ...
Wer im Heimnetz hinter öffentlicher IPv4-Adresse eines NAT-Routers Dienste betreibt, benötigt mehrere im weltweiten Domain-Name-System registrierte Nameserver, welchen der heimische Router
seine öffentliche IPv4-Adresse bei Änderungen per Dynamic DNS mitteilt und so unter einem gleichbleibenden Domain-Namen des Dyn-DNS-Anbieters erreichbar ist. Auch IPv6-Adressen eigener
Server wollen unter gleichbleibendem Domain-Namen erreichbar sein.
Dieses Geschäftsmodell wurde mit "Erfindung der Zwangstrennung" an DSL-Anschlüssen quasi über Nacht geschaffen und viele Anbieter drängen mit stetig eingeschränkten freien Angeboten
- Rechner hinter dem Router nicht erreichbar
- begrenzte Zahl an Hosts kostenlos
- nur wenige, vom Dynamic-DNS-Anbieter besessene Domain-Namen mit erkennbarem Bezug zur Fremd-Dienstleistung
- Zwangsaktualisierung von IP-Adressen in bestimmten Intervallen zur Beibehaltung des Accounts
- nicht in Voreinstellungen der FritzBox vorhanden
- unattraktive TTL- (Time-To-Live) -Intervalle und Zonen-Transfers
Auch mich ließen Wichtigkeit der beruflichen Erreichbarkeit und die Befürchtung technischer Komplexität zunächst mehrere Jahre zahlen, nachdem DynDNS.org sich über die Jahre stetig wie sprunghaft verteuert hatte.
Das jedoch muss nicht sein und kann ebenso einfach wie zuverlässig so gelöst werden, dass man nicht nur unter der/den eigenen Wunsch-Domains erreichbar ist, sondern auch beliebige weitere Domains, DSL-, Glasfaser-, Kabel-Anschlüsse für Freunde, Bekannte wie Geschäftspartner ohne weiteren Aufwand so mit Namensdiensten versehen kann wie jeder kommerzielle Anbieter.
Die dahinterliegende Idee ist nicht neu, jedoch möchte ich den vielen Anleitungsvarianten im Internet diejenige auf bewusster Minimalgrundlage von bind9 hinzufügen, welche ich selbst in präziser Knappheit gerne für eine Umsetzung rein mit bind9 und PHP gerne gelesen hätte. Voraussetzungen
- Hinreichende Kenntnis von IPv4, IPv6 nebst Domain-Name-System wie im besonderen Einarbeitungsbereitschaft in BIND 8/9 als eigentlichen Nameserver
- Empfohlen sei das erste Drittel das Standardwerks zu DNS and BIND aus der Titelzeile.
- Dort vermittelte Grundlagen, welche meiner Ansicht nach schlicht systematisch wie gründlich und damit richtig zu erlernen sind, werden unten als bekannt vorausgesetzt.
- Ein Linux-Root-Server mit statischer IPv4- und IPv6-Adresse
- dieser Server wird der Master-Nameserver und gehört zu einer beliebigen eigenen oder fremden Domain z.B. des Root-Server-Hosters
- Eine eigene Domain
- am besten nicht über einen Hoster oder den eigenen Internet-Service-Provider, da man sich damit bereits dauerhaft an den Dienstleister kettet, welcher die Domain selbst registriert und für die Vertragsdauer praktisch lediglich verleiht, sondern einen echten Registrar, in meinem Fall etwa United-Domains, direkt bei der für die zugehörige Top-Level-Domain zuständigen Registry, denn diesen Domain-Namen wird man wahrscheinlich nicht nur ein Leben lang behalten sondern (und lediglich darin unterscheidet er sich von der Steuer-ID des Finanzamtes) auch vererben ;-)
- diese zunächst virtuelle, "frei schwebende" Domain (auch mehrere), für deren sämtliche öffentlich erreichbare Rechner wir den Nameserver betreiben, ist technisch zwingend vom vorigen Root-Server separiert. Der Root-Server, auf welchem wir den Nameserver für vorige Domain einrichten, wird bei einem beliebigen Hoster betrieben, hat einen ebenso beliebigen Domain-Namen, jedoch statische IPv4/6-Adressen. Die auf den eigenen Namen registrierte Domain wird erst über den Nameserver mit einem oder mehreren wiederum beliebigen privaten eigenen oder fremden Netzwerken verknüft.
- Ein für 300.000 Anfragen/Monat kostenloser Account des von c't bereits 2013 empfohlenen Anbieters für Secondary-Nameserver BuddyNS, dessen
Angebot auch 2021 noch unverändert besteht.
- Um einen (hier eigenen) Nameserver für die "echte" eigene Domain offiziell im weltweiten Verbund des Domain-Name-Systems registrieren zu lassen, verlangen Registry und damit Registrar in vielen Fällen (z.B. Subdomain der DE-Toplevel-Domain) den Nachweis der Ausfallsicherheit durch mehrere weitere secondary oder Slave-Nameserver. Genau diesen Service, den Zonen-Transfer, vulgo Kopien des selbstverwalteten Master-Nameservers, bietet BuddyNS auf einfache Weise.
- Für die Anmeldung (Datenschutz) genügen die Angaben von
- eigener Domain, für welche der Namensdienst eingerichtet wird,
- der statischen IPv4-Adresse des eigenen Nameservers und
- der eigenen Mail-Adresse
- Empfohlen sei das erste Drittel das Standardwerks zu DNS and BIND aus der Titelzeile.
- Linux-Root-Server mit statischer IPv4- und IPv6-Adresse bei beliebigem Hoster, egal ob nur unter dessen oder einer eigenen Domain erreichbar.
- Ein BuddyNS-Account oder alternatives Angebot für Slave-Nameservices
- Eine direkt via Registrar erworbene Domain
- example.org diejenige eigene Domain, für welche (dynamische) IPv4-/IPv6-Namensdienste benötigt werden
- dns.andere.domain der abweichende (sic !) Domain-Name des eigenen Servers mit statischen Adressen unter der fremden oder eigenen Domain andere.domain.
Nach Installation von bind9 werden auf dem Root-Server sämtlich unter /etc/bind liegende Dateien angelegt (db.example.org), bzw. editiert (named.local.conf, named.local.options) ...
... wie hier dargestellt ...
... und unter apache2 auf demselben Root-Server ein PHP-Script dnsupdate.php angelegt, welches nach Aufruf zur Adressaktualisierung von eigenen Routern/FritzBoxen (bzw. im Test manuell) das dynamische Update derer IPv4- und IPv6-Adressen via Konfigurationsdatei für und Aufruf von nsupdate in db.example.org (effektiv db.exmaple.org.jnl, cf. Lehrbuch oben) durchführt ...
Wurden alle Funktionen hinreichend getestet und der Zonentransfer an den Anbieter für secondary nameserver, hier BuddyNS erfolgreich durchgeführt, können in der Konfiguration der eigenen Domain (hier United Domains) für das Beispiel example.org der so eingerichtete Master-Nameserver und alle von Registry/Registrar geforderten Slave-Nameserver offiziell und damit weltweit gültig registriert werden.
Erst nach der sogenannten Registrierung der Nameserver für die eigene Domain kann und wird auch die Konfiguration bei BuddyNS oder anderem Anbieter vollständig abgeschlossen.
Im letzten Schritt nun werden heimische FritzBoxen so konfiguriert, dass sie zunächst ihre IPv6- und anschließend ihre IPv4-Adresse über das oben installierte PHP-Script aktualisieren. Nach erfolgreichem Aufruf des Scripts mit FritzBox-spezifischer Rückgabe "good "<IP-Adresse> prüfen diese in der Folge halbstündlich, ob der Domain-Name tatsächlich aktualisiert worden war und signalisieren genau danach eine erfolgreiche Anmeldung.
Impressum und Datenschutzerklärung