[[Vorlage(Archiviert)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] [:DNS-Server_Bind: Der Bind-Nameserver] [:ISC-DHCPD: Der ISC-DHCP-Server] }}} [[Inhaltsverzeichnis(2)]] = 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: {{{#!vorlage Befehl 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. {{{#!vorlage 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. {{{#!vorlage 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: {{{#!vorlage Befehl /etc/init.d/dhcp3-server restart }}} Den Bind-Server kann man sogar im laufenden Betrieb dazu bringen, seine Konfiguration neu einzulesen: {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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. {{{#!vorlage Befehl $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. # tag: Netzwerk, Server, dns, dhcp