DNS

DynDNS - Eintrag von temporären Adressen in den Nameserver

Nutzungsszenario

Man möchte vom Internet aus auf einen Rechner im lokalen Netz zugreifen (z.B. WWW-Dienst). Das lokale Netz ist über eine Wahlverbindung mit dem Internet verbunden.

In einem lokalen Netz sollte der DHCP-Server konsistent mit dem Nameserver sein. Manchmal sollen die Nutzer für ihren persönlichen Rechner eigene Namen vergeben dürfen, die dann via DHCP-Server zum Nameserver übertragen werden sollen.

Protokoll

RFC2136 Dynamic Updates in the Domain Name System (DNS UPDATE): beschreibt die Protokollerweiterung, der das Update erlaubt.

Verwendung des Bind

Methode mit Key-File

Zone in etc/named.conf einrichten:

zone "dyn.intern" in {
        type master;
        allow-transfer { localhost; localnets; internnets;};
        file "master/dyn.intern.zone";
        update-policy {
            grant rw.intern zonesub ANY;
        };
};

mit der update-policy ist das Dynamic Update erlaubt.

Im Verzeichnis master muss ein leeres Zone-File angelegt sein:

$ORIGIN .
$TTL 259200     ; 3 days
dyn.intern              IN SOA  ns.intern. hostmaster.intern. (
                                2013010206 ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                2419200    ; expire (4 weeks)
                                86400      ; minimum (1 day)
                                )
                        NS      ns.intern.
                        TXT     "Rudolfs Webers dynamische Intern Domain"
$ORIGIN dyn.intern.
$TTL 1  ; 1 second

Erzeugung key-File:

   ddns-confgen -a hmac-md5 -k rw.intern -z dyn.intern

wobei rw.intern der Keyname ist, und dyn.intern die dynamische Zone.

Den oberen Teil

key "rw.intern" {
        algorithm hmac-md5;
        secret "HHzzrHKPwKd+cY+mJ31qhA==";
};

kopiert man entweder ins named.conf oder besser:
in named.conf

    include "keys.conf";

und kopiert in das named.conf Konfigurierte directory den Schlüssel in eine Datei keys.conf

Die Datei den aktuellen Key -Block braucht man auch als "keyfile" auf der Client-Seite.

Wichtig ist, dass der Key, hier "rw.intern", die Verbindung vom key zum grant herstellt. Offensichtlich besteht der Sicherheitsmechanismus hier, das das "secret" sowohl Nameserver als auch nsupdate-Client bekannt ist. Daher ist dieses geheimzuhalten und nicht etwa wie oben geschen zu veröffentlichen :-)

Weitere Hinweise:

Das Verzeichnis, in dem das Zonefile legt, muss für den named schreibbar sein
Das Zonefile selber wird auch automatisch fortgeführt.
Das Journal zonefile.jnl wird geschrieben.
Mit named-journalprint zonefile.jnl kann die Aufdatierungsgeschichte gesehen werden.

Eintragen eines Resource Records

#!/bin/bash
nsupdate -k keyfile <<EOF
server	192.168.1.4
zone	dyn.intern.
ttl	1
update delete nutest.dyn.intern A
update add nutest.dyn.intern 1 A 127.0.0.1
send
EOF

Test

Danach ist also der Name nutext.dyn.intern eingetragen, wie man verifizieren kann:

  dig @192.168.1.4 nutext.dyn.intern

Methode mit Nutzerschüssel

Erzeugung Nutzerschlüssel

     dnssec-keygen -a HMAC-MD5 -b 512 -n USER Rudolf.Weber.iss-ag.com

(aus [PDDNS])

Falsche Überlegung

Der Nutzerkey könnte ganz normal in der Zone intern aufgenommen werden, und der named könnte beim auflösen des Nutzers sich selber fragen.
Allerdinge entnehme ich ARM, dass der Schüssel in dem named.conf-Datei eingetragen sein muss!
Allerdings kann der Tat ein öffentlicher Schlüssel so via Name-Server veröffentlicht werden.