Archiv/DDNS

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

  1. Ein Terminal öffnen

  2. Einen Editor öffnen

  3. Der Bind-Nameserver

  4. Der ISC-DHCP-Server

Inhaltsverzeichnis
  1. DHCP-Server und DNS-Server mit automatisch...
  2. Erzeugen eines DDNS-Schlüssels
  3. Konfiguration des DHCP
  4. Konfiguration des DNS
  5. Inbetriebnahme
  6. Client-Konfiguration
  7. Zonen-Updates

DHCP-Server und DNS-Server mit automatischem Update (DDNS)

Rechner mit festen IP-Adressen sind eigentlich der Standardfall für DNS. Die Zuordnung von IP-Adresse und Hostname fällt dem Nameserver hier leicht. Beim Einsatz von DHCP würde der ständige Wechsel der IP-Adressen der Hosts viel Arbeit bei der manuellen Pflege des DNS bedeuten. Um dynamisch vergebende Adressen inklusive der Hostnamen durch den für die Domäne zuständigen Nameserver auflösen zu lassen, kann ein DHCP-Server dem DNS-Server Informationen über neu hinzugekommene Rechner schicken. Wie dieses Zusammenspiel zwischen dem ISC-DHCP-Server und dem Bind-DNS-Server funktioniert, beschreibt dieser Artikel.

Erzeugen eines DDNS-Schlüssels

Damit das Update der Zone einigermaßen sicher erfolgt, und nicht jeder nach Belieben die DNS-Zone verändern kann, werden die Übertragungen mit Hilfe eines Schlüssels (Key) signiert, der wie folgt erzeugt wird:

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

Dadurch erhält man zwei Dateien, die beide den generierten Key enthalten. Die Dateinamen beginnen mit Kdhcp_updater und sind im aktuellen Verzeichnis zu finden. Die wichtige ist die mit der Endung .private:

  Private-key-format: v1.2
  Algorithm: 157 (HMAC_MD5)
  Key: Uv4q8GlDJGVFWIdy+ntrwQ==

Aus dieser Datei ist der Buchstabensalat hinter Key: wichtig. Dieser Schlüssel wird jetzt in eine neu angelegte Datei ddns.key geschrieben, die so aussieht:

key DHCP_UPDATER {
         algorithm HMAC-MD5.SIG-ALG.REG.INT;
         secret "pRP5FapFoJ95JEL06sv4PQ==";
};

(Man kann natürlich auch gleich die .private-Datei entsprechend editieren und dann umbenennen. Dabei aber auf die Anführungszeichen und das Semikolon am Ende des Schlüssels achten.)

Die Datei ddns.key wird nun sowohl nach /etc/bind, als auch nach /etc/dhcp3 kopiert, dem Benutzer root und den Gruppen bind bzw. dhcpd zugeordnet, und auf die Dateimodi 640 gesetzt. Die Originaldateien sollten danach gelöscht werden.

Hinweis:

Da die folgenden Schritte alle als root ausgeführt werden müssen, und man als normaler Benutzer teilweise nicht mal die entsprechenden Verzeichnisse betreten darf, empfiehlt sich die Benutzung von sudo -s.

Die Existenz einer funktionierenden Bind9- [3] und DHCPD-Installation [4] wird vorausgesetzt.

Konfiguration des DHCP

Die Datei /etc/dhcpd3/dhcpd.conf unterteilt sich in mehrere Abschnitte. Im allgemeinen Abschnitt, außerhalb von Subnetz-Blöcken o.ä., muss Folgendes eingetragen werden:

  ddns-update-style interim;
  ddns-domainname "olymp.gr"; #diese Domain wird dynamisch aktualisiert
  ignore client-updates;
  update-static-leases off;

ddns-update-style

Diese Option sollte immer auf interim stehen. Die einzige andere bekannte Methode heißt adhoc und ist veraltet.

client-updates

