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


## Nutzung