[HowTo] DDNS (mit dhcpd und bind9)

[ThorstenHirsch]

0. Vorwort
Dieses HowTo besteht eigentlich aus 2 HowTos, denn noch während ich daran arbeitete, hat sich Schoki (ein Forumsmitglied) bei mir gemeldet und mich auf sein HowTo hingewiesen, das er jetzt auch veröffentlichen wollte. Damit wir nicht zeitgleich 2 HowTos zum selben Thema mit beinahe komplett gleichem Inhalt hier im Forum haben, habe ich die beiden HowTos zusammengefasst.

Ihr findet das HowTo von Schoki hier.

Noch ein Wort zur Zielgruppe: Ihr solltet in etwa wissen, wie /etc aufgebaut ist, vor allem wie man Dienste/Daemons startet und dem "Autostart" Eurer Distribution hinzufügt. Darauf werde ich nicht eingehen. Falls es Probleme gibt, bitte keine PMs, sondern macht einen ganz normalen Thread auf. Und schaut am besten zunächst in die Logdateien unter /var/log - oft können die Euch schon weiterhelfen.

1. Überblick

Klar, für eine komfortable Konfiguration des heimischen Netzwerks nutzt man einen DHCP-Server. Der ist schnell eingerichtet und muss später auch nicht mehr gepflegt werden. Will man einen DNS-Server nicht nur zum weiterleiten der DNS-Anfragen an richtige DNS-Server nutzen, sondern auch die Namen der ans heimische LAN angeschlossenen Rechner auflösen, sieht das schon anders aus: für jeden Rechner sind zwei Einträge im DNS-Server nötig. Ein Eintrag beschreibt die Auflösung Rechnername => IP-Adresse und ein zweiter die Rückauflösung IP-Adresse => Rechnername. Die Pflege dieser Einträge für jeden neuen Rechner im LAN per Hand macht nicht besonders großen Spaß und angesichts der Syntax für den Hobby-Admin auch immer wieder mit einem seufzenden "wie war das noch gleich?" verbunden. Gerade beim heimischen LAN fragt man sich, ob dieser Aufwand überhaupt lohnt, oder ob man auf das DNS im LAN verzichtet und sich nicht doch lieber die 3 oder 4 IP-Adressen einfach merken sollte. Wer sich das fragt, sollte einen Blick auf DDNS werfen, denn hiermit entfällt die Pflege dieser Einträge, da sie automatisch erzeugt werden.

Der Knackpunkt an DDNS: der Rechnername wird vom Client selbst bestimmt. Wer dies nicht möchte, ist mit statischem DNS besser beraten. Für alle anderen, gibt's nun die Erklärung des technischen Zusammenspiels und anschließend eine Beispielkonfiguration. Diese wurde ausnahmsweise mal nicht unter Linux, sondern auf einem NetBSD-Rechner erstellt - die genutzten Programme* gibt's aber auch für Linux und sind bei Deiner Distribution wahrscheinlich sogar dabei.

2. Funktionsweise

Das Geheimnis hinter DDNS ist die Kommunikation zwischen DHCP- und DNS-Server. Sobald sich ein Rechner im LAN meldet (mit einem DHCPDISCOVER), bekommt er nicht nur vom DHCP-Server eine IP-Adresse zugewiesen, sondern teilt ihm auch seinen Hostnamen mit. Der DHCP-Server sagt diesen Hostname weiter an den DNS-Server, zusammen mit der IP-Adresse, die er ihm gegeben hat. Der DNS-Server erstellt daraus die Einträge zur Namens- und Reverse-Auflösung selbst.

3. Netzwerkaufbau

IP-Range: 192.168.0.0/24
Das bedeutet: 192.168.0.1 bis 192.168.0.254, Netzmaske: 255.255.255.0 und Broadcast-Adresse 192.168.0.255

Server: 192.168.0.1 (...und heißt "eclipse")
Clients: 192.168.0.11 bis 192.168.0.99 (wird vom DHCP-Server zugewiesen)
Domain-Name: example.lan

