Bez popisu

Patrick Jaeger 8e51c7b1e0 Schlüsselintegration fertig dokumentiert %!s(int64=8) %!d(string=před) roky
README.md 8e51c7b1e0 Schlüsselintegration fertig dokumentiert %!s(int64=8) %!d(string=před) roky
script.sh 1524364024 Init + Update-Skript %!s(int64=8) %!d(string=před) roky

README.md

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

  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.

Nutzung