

<pre>
= DHCP-Server mit DNS =

Dieser Artikel beschreibt ein älteres Setup, das wir im KrefixLinux-Router benutzt haben. Eine für normale Heimnetze viel einfachere Lösung bietet das neuere Paket DnsMasq. Die hier verwendete Kombination aus Bind und dem DHCP-Server vom ISC ist für sehr komplexe Aufgabenstellungen immer noch die leistungsfähigere, aber DnsMasq sollte eigentlich für jeden, der einen Server in seinem Heim- oder Firmennetz benötigt, die bessere Wahl sein.

Ein DHCP-Server mit einer herkömmlichen Konfiguration gibt an neue,
unbekannte Clients lediglich IP-Adressen aus einem vorgegebenen
Adresspool. Bei unserem Projekt KrefixLinux wollen wir jedoch, dass
das gesamte Netz komplett automatisch konfiguriert werden kann.
Dazu gehört, daß für einen neuen Client auch ein Name vergeben
wird, der dann auch vom Nameserver richtig aufgelöst wird.

Dabei sind folgende Schritte nötig:
* Vergabe einer IP-Adresse
* automatische Erzeugung eines Namens und Übergabe an den Client
* Übergabe des Namens an den Nameserver
* Konfiguration des Nameservers, damit er diesen Namen annimmt

== Benutzte Softwarepakete ==

Wir benutzen für KrefixLinux die Debian-Pakete '''dhcp3-server'''
und '''bind9''', die beide vom [http://www.isc.org Internet
Software Consortium] kommen. Diese beiden arbeiten gut miteinander
und auch mit dem von uns verwendeten DHCP-Client (siehe
NetzKonfigMitDHCP) zusammen. Außerdem stellt ''bind'' sowieso den
de-facto-Standard für DNS-Server im Internet dar.

Leider ist die (hier beschriebene) Konfiguration der Server des ISC
nicht gerade einfach und übersichtlich. Deshalb an dieser Stelle
eine einfache Alternative, die im Wesentlichen in einer Datei
konfiguriert wird: Das Debian-Paket '''DnsMasq''' enthält einen
DNS-Proxy. Er kann die ''/etc/hosts''-Datei des Servers auslesen
und benutzt die IP-Adresse/Name-Zuordnung für die lokale Domain.
Und IP-Adressen per DHCP vergeben kann er auch! Das wäre sicher
eine Alternative für KrefixLinux2...

Nach Installation des dhcp3-server-Paketes muss die Datei
''/etc/dhcp3/dhcpd.conf'' angepasst werden. Einfache Beispiele sind
darin bereits enthalten, so daß wir keine besonderen Probleme
hatten. Für kompliziertere Dinge ist dieser Server allerdings auch
zu haben. Dieser DHCP-Server ist wohl auch der einzige, der direkt
(ohne Hilfs-Skripte) einen Nameserver updaten kann, wenn neue Hosts
angemeldet werden.

== Vergabe einer IP-Adresse ==

Mit folgendem Ausschnitt aus der ''dhcpd.conf'' vergeben wir unsere
IP-Adressen:

 default-lease-time 86400;  # ein Tag
 max-lease-time 604800;     # eine Woche

 subnet 192.168.200.0 netmask 255.255.255.0 {
   range 192.168.200.2 192.168.200.127;
   option host-name = concat(&quot;alpha&quot;, binary-to-ascii(
                        10,8,&quot;&quot;,substring(leased-address,3,1)));
   option routers 192.168.200.1;
 }
 subnet 192.168.201.0 netmask 255.255.255.0 {
   range 192.168.201.2 192.168.201.127;
   option host-name = concat(&quot;beta&quot;, binary-to-ascii(
                        10,8,&quot;&quot;,substring(leased-address,3,1)));
   option routers 192.168.201.1;
 }
 subnet 192.168.202.0 netmask 255.255.255.0 {
   range 192.168.202.2 192.168.202.127;
   option host-name = concat(&quot;gamma&quot;, binary-to-ascii(
                        10,8,&quot;&quot;,substring(leased-address,3,1)));
   option routers 192.168.202.1;
 }
 subnet 192.168.203.0 netmask 255.255.255.0 {
   range 192.168.203.2 192.168.203.127;
   option host-name = concat(&quot;delta&quot;, binary-to-ascii(
                        10,8,&quot;&quot;,substring(leased-address,3,1)));
   option routers 192.168.203.1;
 }