Mit der Option allow client-updates kann der DHCP-Server Clients erlauben, selber ihren Namen beim DNS-Server zu registrieren. Das hat den Vorteil, dass mobile Geräte aus anderen Domains ihren Standort an ihre eigenen Nameserver weitergeben können, anstatt sich in der lokalen Domain anmelden zu müssen. Allerdings muss dafür der jeweilige Server so konfiguriert werden, dass er von dem entsprechenden Rechner auch Updates entgegennimmt. Mit der in diesem Artikel beschriebenen Konfiguration akzeptiert der DNS-Server Updates aber nur vom DHCP-Server, weswegen die client-updates verboten werden sollten.

update-static-leases

Standardmäßig registriert der DHCP-Server keine Namen von Rechnern, die auf statische DHCP-Adressen festgelegt sind. Schaltet man diese Option auf on, ändert sich dieses Verhalten, aber auf Grund von möglichen Problemen rät die Manpage von dhcpd.conf von der Verwendung dieser Option ab. Statische Rechner sollten stattdessen auch statische Namen im DNS erhalten.

In den Subnetz-Blöcken ist nur darauf zu achten, dass der Name der Domain mit einem option domain-name-Statement angegeben wird, sofern diese Option nicht schon in der globalen Sektion existiert.

Für die zu aktualisierenden Forward- und Reverse-Zonen müssen noch die jeweiligen Einträge definiert werden, wer der Nameserver ist, der die Updates empfangen soll, und welcher Schlüssel (Key) zu verwenden ist.

include "/etc/dhcp3/ddns.key";

zone olymp.gr. {                        #Forward-Zone
        primary 127.0.0.1;              #Der DNS-Server, der aktualisiert wird
        key DHCP_UPDATER;
}

zone 84.168.192.in-addr.arpa. {         #Reverse-Zone
          primary 127.0.0.1;
          key DHCP_UPDATER;
}

Die Zonenbezeichnungen müssen mit einem Punkt enden, und es muss der primäre Nameserver der entsprechenden Zone angegeben werden. (Im Beispiel liegen beide Server auf demselben Rechner. Wenn DHCP- und DNS-Server sich auf unterschiedlichen Rechnern befinden, muss das primary-Statement natürlich angepasst werden.)

Konfiguration des DNS

Um dem Nameserver beizubringen, dass er Updates gestatten soll, ist in /etc/bind/named.conf.options (außerhalb des normalen options-Blocks) der gleiche Schlüssel zu platzieren, wie in /etc/dhcpd3/dhcpd.conf:

include "/etc/bind/ddns.key";

Die Zonen-Deklarationen in der Datei /etc/bind/named.conf.local sind durch ein allow-update-Statement zu ergänzen. Außerdem müssen die Pfade auf /var/cache/bind angepasst werden:

zone "olymp.gr"  {
        type master ;
        file "/var/cache/bind/db.olymp.gr" ;
        allow-update { key "DHCP_UPDATER"; };
};

zone "84.168.192.in-addr.arpa" {
        type master ;
        file "/var/cache/bind/db.84" ;
        allow-update { key "DHCP_UPDATER"; };
};

Weiterhin müssen in /var/cache/bind symbolische Links auf die Zonendateien angelegt werden. Der Grund dafür ist folgender: Der Bind-Server möchte gerne für jede Zone, die er dynamisch verwaltet, ein Journal auf der Festplatte anlegen, dass genau so heißt wie die Zonendatei, aber mit der Endung .jnl, also z.B. /etc/bind/db.olymp.gr. Die Berechtigung dazu, nach Belieben Dateien in /etc/bind anzulegen, sollte dem Server aber nicht gestattet werden. Leider genügt es nicht, mit touch entsprechende leere Dateien zu kreieren, da dort noch ein paar binäre Headerinformationen hineingehören. Um dieses Problem zu lösen, muss der Server dazu gebracht werden, die .jnl-Dateien in /var/cache/bind anzulegen, wo er Schreibrechte besitzt. Im übrigen sind Daten, die sich laufend ändern, in der /var-Hierarchie sowieso besser aufgehoben.

Hinweis:

Sollte der DNS vorher nur mit festen IP-Adressen gearbeitet haben, ist dafür zu sorgen, dass die Einträge solcher Rechner, die ab sofort dynamische IPs beziehen sollen, aus den Zonen-Dateien zu löschen sind. Sinnvollerweise ist es nämlich verboten, einen schon vergebenen Namen über DHCP erneut zu registrieren.

