Inhaltsverzeichnis
Es gibt wenige Themen in der UNIX-Welt, die zu solchen Auseinandersetzungen führen wie das Domain Name System (DNS) und das Dynamic Host Configuration Protocol (DHCP). Nicht alle Argumente, die für oder gegen einzelne Implementationen von DNS und DHCP angeführt werden, sind stichhaltig.
Wir leben in einem modernen Zeitalter, in dem viele Anwender von Informationstechnologie Mobilität und Freiheit anstreben. Besonders Nutzer von MS Windows erwarten, ihr Notebook einfach an eine Netzwerk-Buchse anschließen zu können und dass die Dinge „ einfach funktionieren“.
UNIX-Administratoren haben ein gutes Argument. Vieles aus der normativen Praxis in der MS Windows-Welt grenzt unter Sicherheitsgesichtspunkten im besten Fall an schlechte Gewohnheiten. MS Windows Netzwerk-Protokolle erlauben es Workstations, sich willkürlich an einem Netzwerk anzumelden. Windows 2000 Active Directory registriert Einträge im DNS-Namensraum, die UNIX-Administratoren nur so erstaunen. Willkommen in der neuen Welt!
Der Zweck dieses Kapitels ist, die Konfiguration von Internet Software Consortium-(ISC-) DNS- und DHCP-Servern zu demonstrieren, um dynamische Dienste anzubieten, die kompatibel mit ihren Entsprechungen in den Microsoft Windows 2000 Server-Produkten sind.
Der Zweck dieses Kapitels ist lediglich, ein funktionierendes Beispiel für Konfigurationsdateien anzubieten, und zwar sowohl für DNS- als auch für DHCP-Server. Die verwendeten Beispiele passen zu Konfigurationsbeispielen, die in anderen Bereichen dieses Dokuments angeführt werden.
Dieses Kapitel stellt ausdrücklich kein Tutorial dar, und es soll auch keine Referenz zu DNS und DHCP sein, da dies weit über den Horizont und die Zielsetzung dieses Dokuments hinausginge. Jeder, der detailliertere Materialien zu DNS oder DHCP braucht, sollte die ISC-Website auf http://www.isc.org besuchen. Jene, die eher gedruckten Text bevorzugen, könnten Interesse an den O'Reilly-Publikationen zu diesen Themen finden.
Das Domain Name System ist für das Internet, was das Wasser für das Leben ist. Durch dieses System werden fast alle Informationsressourcen (Host-Namen) in ihre Internet-Protokoll-(IP-)Adressen aufgelöst. Die Windows-Netzwerk-Technologie versucht sehr stark, die Komplexitäten von DNS zu vermeiden, aber leider hat DNS gewonnen. Die Alternative zu DNS, Windows Internet Name Service (WINS), ein Artefakt aus der Zeit, in der NetBIOS-Netzwerke über TCP/IP-Protokoll betrieben wurden, hat nicht nur Skalierungsprobleme, sondern auch einen flachen, nicht-hierarchischen Namensraum, der unverwaltbar wurde, als die Größe und Komplexität der Informationstechnologie-Netzwerke wuchs.
WINS ist eine Microsoft-Implementation des NetBIOS Name Service (NBNS) laut RFC1001/1002. Es erlaubt NetBIOS-Clients (wie Microsoft Windows-Maschinen), einen willkürlichen Maschinen-Namen, den der Administrator oder Benutzer gewählt hat, gemeinsam mit der zugewiesenen IP-Adresse zu registrieren. Durch die Verwendung von WINS können Netzwerk-Client-Maschinen Maschinen-Namen in ihre IP-Adressen auflösen.
Der Bedarf nach einer Alternative zu den Beschränkungen des NetBIOS-Netzwerks führte Microsoft schließlich dazu, DNS und Active Directory zu verwenden. Die neue Implementation von Microsoft versucht, DNS in einer ähnlichen Weise zu verwenden, wie WINS für NetBIOS verwendet wird. Sowohl WINS als auch Microsoft DNS basieren auf dem dynamischen Registrieren von Namen.
MS Windows-Clients können beim Start eine dynamische Namensregistrierung am DNS-Server durchführen. Alternativ ist es dort, wo DHCP zur Zuweisung der IP-Adressen verwendet wird, möglich, Hostnamen und deren IP-Adressen durch den DHCP-Server zu registrieren, sobald der Client ein so genanntes IP-Lease akzeptiert. Zuletzt kann MS DNS Hostnamen via MS WINS auflösen.
Die folgenden Konfigurationen zeigen einen einfachen Dynamic-DNS-Server und einen einfachen DHCP-Server, der zu der DNS-Konfiguration passt.
Die Beispiel-DNS-Konfiguration erfolgt für ein privates Netzwerk im IP-Adressraum 192.168.1.0/24. Der „private class“-Netzwerk-Adressraum ist in RFC1918 festgelegt.
Es wird angenommen, dass dieses Netzwerk hinter einer sicheren Firewall liegen wird. Die folgenden Dateien arbeiten mit ISC BIND Version 9. BIND ist der Berkeley Internet Name Daemon. Die folgenden Konfigurationsdateien werden angeboten:
Die Hauptkonfigurationsdatei /etc/named.conf bestimmt die Lage aller weiteren Konfigurationsdateien. Die Lage und der Name dieser Datei wird im Start-Skript des Betriebssystems festgelegt.
# Quenya.Org configuration file
acl mynet {
192.168.1.0/24;
127.0.0.1;
};
options {
directory "/var/named";
listen-on-v6 { any; };
notify no;
forward first;
forwarders {
192.168.1.1;
};
auth-nxdomain yes;
multiple-cnames yes;
listen-on {
mynet;
};
};
# The following three zone definitions do not need any modification.
# The first one defines localhost while the second defines the
# reverse lookup for localhost. The last zone "." is the
# definition of the root name servers.
zone "localhost" in {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "127.0.0.zone";
};
zone "." in {
type hint;
file "root.hint";
};
# You can insert further zone records for your own domains below.
zone "quenya.org" {
type master;
file "/var/named/quenya.org.hosts";
allow-query {
mynet;
};
allow-transfer {
mynet;
};
allow-update {
mynet;
};
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/var/named/192.168.1.0.rev";
allow-query {
mynet;
};
allow-transfer {
mynet;
};
allow-update {
mynet;
};
};
Die folgenden Dateien liegen alle im Verzeichnis /var/named. Dies ist die Datei /var/named/localhost.zone:
$TTL 1W @ IN SOA @ root ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS @ IN A 127.0.0.1
Die Datei /var/named/127.0.0.zone sieht wie folgt aus:
$TTL 1W @ IN SOA localhost. root.localhost. ( 42 ; serial (d. adams) 2D ; refresh 4H ; retry 6W ; expiry 1W ) ; minimum IN NS localhost. 1 IN PTR localhost.
Die Datei /var/named/quenya.org.host sieht so aus:
$ORIGIN . $TTL 38400 ; 10 hours 40 minutes quenya.org IN SOA marvel.quenya.org. root.quenya.org. ( 2003021832 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS marvel.quenya.org. MX 10 mail.quenya.org. $ORIGIN quenya.org. frodo A 192.168.1.1 marvel A 192.168.1.2 ; mail CNAME marvel www CNAME marvel
Die Datei /var/named/192.168.1.0.rev sieht so aus:
$ORIGIN . $TTL 38400 ; 10 hours 40 minutes 1.168.192.in-addr.arpa IN SOA marvel.quenya.org. root.quenya.org. ( 2003021824 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 38400 ; minimum (10 hours 40 minutes) ) NS marvel.quenya.org. $ORIGIN 1.168.192.in-addr.arpa. 1 PTR frodo.quenya.org. 2 PTR marvel.quenya.org.
Die oben gezeigten Dateien wurden von einem vollständig funktionierenden System kopiert. Alle dynamisch registrierten Einträge wurden entfernt. Zusätzlich zu diesen Dateien wird BIND Version 9 für jede der dynamischen Registrationsdateien eine Datei anlegen, die die Endung .jnl hat. Machen Sie sich nicht an diesen Dateien zu schaffen, auch nicht an den .jnl-Dateien!
Folgende Datei wird mit dem ISC DHCP Server Version 3 verwendet. Die Datei liegt in /etc/dhcpd.conf:
ddns-updates on;
ddns-domainname "quenya.org";
option ntp-servers 192.168.1.2;
ddns-update-style ad-hoc;
allow unknown-clients;
default-lease-time 86400;
max-lease-time 172800;
option domain-name "quenya.org";
option domain-name-servers 192.168.1.2;
option netbios-name-servers 192.168.1.2;
option netbios-dd-server 192.168.1.2;
option netbios-node-type 8;
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.60 192.168.1.254;
option subnet-mask 255.255.255.0;
option routers 192.168.1.2;
allow unknown-clients;
}
Im obigen Beispiel werden IP-Adressen zwischen 192.168.1.1 und 192.168.1.59 für fixe (üblicherweise als hard-wired bezeichnete) IP-Adressen reserviert. Die Adressen zwischen 192.168.1.60 und 192.168.1.254 werden zur dynamischen Verwendung bereitgestellt.