Dabei benutzen wir für KrefixLinux immer 4 Interfaces, weil das die
von uns gewählte Höchstzahl an Interfaces ist. Bei der Anwendung
für einen speziellen Rechner braucht man natürlich nur soviele
subnet-Deklarationen wie Netzwerkkarten. Falls eine dieser
subnet-Deklarationen kein passendes Interface findet (weil es z.B.
gar nicht so viele Interfaces gibt), wird die Deklaration einfach
verworfen. Nachdem der Server selber die Adresse 192.168.20x.1 hat,
werden die restlichen Clients jetzt auf die Adressen ...20x.2 bis
...20x.127 verteilt. (Die Adressen 128-255 behalten wir uns vor,
falls ein Admin Adressen fest vergeben will.) 

== Erzeugung des Namens ==
Zur dynamischen Erzeugung von Namen hat der dhcp eine Art
Skriptsprache, die mächtig genug ist, um alle benötigten Ausdrücke
auszuwerten. Diese ist auf der '''dhcp-eval'''-Manpage beschrieben.
Um nun unsere Namen zu erzeugen, benutzen wir folgende Zeile:

 option host-name = concat(&quot;alpha&quot;,
binary-to-ascii(10,8,&quot;&quot;,substring(leased-address,3,1)));

Die host-name-Zeile wandelt die letzte Zahl der vergebenen
IP-Adresse in einen Textstring und hängt diesen an das Wort &quot;alpha&quot;
(den Basisnamen für unsere Clients) an. So heisst z.B. der Rechner
mit der IP-Adresse ''192.168.200.42'' dann ''alpha42''. In unserer
Konfiguration haben wir für verschiedene Netzwerkkarten (die
jeweils andere IP-Subnetze versorgen) dann verschiedene Basisnamen
benutzt.

== Übergabe des Namens an den Client ==

Die folgenden Optionen haben wir in unserer Konfiguration auch noch
eingesetzt. Durch diese meldet der DHCP-Server dem angegebenen
Nameserver (auf 127.0.0.1) alle Namen, die er vergibt.

 ddns-update-style interim;
 ddns-domainname &quot;intranet&quot;;
 update-static-leases true;
 ignore client-updates;
 authoritative;

 zone intranet. {
   primary 127.0.0.1;
 }
 zone 168.192.in-addr.arpa. {
   primary 127.0.0.1;
 }

== Konfiguration des Nameservers ==

Wie im folgenden Ausschnitt der ''named.conf'' gezeigt, muss im
Nameserver lediglich die '''allow-update'''-Direktive gesetzt
werden:

 zone &quot;intranet&quot; {
   type master;
   file &quot;/etc/bind/db.intranet&quot;;
   allow-update { 127.0.0.1; };
 };
 
 zone &quot;168.192.in-addr.arpa&quot; {
   type master;
   file &quot;/etc/bind/db.192.168&quot;;
   allow-update { 127.0.0.1; };
 };

== Sicherheit ==

Es ist natürlich wichtig, daß nicht irgendein anderes Programm
einfach den Nameserver manipuliert. Andere Beispiel-Lösungen und
die manpage zeigen, wie man eine Authentifizierung benutzen kann,
um sicherzustellen, daß nur der DHCP-Server dies kann. Dadurch, das
wir updates nur von der localhost-Adresse 127.0.0.1 zulassen, haben
wir bereits den wichtigsten Schritt getan. Updates von anderen als
dem eigenen Rechner aus sollten eigentlich nie nötig sein. Dennoch
haben jetzt alle Benutzer und Dienste auf diesem Rechner die
Möglichkeit, die angegebenen DNS-Zonen zu verändern.

== Links ==
* http://www.pl-berichte.de/t_netzwerk/dhcpunddns.html - Artikel
über dieses Thema


[{Tag Netzwerk ThinClient}]

</pre>