|
|
Domain Name Service: DNSDer Domain Name Service dient der Auflösung von Hostnamen zu Internetnummern und umgekehrt und übernimmt damit die Aufgabe, die die Datei /etc/hosts lokal erfüllt. Der Vorteil des DNS liegt auf der Hand: Änderungen müssen nur an einer Stelle durchgeführt werden und gelten für alle Rechner im Netz. Die Bedeutung von DNS reicht aber weit über das lokale Netzwerk hinaus. Der Dreh- und Angelpunkt für einen Zugriff auf das Internet ist die Anbindung an einen DNS-Server. Sobald diese Anbindung erfolgt ist, erhalten Namen wie www.apple.de oder arnold@willemer.de erst die Zuordung zu den richtigen IP-Nummern. Eine Domäne ist nicht unbedingt deckungsgleich mit einem physikalischen Netzwerk, sondern bezeichnet den Bereich, für den der Namensserver eingesetzt wird. Die kleine Firma, die als Beispiel für das Routing diente, hat zwar mehrere TCP/IP-Netze, wird aber sicher nur eine Domäne einrichten. BIND (Berkeley Internet Name Domain) ist die wichtigste Implementation des DNS. Die Konfiguration des Clients erfolgt in resolv.conf und host.conf. Beide Dateien befinden sich im Verzeichnis /etc. Der Server verwendet zwei weitere Dateien je Domäne zur Namens- bzw. zur Nummernauflösung. Als Primary Server bezeichnet man denjenigen Namensserver, der die Autorität für die Domäne hat. Um den Ausfall des Primary Servers abzusichern, stellt man einen Secondary Server ins Netz. Dieser übernimmt die Namensauflösung, wenn der Primary Server ausfällt. Seine Informationen übernimmt der Secondary Server übers Netz vom Primary Server. Damit muss nur der Primary Server aktualisiert werden, wenn beispielsweise neue Rechner hinzukommen. Als weitere Variante gibt es den Cache Only Server. Cache Only Server kopieren sich die Informationen des Primary Servers. Sie werden beispielsweise in Netzen verwendet, die zur Namensauflösung ansonsten eine Wählleitung in Anspruch nehmen müssten.
DNS-Client
Der Client wird als Resolver (engl. resolve: auflösen) bezeichnet. Dabei
ist der Resolver nicht ein eigenständiger Prozess, sondern ist mittels
Funktionsbibliothek quasi in den einzelnen Programmen enthalten.
Alle Programme, die mit dem Namen von Rechnern arbeiten, verwenden den
Systemaufruf In der Datei host.conf legt die Zeile, die mit order beginnt, fest, in welcher Reihenfolge die Namensauflösungsverfahren aufgerufen werden. Im unteren Beispiel wird zuerst in der /etc/hosts nachgesehen und anschließend BIND verwendet. Diese Reihenfolge ist normalerweise auch sinnvoll, da der Zugriff auf die lokalen Datei effizienter als die Suche im Netz ist.
order hosts bind multi on In der Datei /etc/resolv.conf wird definiert, zu welcher Domäne der Rechner gehört und welche Rechner Namensserver sind. Um meinen Arbeitsplatzrechner an den DNS-Dienst des Internet zu koppeln, reicht eine kleine resolv.conf. Beispiel:
domain willemer.edu nameserver 194.25.2.129 # frage den ISP Eine Namensanfrage wird aufgrund der host.conf zunächst lokal in der /etc/hosts bedient und alle anderen Namen würden beim DNS des Providers gesucht. Wollen Sie das TCP/IP-Netz der Beispielfirma an das Internet anbinden, reicht es, eine etwas größere resolv.conf zu verwenden. Dabei wird hier angenommen, die Firma hätte die Domäne firma.de.
domain firma.de nameserver 192.168.108.201 # frage zuerst unseren Server nameserver 194.25.2.129 # dann frage den ISP Zuerst werden die Namen lokal geprüft. Damit gehen lokale Namensauflösungen nicht ins Internet. Erst wenn der Name hier unbekannt ist, wird der DNS-Server des Internet Service Providers (ISP) angefragt. Zu einer vollständigen Anbindung ist natürlich ein geeignetes Routing einzurichten. Da die meisten Firmen über keine eigenen internetfähigen IP-Adressen verfügen, muss noch ein Proxy (siehe S. proxy) oder ein Masquerading (siehe S. masquerading) eingerichtet werden. Beides sind unterschiedliche Mechanismen, um über einen anderen Rechner, der eine Verbindung zum Internet hat, einen Zugang zu erhalten, obwohl der eigene Computer keine internetfähige Adresse hat.
DNS-Server named
Der Serverprozess des DNS heißt Ein Primary Server hat beispielsweise folgende Einträge in der Konfigurationsdatei named.boot:
primary willemer.edu /var/named/name2nr primary 109.168.192.IN-ADDR.ARPA /var/named/nr2name cache . /var/named/named.root forwarders 194.25.2.129 Primary Server wird ein DNS-Server genannt, der die Namen für die Domäne verantwortlich verwaltet. Die erste Zeile drückt aus, dass dieser Rechner ein Primary Server für die Domäne willemer.edu ist. Die Namensinformationen der Domäne werden in der Datei /var/named/name2nr gepflegt. Für den umgekehrten Weg, also aus den Nummern die Namen zu ermitteln, wird nr2name verwendet. Die Cachedatei dient als Basis für das Vorhalten der Namen aus dem Internet. Wie Sie an diese Datei gelangen, wird später beschrieben. Der letzte Eintrag gibt den Namensserver an, an den die Anfrage weitergeleitet werden soll, wenn der Name aus einer fremden Domäne stammt. Beispielsweise kann hier der DNS-Server des Internet Providers stehen. Ein Secondary Server hätte eine ganz ähnliche /etc/named.boot:
directory /var/named secondary willemer.edu 192.168.109.144 name2nr secondary 109.168.192.IN-ADDR.ARPA 192.168.109.144 nr2name Der Unterschied liegt in der ersten Spalte der zweiten und dritten Zeile. Sie besagt, dass dieser Rechner ein Secondary Server für willemer.edu ist. Sie gibt ferner die IP-Nummer des Primary Servers an. Schließlich wird definiert, in welcher lokalen Datei die Informationen vom Primary Server abgelegt werden. Die erste Zeile (directory) ist lediglich eine Abkürzung, damit man den Pfadnamen nicht bei jeder Dateiangabe wiederholen muss. In diesem Beispiel wurde die Datei name2nr in der /etc/named.boot als Namensdatei angegeben. In dieser Datei dient das Semikolon als Kommentarzeichen.
@ IN SOA mail.willemer.edu. root.mail.willemer.edu. ( 200111303 ;serial 360000 ;refresh every 100 hours 3600 ;retry after 1 hour 3600000 ;expire after 1000 hours 360000 ;default ttl is 100 hours ) ; Wer ist der zustaendige Namensserver IN NS gaston.willemer.edu.
; Wer sind die zustaendigen Mailserver IN MX 10 mail.willemer.edu.
localhost IN A 127.0.0.1
; Alle Rechner in der eignenen Domain mail IN A 192.168.109.137 asterix IN CNAME mail gaston IN A 192.168.109.144 powermac IN A 192.168.109.141 Die erste Zeile beginnt mit einem @. Es steht für den lokalen Domänennamen. Hier könnte also auch willemer.edu stehen. Die Abkürzung SOA bedeutet Start Of zone Authority. Die so bezeichnete Zeile gibt den Standardnameserver der Domäne und die E-Mailadresse des Verantwortlichen an. Allerdings wird das @ in der Mailadresse durch einen Punkt ersetzt. gaston ist der Namensserver (IN NS). Mailserver der Domäne ist der Rechner mail (IN MX), der aber auch unter dem Namen asterix im Netz agiert. In der Klammer werden Parameter gesetzt, die Informationen über das Update-Verhalten festlegen. Die Zeile mit dem Kommentar serial kann irgend eine Versionsnummer sein, die allerdings bei jeder Änderung steigen muss. Es hat sich eingebürgert, hier das Datum in der Darstellung YYYYMMDD gefolgt von einer mehrstelligen Zahl zu verwenden, die hochgezählt wird, wenn am selben Tag mehrere Änderungen durchgeführt werden. In diesem Fall wurde die Datei zuletzt am 13.11.2001 und an diesem Tag das dritte Mal geändert. Die anderen Zeilen geben folgende Informationen:
Es werden die Namen mail, gaston und powermac auf IP-Nummern abgebildet und für mail die Nicknames asterix festgelegt. Bei den in dieser Datei vorkommenden Namen wird vom System der Domänenname ergänzt, wenn der Name nicht mit einem Punkt beendet wird. Darum steht hinter mail.willemer.edu ein Punkt. Taucht im Zusammenhang des Tests der Domänname doppelt auf (also so etwas wie max.willemer.edu.willemer.edu) dann fehlt sicher irgendwo ein Punkt. Die Datei nr2name ist das Gegenstück zur Namenstabelle. Hier werden die Hostanteile der IP-Nummern auf Namen abgebildet. Bei einem Class B Netz würden also zwei durch einen Punkt getrennte Nummern in der linken Spalte stehen. Diese Umsetzung von Nummern auf Namen wird im Allgemeinen bei Berechtigungsprüfungen oder bei Anzeigen verbundener Rechner und ähnlichem benötigt.
@ IN SOA mail.willemer.edu. root.mail.willemer.edu. ( 1999062702 ;serial 360000 ;refresh every 100 hours 3600 ;retry after 1 hour 3600000 ;expire after 1000 hours 360000 ;default ttl is 100 hours ) ; Wer ist der zustaendige Namensserver IN NS mail.willemer.edu.
137 IN PTR mail.willemer.edu. 144 IN PTR gaston.willemer.edu.
Testen
Das Testen einer DNS-Konfiguration erfolgt mit dem Befehl
gaston > nslookup Default Server: www-proxy.KI1.srv.t-online.de Address: 212.185.254.170
> www.willemer.de Server: www-proxy.KI1.srv.t-online.de Address: 212.185.254.170
Non-authoritative answer: Name: www.willemer.de Address: 212.227.118.90
> www.apple.de Server: www-proxy.KI1.srv.t-online.de Address: 212.185.254.170
Non-authoritative answer: Name: www.germany.euro.apple.com Address: 17.254.3.153 Aliases: www.apple.de
> exit
Hier wurde in einer Internetsitzung nach den Adressen www.willemer.de und der
Adresse www.apple.de gefragt. Beendet wird die Sitzung mit dem Befehl
Root-Cache DateienFür einen Cache Only Server brauchen Sie eine Ausgangsdatei, in der die Adressen der DNS-Server der Rootdomain. Diese Datei können Sie unter dem Namen named.root per ftp vom Server rs.internic.net mit der Adresse 198.41.0.7 aus dem Verzeichnis domain heruntergeladen. Diese Datei muss als Ausgangsdatei für den Cache verwendet werden. Hier ein Protokoll, wie man die Datei herunterlädt.
gaston # ftp rs.internic.net Connected to rs.internic.net. 220-********************************************************** 220-***** ***** 220-***** InterNIC Public FTP Server ***** 220-***** ***** 220-***** Login with username "anonymous" ***** 220-***** You may change directories to the following: ***** 220-***** ***** 220-***** domain - Root Domain Zone Files ***** 220-***** ***** 220-***** Unauthorized access to this system may ***** 220-***** result in criminal prosecution. ***** 220-***** ***** 220-***** All sessions established with this server are ***** 220-***** monitored and logged. Disconnect now if you do ***** 220-***** not consent to having your actions monitored ***** 220-***** and logged. ***** 220-***** ***** 220-********************************************************** 220- 220 FTP server ready. Name (rs.internic.net:root): anonymous 331 Guest login ok, send your e-mail address as password. Password: 230 User ftp logged in. Access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd domain 250 CWD command successful. ftp> get named.root local: named.root remote: named.root 500 'EPSV': command not understood. 227 Passive Mode (198,41,0,6,177,154) 150 Opening BINARY mode data connection for named.root. 100% |*****************************| 2769 3.91 KB/s 00:00 ETA 226 Transfer complete. 2769 bytes received in 00:00 (3.07 KB/s) ftp> quit 221-You have transferred 2769 bytes in 1 files. 221-Total traffic for this session was 4586 bytes in 1 transfer. 221 Thank you for using the FTP service on rs.internic.net. gaston # Die Datei named.root enthält die DNS-Server der Rootdomain, also die letzte Instanz.
Änderungen zu BIND 8 und 9Ab Version 8 verwendet BIND eine neue Konfigurationsdatei named.conf, die die bisherige Datei named.boot ersetzt. Inhaltlich bleiben die bisherigen Einträge erhalten, sie werden syntaktisch ein wenig aufpoliert und zu Gruppen zusammengefasst.
Zunächst wird in der globalen Gruppe
options { directory "/var/named"; forwarders { 194.25.2.129; }; }; In diesem Abschnitt wird neben dem Verzeichnis auch noch der Namensserver genannt, an den Anfragen weitergeleitet werden sollen, die der hiesige DNS-Server nicht beantworten kann. Neu sind die geschweiften Klammern, in denen die Konfigurationen zusammen gefasst werden und das Semikolon am Ende jeder Definition. Für jede Domäne, die der Server bearbeitet, werden zwei Zonen eingerichtet. Die eine dient der Namensauflösung, die andere der Nummernauflösung. Für die Domäne willemer.edu würden Sie beispielsweise folgende Einträge definieren.
#Namenaufloesung zone "willemer.edu" in { type master; file "willemer.edu"; };
#Nummeraufloesung zone "109.168.192.in-addr.arpa" in { type master; file "named.192.168.109"; };
Hier wird definiert, dass die Namensauflösung für die Domäne willemer.edu
in der Datei named.willemer.edu stattfindet. Dass diese Datei
im Verzeichnis /var/named liegt, wurde bereits in den Der Cache wird in gleicher Weise eingetragen. Allerdings ist dieser nicht vom Typ master, sondern vom Typ hint:
# Einbinden der von rs.internic.net geholten root.named zone "." in { type hint; file "named.root"; }; Die Änderungen in den eigentlichen Konfigurationsdateien sind bei BIND 8 nur gering. Neu ist, dass der TTL-Wert (Time To Live; engl. Lebenszeit) bereits am Anfang der Datei stehen muss. Dieser Wert spezifiziert, wann die Daten von einem anderem Server erneut gelesen werden müssen. In der Version 8 muss er noch nicht zwingend dort stehen, in der Version 9 wird der Eintrag allerdings verlangt. Er befindet sich entweder am Anfang der Datei vor dem SOA-Eintrag in der folgenden Form:
$TTL 1W Oder Sie setzen den Wert im SOA Eintrag direkt vor das Schlüsselwort IN.
@ 86400 IN SOA ns hostmaster ( Fehlt dieser Eintrag, finden Sie in den syslog-Protokollen (siehe S. syslog), also beispielsweise in der messages die Meldung »no TTL specified«. Ein weiterer Fallstrick ist, dass die öffnende Klammer hinter dem SOA-Eintrag noch in der gleichen Zeile sein muss und nicht, wie oben der Übersichtlichkeit halber in der Folgezeile stehen kann. Am TTL-Eintrag zu sehen ist auch die Möglichkeit, die Werte, die bisher nur in Sekunden definiert wurden, nun auch in Stunden (H), Tagen (D) oder Wochen (W) anzugeben.
|
|
Copyright © Rheinwerk Verlag GmbH 2003
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken.
Ansonsten unterliegt das Openbook denselben Bestimmungen wie die gebundene Ausgabe:
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie
Einspeicherung und Verarbeitung in elektronischen Systemen.
Nutzungsbestimmungen | Datenschutz | Impressum
Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de
Cookie-Einstellungen ändern