Der "Server" ist der Rechner, auf dem wir DDNS einrichten wollen. Außerdem wählt er sich per Arcor-DSL ins Internet ein und routet das lokale Netzwerk. Dies ist optional, ich habe die entsprechenden Stellen blau hervorgehoben, so dass Ihr wisst, was anzupassen ist, falls Euer DDNS-Server nicht gleichzeitig der Router ist. Die roten Markierungen sind spezifisch für Arcor-DSL.

4. Schlüssel

Keine Angst, hier wird kein Kryptogrphie-Know-How benötigt. Wir müssen nur einen Schlüssel erstellen, den der DHCP- und der DNS-Server nutzen, um die gegenseitige Kommunikation zu erlauben, was mit einem einfachen "shared secret key" funktioniert, also quasi einem Passwort, das beide Dienste kennen. Dieses Passwort denken wir uns aber nicht selbst aus, sondern lassen es uns erstellen von einem Programm:

dnssec-keygen -a HMAC-MD5 -b 128 -n USER mykey

Es sind nun 2 Dateien entstanden, die mit Kmykey anfangen und mit .private und .key aufhören. Ein Blick in eine der Dateien sollte uns das "Passwort" offenbaren. In unserem Beispiel sieht es so aus:

#/etc/Kmykey+Nummer.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: 3cd7a0db76ff9dca48979e24c39b408c

Den Key in der letzten Zeile heben wir uns auf für später, aber ansonsten brauchen wir die beiden Dateien nicht mehr und können sie löschen.

4. DHCP

Die Konfiguration des DHCP-Servers sieht wie folgt aus:

#/etc/dhcpd.conf
# Setting DHCPD global parameters
allow unknown-clients;
ddns-update-style interim;
authoritative;

key MYKEY {
  algorithm hmac-md5;
  secret "3cd7a0db76ff9dca48979e24c39b408c";
};

zone 0.168.192.in-addr.arpa {
  primary 192.168.0.1;
  key MYKEY;
}

zone example.lan {
  primary 192.168.0.1;
  key MYKEY;
}

# Set parameters for the 192.168.0.0/24 subnet.
subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.11 192.168.0.99;
  option subnet-mask 255.255.255.0;
  option domain-name-servers 192.168.0.1;
  option domain-name "example.lan";
  option routers 192.168.0.1;
  option smtp-server 192.168.0.1;
  option netbios-name-servers 192.168.0.1;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
}

Wie bei einem DHCP-Server üblich, gibt es oben globale Konfigurationseinträge und weiter unten die Konfiguration von unserem example.lan als "subnet"-Eintrag. Der zweite Subnet-Eintrag ist für die Netzwerkkarte, an der das DSL-Modem hängt. Hier soll kein DHCP genutzt werden, denn hier ist ja nur das DSL-Modem angeschlossen und sonst nix. Und das DSL-Modem braucht und kann auch gar kein DHCP.

Interessant für das DDNS (wurde durch die 2. Zeile aktiviert) sind die beiden Zone-Einträge (1 Zone für die Auflösung Name=>IP und die 2. für die Auflösung IP=>Name) und der key MYKEY.

5. DNS

Die Konfiguration des DNS-Servers ist etwas komplizierter. Zunächst die globale Konfigurationsdatei:

#/etc/named.conf oder auch /etc/bind/named.conf
acl "home" { 192.168.0.0/24; 127.0.0.1;};

key MYKEY {
  algorithm hmac-md5;
  secret "3cd7a0db76ff9dca48979e24c39b408c";
};

options {
        directory "/etc/namedb";
        allow-transfer { "home"; };
        allow-query { "home"; };
        listen-on port 53 { "home"; };
        auth-nxdomain no;    # conform to RFC1035

        forwarders {
          194.95.246.252;
          194.95.249.252;
        };
};

zone "example.lan" {
        type master;
        file "/etc/namedb/example.lan";
        notify no;
        allow-update { key MYKEY; };
};

zone "0.168.192.in-addr.arpa" {
        type master;
        file "/etc/namedb/example.lan.rev";
        notify no;
        allow-update { key MYKEY; };
};

zone "localhost" {
        type master;
        file "localhost";
};

zone "127.IN-ADDR.ARPA" {
        type master;
        file "127";
};