Inbetriebnahme

Der DHCP-Server muss jetzt einfach nur neugestartet werden:

/etc/init.d/dhcp3-server restart 

Den Bind-Server kann man sogar im laufenden Betrieb dazu bringen, seine Konfiguration neu einzulesen:

sudo rndc reload 

Wenn alles reibungslos funktioniert, sollten im Syslog jetzt bei der dynamischen Adressvergabe derartige Meldungen auftauchen:

dhcpd: DHCPDISCOVER from 00:11:d8:6f:26:35 via eth0
dhcpd: DHCPOFFER on 192.168.84.50 to 00:11:d8:6f:26:35 (hera) via eth0
named[11749]: client 127.0.0.1#1042: updating zone 'olymp.gr/IN': adding an RR at 'hera.olymp.gr' A
named[11749]: client 127.0.0.1#1042: updating zone 'olymp.gr/IN': adding an RR at 'hera.olymp.gr' TXT
named[11749]: journal file db.olymp.gr.jnl does not exist, creating it
dhcpd: Added new forward map from hera.olymp.gr. to 192.168.84.50
named[11749]: zone olymp.gr/IN: sending notifies (serial 2006081601)
named[11749]: client 127.0.0.1#1042: updating zone '84.168.192.in-addr.arpa/IN': adding an RR at '50.84.168.192.in-addr.arpa' PTR
dhcpd: added reverse map from 50.84.168.192.in-addr.arpa. to hera.olymp.gr.
named[11749]: zone 84.168.192.in-addr.arpa/IN: sending notifies (serial 2004070702)
dhcpd: DHCPREQUEST for 192.168.84.50 (192.168.84.12) from 00:11:d8:6f:26:35 (hera) via eth0
dhcpd: DHCPACK on 192.168.84.50 to 00:11:d8:6f:26:35 (hera) via eth0

Client-Konfiguration

Im Gegensatz bspw. zu Windows sendet Ubuntu standardmäßig nicht den Hostnamen zum DHCP-Server. Das kann man aber sehr leicht mit der folgenden Deklaration in /etc/dhcp3/dhclient.conf ändern:

send host-name "ikarus";

Zonen-Updates

Kompliziert wird es, wenn man noch feste DNS-Namen für einige Rechner verwendet und jetzt die Zonendateien ändern will. Wie man leicht feststellen kann, sind die Links in /var/cache/bind nach einer Weile, spätestens wenn der Server mindestens einmal neugestartet wurde, nicht mehr vorhanden. Stattdessen legt der Server an gleicher Stelle selber Zonendateien an, wo er die aktuellen Daten ablegt.

Methode 1 - ohne große Downtime

Man ändert diese Kopien, muss dafür nur kurzzeitig die Annahme von Updates unterbrechen:

rndc freeze 84.168.192.in-addr.arpa
$EDITOR /var/cache/bind/db.84
rndc unfreeze 84.168.192.in-addr.arpa 

Dadurch veralten natürlich die Originaldateien in /etc/bind, und die Vermischung von festen und dynamisch vergebenen Namen wird mit der Zeit in großen Zonen unübersichtlich.

Methode 2 - mit Downtime

Dateien in /etc/bind editieren, dann die entsprechenden Dateien in /var/cache/bind löschen und die Symlinks wieder anlegen.

$EDITOR /etc/bind/db.84
/etc/init.d/bind9 stop
cd /var/cache/bind
rm db.84 db.84.jnl
ln -s /etc/bind/db.84 .
/etc/init.d/bind9 start 

Dabei gehen natürlich alle Updates verloren. D.h. man sollte das möglichst dann machen, wenn gerade kein Client per DHCP eingeloggt ist.

Methode 3 - eigene Subdomain

Wer die Nachteile der Methoden 1 und 2 nicht in Kauf nehmen möchte, legt sich von Anfang an eine leere Subdomain für seine DHCP-Clients an, deren Service für eine Änderung an den festen Namenszuordnungen nicht unterbrochen werden muss.