PrivateDynDns

Anleitung für DynDns mit Bind

Vorbedingung

Das alles funktioniert nur dann, wenn das hier beschriebene im selben Netz / auf dem selben Host passiert, dessen IP aktualisiert werden soll

Erforderlich

1. Unser Nameserver delta.memory-leak.de muß Master der Zone sein

   1. Wie finde ich das raus?

      • In der Datei named.conf.public-zones muß ein Block stehen, der so aussieht:
        

   Zonendatei

   zone "$zonenname" {
       type master;
       file "$zonendatei";
   };
   

   Wichtig ist in der zweiten Zeile master

2. Die Zonendatei muß im Ordner /etc/bind/dynamic-zones liegen

   1. Warum?
      • Der Service named muß zu dieser Datei eine Journal-Datei anlegen dürfen. Diese Journal-Datei wird IMMER im selben Ordner angelegt und hat die Endung .jnl
   2. Damit nicht der Ordner mit allen Zonen-Dateien für den Dienst schreibbar ist, werden die dynamischen Zonen in einen eigenen Ordner ausgelagert
      

3. Ein für die Zonen-Datei eingetragener Schlüssel, mit dem das Update signiert wird

   1. Warum?
      • Kurz und bündig: Autorisierung

Einrichtung

Erzeugen des Zonen-Signier-Schlüssels

Mit dem Tool ddns-confgen (in Debian im Paket bind9 enthalten), den erforderlichen Schlüssel generieren:

ddns-confgen -z $ZONE

$ZONE ist die gewünschte Zone, in meinem Fall war das memory-leak.de

Ergebnis

root@delta:/etc/bind# ddns-confgen -z memory-leak.dre
# To activate this key, place the following in named.conf, and
# in a separate keyfile on the system or systems from which nsupdate
# will be run:
key "ddns-key.memory-leak.dre" {
    algorithm hmac-sha256;
    secret "hMZ4fVbpllxEJ93AoTa+PjYeUIXx2FHXLgBTz/fWXlA=";
};  
# Then, in the "zone" definition statement for "memory-leak.dre",
# place an "update-policy" statement like this one, adjusted as 
# needed for your preferred permissions:
update-policy {
    grant ddns-key.memory-leak.dre zonesub ANY;
};

Dem Ergebnis und den Anweisungen schließt man sich nahezu vollständig an.

Integration des Schlüssels in die Konfiguration

In die Datei ddns-key.$zone kopiert man den ersten Abschnitt:

root@delta:/etc/bind# cat ddns-key.memory-leak.dre 
# To activate this key, place the following in named.conf, and
# in a separate keyfile on the system or systems from which nsupdate
# will be run:
key "ddns-key.memory-leak.dre" {
    algorithm hmac-sha256;
    secret "hMZ4fVbpllxEJ93AoTa+PjYeUIXx2FHXLgBTz/fWXlA=";
};  

Danach integriert man den Schlüssel im System:

root@delta:/etc/bind# cat named.conf.local
...
include "/etc/bind/ddns-key.memory-leak.dre";

Und zu guter Letzt wird der Schlüssel noch für die jeweilige Zone mit seinen Berechtigungen integriert. Dazu editiert man die Datei named.conf.public-zones:

root@delta:/etc/bind# head -n 8 named.conf.public-zones
zone "memory-leak.de" {
    type master;
    file "/etc/bind/dynamic-zones/db.memory-leak.dre";
    // dynamic-zones necessary, because binds named needs to be allowed to write journal files to this directory
    // journal files must be created in the directory of the original zone file. BIND BUG?
    update-policy { grant ddns-key.memory-leak.dre name murnau.memory-leak.de ANY; };
};

Die letzte Zeile vor der schließenden Klammer sagt im Prinzip folgendes aus:

Mit dem Schlüssel, der als ddns-key.memory-leak.dre in die Konfiguration eingebunden wurde, darf ich für die Zonendatei db.memory-leak.dre Veränderungen am Eintrag vornehmen, der auf den Namen murnau.memory-leak.de passt. Für eine genauere Beschreibung der Policy-Einträge kann man sich http://www.zytrax.com/books/dns/ch7/xfer.html#update-policy anschauen. Für eine genauere Einschränkung könnte ich in meinem Fall noch ANY durch A ersetzen, weil ich nur A Records bearbeiten möchte.

Bereitstellen des Schlüssels für die Nutzung

Um den Schlüssel, den wir erzeugt haben, jetzt auch für Aktualisierungen noch nutzen zu können, kopiert man sich den Abschnitt mit dem Schlüssel selbst noch in eine Datei key.txt:

key "ddns-key.memory-leak.dre" {
    algorithm hmac-sha256;
    secret "hMZ4fVbpllxEJ93AoTa+PjYeUIXx2FHXLgBTz/fWXlA=";
};  

Diese Datei hat man auf dem System, von dem die Aktualisierungen kommen.

Damit sind alle Vorarbeiten abgeschlossen.

Nutzung

Im Prinzip erfolgt die Nutzung mit dem im Repository hinterlegten Skript script.sh.

Dazu setzt man folgende Parameter im Skript:

• NS: Der Nameserver, auf dem die Zone liegt, in unserem Fall offensichtlich delta.memory-leak.de
• NSKEY: Der Pfad zur Datei key.txt
• ZONE: Die Zone, die aktualisiert werden soll, in meinem Fall memory-leak.de. Diese Zone entspricht der Zone, für die der Schlüssel auf delta eingebunden wurde
• HOST: Der Eintrag in der $ZONE, der aktualisiert werden soll, in meinem Beispiel oben ist das murnau.memory-leak.de.
• TIMEOUT: Sollte an sich nicht kleiner als 3600s sein, das entspricht einer Stunde. Gemäß RFC dürfen hier auch keine kleineren Einträge stehen.

Die Logik des Skritpes ist geklaut von https://www.thomaschristlieb.de/eigener-dyndns-dienst-mit-fritzbox-und-hetzner/, alle Credits für das Skript gehören also nicht mir.

Das Skript erledigt dann folgendes:

1. Abfragen der im NS hinterlegten IP in die Variable OLDIP
2. Abfragen der aktuellen IP in die Variable NEWIP
3. Vergleichen der IPs
   1. wenn IPs unterschiedlich, Update durchführen
   2. wenn IPs gleich, nichts tun.
      
      
      

Es gibt also einen sehr wichtigen Aspekt: das Skript MUSS von dem NAT-Netz ausgeführt werden, dessen Eintrag aktualisiert werden soll. Es muß nicht zwingend der Router sein, sondern es kann auch ein beliebiges Linux / Unix hinter dem Router sein, solange

• das Tool nsupdate erreichbar ist
• eine Bash verfügbar ist
• der DNS-Server $NS erreichbar ist
• der DNS-Server resolver1.opendns.com erreichbar ist
• ihr dem System soweit vertraut, daß Ihr
  • glaubt, daß der Schlüssel für Updates dort gut geschützt ist
  • davon ausgeht, daß von dort keine kaputten Updates durchgeführt werden