orm@doc-tcpip.org

Erstellt: Mai 2001 - Letzte Modifikation: Nov 2003

[ Main | Local ]


Wie Namensauflösung funktioniert



Die RFCs zum Thema

Alle RFC gibt es beim RFC-Editor (www.rfc-editor.org)

RFC 1034 * Domain names - concepts and facilities
RFC 1035 * Domain names - implementation and specification
RFC 3008 * Domain Name System Security (DNSSEC) Signing Authority
RFC 3007 * Secure Domain Name System (DNS) Dynamic Update
RFC 2931 * DNS Request and Transaction Signatures ( SIG(0)s )
RFC 2929 * Domain Name System (DNS) IANA Considerations
RFC 2845 * Secret Key Transaction Authentication for DNS (TSIG)
RFC 2782 * A DNS RR for specifying the location of services (DNS SRV)
RFC 2317 * Classless IN-ADDR.ARPA delegation
RFC 2182 * Selection and Operation of Secondary DNS Servers
RFC 2181 * Clarifications to the DNS Specification
RFC 2136 * Dynamic Updates in the Domain Name System (DNS UPDATE)
RFC 1996 * A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
RFC 1995 * Incremental Zone Transfer in DNS
RFC 1912 * Common DNS Operational and Configuration Errors
RFC 1886 * DNS Extensions to support IP version 6

Literatur zum Thema

DNS and BIND, Cricket Liu & Paul Albitz; ISBN 0-596-00158-4, O'Reilly.
Ein guter Link: DNS Resources Directory (www.dns.net/dnsrd).

Warum macht man Namensauflösung?

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.



DNS komprimiert

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 - Berkely Internet Name Deamon

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.

Festlegen der Reihenfolge der Services

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.


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )