# Anleitung für DynDns mit Bind

## 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**

1. 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`
    1. Damit nicht der Ordner mit allen Zonen-Dateien für den Dienst schreibbar ist, werden die dynamischen Zonen in einen eigenen Ordner ausgelagert
    
1. 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
1. Abfragen der aktuellen IP in die Variable NEWIP
1. Vergleichen der IPs
   1. wenn IPs unterschiedlich, Update durchführen
   1. 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