zone "." {
        type hint;
        file "root.cache";
};

Ihr seht, dass in der Konfigurationsdatei auf weitere Dateien im Verzeichnis /etc/namedb verwiesen wird. Bei Debian heißt das Verzeichnis /etc/bind - also wenn Ihr Debian habt, müsst Ihr diese Einträge entsprechend ändern.

Die IP-Adressen bei "forwarders" sind die DNS-Server von Arcor. An diese werden Anfragen weitergeleitet, die nicht das eigene LAN betreffen. Bei T-Online müsst Ihr andere IP-Adressen eintragen - welche das sind findet man ganz leicht per Google.

Nun zu den Zones: die ersten beiden sind die Einträge für unser Netzwerk 192.168.0.0/24 (wieder 2x weil in 2 Richtungen aufgelöst wird). Die nächsten beiden sind der Loopback auf dem Server selbst, also das Netz 127.0.0.0/8. Und der letzte Eintrag verweist auf die root-Nameserver im Internet, welche in der Datei /etc/namedb/root.cache eingetragen sind (unter Debian: /etc/bind/db.root). Um diese braucht Ihr Euch nicht zu kümmern, genausowenig um die Dateien für den Loopback.

Aber die beiden Dateien für das eigene Netz müsst Ihr erstellen:

;/etc/namedb/example.lan
$ORIGIN .
$TTL 86400      ; 1 day
example.lan              IN SOA  example.lan. eclipse.example.lan. (
                                2000111413 ; serial
                                10800      ; refresh (3 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      eclipse.example.lan.

Die Punkte am Ende der Domain unbedingt lassen!
Hier noch die Datei für die reverse-Auflösung:

;/etc/namedb/example.lan.rev
$ORIGIN .
$TTL 86400      ; 1 day
0.168.192.in-addr.arpa  IN SOA  example.lan. eclipse.example.lan. (
                                2000107302 ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                3024000    ; expire (5 weeks)
                                86400      ; minimum (1 day)
                                )
                        NS      eclipse.example.lan.

Geschafft. Jetzt können beide Dienste gestartet werden. Wie das funktioniert wisst Ihr bestimmt schon.

Wenn sich nun ein Client im Netz meldet und er seinen Hostname an den DHCP-Server schickt, leiter er den Namen an bind weiter und Ihr könnt die dynamisch erzeugten DNS-Einträge in den beiden letzten Dateien sehen. Ein Rechner "Tuxi" bekommt bspw. folgende Einträge (am Ende der Dateien zu finden):

;/etc/namedb/example.lan
tuxi                    A       192.168.0.98
                        TXT     "31657ed80c4acfdb1878c94dc30aed5b92"

;/etc/namedb/example.lan.rev
98                      PTR     tuxi.example.lan.

...und falls nicht...

6. Troubleshooting

a. DHCP-Clients müssen eventuell konfiguriert werden, so dass sie ihren Hostname an den DHCP-Server senden. Bei dhcpcd könnt Ihr mit den Optionen "-h" und "-H" herumspielen oder gleich einen Blick in die Manpage werfen. Aber die meisten Linuxdistributionen und Windows sind schon korrekt vorkonfiguriert.

b. Probleme mit dem Schlüssel? (...sind in den Logdateien von bind und/oder dhcpd zu sehen)
Hatte ich auch. Meine Lösung: Ihr erstellt eine Datei Namens /etc/rndc.key, in der Ihr den key entsprechend der Syntax in der dhcpd.conf eintragt - also den kompletten Eintrag "key MYKEY { ... };". Dann nehmt ihr die "key MYKEY { ... };"-Einträge aus den Konfigurationsdateien von dhcpd und bin heraus und setzt an deren Stelle jeweils folgenden Eintrag:

include "/etc/rndc.key";

Alternative: Ihr schaut Euch die Lösung von Schoki an - bei Ihm wird wohl ein richtiger Schlüsselaustausch mit public und private key verwendet.

* = die genutzten Programme sind:

- isc-dhcpd 3.0.1rc11 (Debian Paketname: dhcp3-server)
- bind 9.3.1 (Debian Paketname: bind9)