| orm@doc-tcpip.org | Erstellt: Mai 2001 - Letzte Modifikation: Nov 2003 |
Es geht um zwei Dinge: einmal ist es für Menschen doch leichter, sich Worte zu merken - besonders, wenn die Namen die Organisation der Arbeitsgruppe wiederspiegeln (wenn ich weiss, das mein Gateway "gateway" heisst und mein DHCP-Server "dhcp-serv", dann ist das sehr schön). Zum anderen läßt sich so eine weitere Ebene in die Struktur einfügen: Wenn mein NFS-Server "192.168.1.5" heißt, dann kann ich die Maschine nicht einfach ersetzen. Ist er dagegen im Netz als "Dumpy" bekannt, dann kann ich mittels des DNS den Namen "Dumpy" an jede IP binden, bin also deutlich unabhängiger von der Hardware.
Die Zuordnung von Name und IP-Adresse kann auf verschiedenen Wegen erfolgen. In einem kleinen LAN kann man problemlos die /etc/hosts benutzen. Jeder Host des Netzes muß auf jeder Maschine mit IP und Namen erfaßt sein. Das bedeutet, das alle Rechner des Netzes die gleich Kopie der /etc/hosts brauchen -zumindest muß der Inhalt identisch sein. Mit mehr Maschinen und mehr Administratoren wird das schnell schwierig, ganz zu schweigen vom Internet mit mehreren Millionen an Hosts oder Webadressen. Für größere LANs kann man NIS - Network Information Service - einsetzen, was auf eine Verteilung einer zentralen /etc/hosts herausläuft. Im Internet geht an einer verteilten Datenbank wie dem DNS kein Weg vorbei.
Die Clientseite sieht folgendermaßen aus: Auf jedem System gibt es einen Satz an Libary-Routinen, die es den Applikationen erlauben, Namen in IP-Adressen aufzulösen - und umgekehrt IP-Adressen in Namen. Diese Sammlung an Routinen nennt man den Resolver. Für die Applikation ist das ganze völlig transparent - es ist keine Kenntnis nötig, ob die "Files" (/etc/hosts) oder NIS bzw. DNS benutzt werden.
Das DNS ist eine hierarchische und im Netz verteilte Datenbank. Für jeden Bereich gibt es Server, die diesen Bereich kennen (und wo ein Administrator sitzt, der dafür verantwortlich zeichnet). Diese Server sind in ein hierarchisches System mit einer fiktiven Wurzel eingegliedert. Diese Wurzel ist die 15 - 20 Server umfaßende Gruppe der Root Server. Diese Server kennen die Adressen aller Server der ersten Ebene, also die Domänen .com, .org, .de etc.. Für jede dieser Zonen gibt es dann wieder zuständige Server, jetzt auf der zweiten Ebene, z.B. ibm.com, mit.edu oder siemens.de. Diese verteilen dann weiter nach unten, z.B. nach Lokationen wie mainz.ibm.com. Irgendwann erreicht eine Anfrage jedenfalls einen Server, der für diese Domäne authoritär ist -hier wird dann entweder die Zuordnung IP/Name gemacht, oder es wird mitgeteilt, das es diesen Namen/Adresse nicht gibt.
Also sind Nameserver immer nur für einen Teil des ganzen Namensraumes verantwortlich (authoritär). Kann ein authoritärer Server eine Anfrage nicht bedienen (also weder im positiven noch im negativen Sinn), dann gibt er SERVFAIL zurück, was auf Client (resolver) Seite meist ein name server lookup failure auslöst. Das weist immer auf einen Konfigurationsfehler hin, der aber auch auf einem anderen Server liegen kann (es sollte immer zumindest eine Antwort kommen). Falls der Server sieht, das entweder die Domäne oder der Name nicht existiert, gibt er nonexistent host or domain zurück.
BIND ist nichts anderes als eine (von vielen) Implementationen des DNS. Es ist aber die meistverbreiteste, ich würde die anderen Implementationen eher esoterisch nennen. Die meisten Resolver-Routinen basieren auf dem BIND-Code. Der Server-Code ist frei erhältlich und wird mit fast allen Unixen mitgeliefert. Leider ist der Code sehr inhomogen und von Sicherheitslöchern geplagt, als guter Admin sollte man ein scharfes Auge auf CERT-Alerts (CERT - Computer Emergency Response Team) (www.cert.org) haben. Und letzter Patchstand ist selbstverständlich. Es gibt bind 4.9.3 (nur IPv4) und bind 8.2.3 (mit IPv6). Beide unterscheiden sich im Prinzip nur im Umfang der Features. Der Einsatz von bind 9 hat gerade begonnen. Das ist ein kompleter Rewrite unter Aufsicht des ISC - Internet Software Consortium (www.isc.org) . Bei Neuinstallationen sollte man wohl bind 9 bevorzugen, dabei die Features durchgehen und einsetzen.
Standard, also hardcoded, ist folgender Ablauf: zuerst DNS, dann NIS und
zum Schluß FILES, also die /etc/hosts. Dabei werden selbsverständlich
die Timeouts der einzelnen Dienste durchlaufen.
Systemweit kann man das in der /etc/netsvc.conf einstellen. Jeder User kann das
wieder über seine NSORDER Umgebungsvariable ändern. Die netsvc.conf
hat folgende Form: hosts=service1,service2,service3.
Die NSORDER VAriable wird genauso gesetzt:
NSORDER=service1,service2,service3
Mit dem Keyword "auth" kann man einen der Services authoritär machen. Es
wird dann nur dieser Service benutzt.
Daneben gibt es noch das File /etc/irs.conf. Das steht in der Hierarchie am
untersten Punkt, wird also von netsvc.conf und NSORDER überspielt. Es lassen sich neben der Namensauflösung auch andere Services konfigurieren und
miteinander verketten. Dazu gibt es Keywörter wie "continue" oder "merge".
Beispiele finden sich in der Man-page.
Es sei nochmal darauf hingewiesen, das diese Files stark abhängig sind vom
Betriebsystem. So erfüllen unter Solaris, Linux oder *BSD Files wie
nsswitch.conf oder host.conf diese Aufgaben.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL