Damit die Namen weltweit eindeutig sind und nicht alle von einer zentralen Instanz verwaltet werden müssen, bildet man Hierarchien, sogenannte Domains. Jede Ebene der Hierarchie bekommt einen Namen. Diese Namen verbindet man mit einem Punkt von der tiefsten bis zur höchsten Ebene :
google.com
elug.de
dida.physik.uni-essen.de
Die Namen der Computer setzt man davor :
www.google.com
www.elug.de
agnes.dida.physik.uni-essen.de
Solche Namen nennt man voll qualifizierte Domain-Namen bzw.
Fully Qualified Domain Names (FQDN). Die Domains der höchsten
Ebene nennt man Toplevel Domains, darunterliegende
Subdomains. Hierarchisch zusammenhängende Domains nennt man
Zonen.
Die Zuordnung zwischen diesen Namen und den IP-Adressen der Computer erfolgt durch einen Domain Name Service (DNS). Dieser wird durch Domain Name Server realisiert.
Das Verfahren zur Umwandlung eines FQDN in eine Adresse nennt man Name Resolution oder Namensauflösung.
Das Ergebnis ist eine Liste von Resource Records (RR). Dies können nicht nur IP-Adressen von anderen Computern sein, sondern auch andere Informationen. Diese wählt man mit der Typangabe aus :
| Typ | Information |
|---|---|
A |
IP-Adresse eines Computers |
PTR |
FQDN eines anderen Computers |
NS |
FQDN eines Computers mit einem anderen Name Server |
MX |
FQDN eines Computers mit einem Mail-Server |
CNAME |
Alias-Name (FQDN) eines Computers |
Ein großes Problem ist, daß es keinen Name Server gibt, der alle Domains kennt. Um eine Adresse zu finden ist es daher nötig, zunächst einen Name Server zu finden, der die gewünschte Domain kennt. Dazu gibt es Root Name Server. Diese kennen alle Name Server aller Toplevel Domains. Man fragt also zunächst einen der Root Name Server nach Name Servern der gewünschten Toplevel Domain. Alle diese Name Server kennen wiederum die Name Server aller darunterliegenden Domains. Man wählt also einen Name Server aus und fragt ihn wiederum nach Name Servern der Domain der nächsten Ebene usw., bis man einen Name Server gefunden hat, der die Computer der gewünschten Domain kennt. Diesen fragt man schließlich nach der Adresse des gewünschten Computers.
Es bleibt noch das Problem, einen Root Name Server zu finden. Dazu kann man einfach einen vorhandenen Name Server fragen. Das Ergebnis kann sinnvollerweise in einer Datei gespeichert werden, da es immer wieder benötigt wird. Ein Name Server verwendet eine solche Datei als Start-Information. Die Datei sollte gelegentlich aktualisiert werden, obwohl Änderungen selten zu erwarten sind.
host soll als Hilfe dienen.
Für einen Browser wird die Adresse des Computers www.elug.de
gesucht. Zunächst muß mit Hilfe irgend eines Name Servers ein
Root Name Server gesucht werden.
$ host -v -t ns .
rcode = 0 (Success), ancount=13
The following answer is not authoritative:
. 325223 IN NS J.ROOT-SERVERS.NET
. 325223 IN NS K.ROOT-SERVERS.NET <--
. 325223 IN NS L.ROOT-SERVERS.NET
. 325223 IN NS M.ROOT-SERVERS.NET
. 325223 IN NS I.ROOT-SERVERS.NET
. 325223 IN NS E.ROOT-SERVERS.NET
. 325223 IN NS D.ROOT-SERVERS.NET
. 325223 IN NS A.ROOT-SERVERS.NET
. 325223 IN NS H.ROOT-SERVERS.NET
. 325223 IN NS C.ROOT-SERVERS.NET
. 325223 IN NS G.ROOT-SERVERS.NET
. 325223 IN NS F.ROOT-SERVERS.NET
. 325223 IN NS B.ROOT-SERVERS.NET
Additional information:
J.ROOT-SERVERS.NET 411623 IN A 198.41.0.10
K.ROOT-SERVERS.NET 411623 IN A 193.0.14.129 <--
L.ROOT-SERVERS.NET 411623 IN A 198.32.64.12
M.ROOT-SERVERS.NET 411623 IN A 202.12.27.33
I.ROOT-SERVERS.NET 411623 IN A 192.36.148.17
E.ROOT-SERVERS.NET 411623 IN A 192.203.230.10
D.ROOT-SERVERS.NET 411623 IN A 128.8.10.90
A.ROOT-SERVERS.NET 411623 IN A 198.41.0.4
H.ROOT-SERVERS.NET 411623 IN A 128.63.2.53
C.ROOT-SERVERS.NET 411623 IN A 192.33.4.12
G.ROOT-SERVERS.NET 411623 IN A 192.112.36.4
F.ROOT-SERVERS.NET 411623 IN A 192.5.5.241
B.ROOT-SERVERS.NET 411623 IN A 128.9.0.107
Es soll der Root Name Server K.ROOT-SERVERS.NET (193.0.14.129)
verwendet werden. Dieser wird nach der gewünschten Adresse gefragt.
$ host -v -r -a www.elug.de. 193.0.14.129
Using domain server 193.0.14.129:
rcode = 0 (Success), ancount=0
For authoritative answers, see:
de 172800 IN NS AUTH03.NS.DE.UU.NET
de 172800 IN NS DNS.DENIC.de <--
de 172800 IN NS SUNIC.SUNET.SE
de 172800 IN NS DNS.NIC.XLINK.NET
de 172800 IN NS SSS-AT.DENIC.de
de 172800 IN NS SSS-NL.DENIC.de
de 172800 IN NS DNS2.DENIC.de
Additional information:
AUTH03.NS.DE.UU.NET 172800 IN A 192.76.144.16
DNS.DENIC.de 172800 IN A 194.246.96.79 <--
SUNIC.SUNET.SE 172800 IN A 192.36.125.2
DNS.NIC.XLINK.NET 172800 IN A 193.141.40.42
SSS-AT.DENIC.de 172800 IN A 193.171.255.34
SSS-NL.DENIC.de 172800 IN A 193.0.0.237
DNS2.DENIC.de 172800 IN A 194.246.96.49
Der Root Name Server kennt (natürlich) die gewünschte Adresse nicht.
Aber er liefert Informationen über Name Server der Toplevel Domain
de. Also suchen wir einen aus, z. B.
DNS.DENIC.de (194.246.96.79), und fragen ihn.
$ host -v -r -a www.elug.de. 194.246.96.79
Using domain server 194.246.96.79:
rcode = 0 (Success), ancount=0
For authoritative answers, see:
elug.de 86400 IN NS domain.gdata.de <--
elug.de 86400 IN NS ns2.tmag.de
Additional information:
domain.gdata.de 86400 IN A 212.23.138.18 <--
Auch er weiß die Antwort nicht, verweist uns aber wiederum an Name Server
der Domain elug.de. Wir wählen domain.gdata.de
(212.23.138.18), da wir nur von ihm die IP-Adresse direkt bekommen.
(Das spart uns weitere Anfragen für ns2.tmag.de.)
$ host -v -r -a www.elug.de. 212.23.138.18
Using domain server 212.23.138.18:
rcode = 0 (Success), ancount=1
www.elug.de 172800 IN CNAME adele.gerwinski.de <--
For authoritative answers, see:
elug.de 172800 IN NS domain.gdata.de
elug.de 172800 IN NS ns2.tmag.de
Additional information:
domain.gdata.de 172800 IN A 212.23.138.18
ns2.tmag.de 49956 IN A 62.208.139.3
Ungünstigerweise ist www.elug.de ein Alias für
adele.gerwinski.de.
Das Programm erkennt dies und stellt automatisch eine neue Anfrage
nach adele.gerwinski.de zum selben Name Server.
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
adele.gerwinski.de 10977 IN A 217.69.76.193 <--
For authoritative answers, see:
de 122995 IN NS AUTH03.NS.DE.UU.NET
de 122995 IN NS DNS.DENIC.de
de 122995 IN NS SUNIC.SUNET.SE
de 122995 IN NS DNS.NIC.XLINK.NET
de 122995 IN NS SSS-AT.DENIC.de
de 122995 IN NS SSS-NL.DENIC.de
de 122995 IN NS DNS2.DENIC.de
Additional information:
AUTH03.NS.DE.UU.NET 6889 IN A 192.76.144.16
DNS.DENIC.de 30160 IN A 194.246.96.79
SUNIC.SUNET.SE 52002 IN A 192.36.125.2
DNS.NIC.XLINK.NET 53203 IN A 193.141.40.42
SSS-AT.DENIC.de 54211 IN A 193.171.255.34
SSS-NL.DENIC.de 60454 IN A 193.0.0.237
DNS2.DENIC.de 55900 IN A 194.246.96.49
Der Name Server kennt die Adresse, obwohl sie nicht zur Domain
elug.de gehört und liefert sie uns.
Würde er sie nicht kennen, so müßten wir die Suche wiederum
bei einem Name Server der Domain de fortsetzen.
Wir wählen also wieder DNS.DENIC.de (194.246.96.79)
und fragen erneut.
$ host -v -r -a adele.gerwinski.de. 194.246.96.79
Using domain server 194.246.96.79:
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
adele.gerwinski.de 86400 IN A 217.69.76.193 <--
For authoritative answers, see:
gerwinski.de 86400 IN NS adele.gerwinski.de <--
gerwinski.de 86400 IN NS ns2.openit.de
Additional information:
adele.gerwinski.de 86400 IN A 217.69.76.193 <--
ns2.openit.de 86400 IN A 217.10.64.100
Er kennt die Adresse, weil sie offenbar selber ein Name Server für die
Domain gerwinski.de ist.
Nun wollen wir alle Informationen über den Computer sehen.
$ host -v -r -a adele.gerwinski.de. 217.69.76.193
Using domain server 217.69.76.193:
rcode = 0 (Success), ancount=1
adele.gerwinski.de 10000 IN A 217.69.76.193
For authoritative answers, see:
gerwinski.de 10000 IN NS adele.gerwinski.de
gerwinski.de 10000 IN NS ns2.openit.de
Additional information:
adele.gerwinski.de 10000 IN A 217.69.76.193
ns2.openit.de 29590 IN A 217.10.64.100
Ein Name Server kann auch als Cacheing Name Server arbeiten. Hierbei wird nicht nur der oben beschriebene Ablauf durchgeführt, sondern es werden auch alle Antworten gespeichert, sodaß spätere Anfragen teilweise selbst beantwortet werden können. Genau dies besagt die obige Meldung "The following answer is not authoritative".
Außerdem kann der Name Server die Ergebnisse von Anfragen, die er an
andere Name Server weitergeleitet hat, ebenfalls im Cache speichern.
Das is auch der Grund, warum der Name Server der Domain elug.de
eine Antwort für die Domain gerwinski.de wußte.
Dann kann einfach ein Name Server direkt nach den gewünschten Informationen gefragt werden :
$ host -v -a www.elug.de.
rcode = 0 (Success), ancount=1
www.elug.de 172800 IN CNAME adele.gerwinski.de
For authoritative answers, see:
elug.de 172800 IN NS domain.gdata.de
elug.de 172800 IN NS ns2.tmag.de
Additional information:
domain.gdata.de 172800 IN A 212.23.138.18
ns2.tmag.de 41296 IN A 62.208.139.3
rcode = 0 (Success), ancount=1
The following answer is not authoritative:
adele.gerwinski.de 42870 IN A 217.69.76.193
For authoritative answers, see:
de 104363 IN NS AUTH03.NS.DE.UU.NET
de 104363 IN NS DNS.DENIC.de
de 104363 IN NS SUNIC.SUNET.SE
de 104363 IN NS DNS.NIC.XLINK.NET
de 104363 IN NS SSS-AT.DENIC.de
de 104363 IN NS SSS-NL.DENIC.de
de 104363 IN NS DNS2.DENIC.de
Additional information:
AUTH03.NS.DE.UU.NET 5310 IN A 192.76.144.16
DNS.DENIC.de 66697 IN A 194.246.96.79
SUNIC.SUNET.SE 14377 IN A 192.36.125.2
DNS.NIC.XLINK.NET 18857 IN A 193.141.40.42
SSS-AT.DENIC.de 41582 IN A 193.171.255.34
SSS-NL.DENIC.de 22638 IN A 193.0.0.237
DNS2.DENIC.de 24318 IN A 194.246.96.49
Das gerade beschriebene Verfahren nennt man Forward Mapping.
in-addr.arpa eingerichtet. Diese bildet die Reverse Zone.
Man wandelt eine IP-Adresse in einen entsprechenden Pseudo-Domain-Namen um,
indem man die 4 Teile der Adresse umdreht und dann .in-addr.arpa
anhängt.
Die Adresse des Computers adele.gerwinski.de (217.69.76.193)
hätte also den Pseudo-FQDN 193.76.69.217.in-addr.arpa.
Über diesen Adress-FQDN läßt sich nach obigem Verfahren der
FQDN des Computers hearusfinden.
Der einzige Unterschied ist, daß man am Ende nach Resource Records
nicht des Typs A, sondern PTR sucht.
Das Reverse Mapping kann zur Prüfung einer Adresse verwendet werden.
Beispielsweise versucht der rlogind-Server die Echtheit der
Adresse eines anfragenden rlogin-Clients zu prüfen :
Man kann auch Angreifer lokalisieren, indem man nach den FQDN von IP-Adressen sucht, die man in Log Files findet. Daran kann man erkennen, über welchen ISP der Angreifer kommt. Dies kann man dann zusammen mit der IP-Adresse und der Uhrzeit dem ISP mitteilen, der dann wiederum eine Möglichkeit hat, über die Einwahlnummer den Angreifer zu finden.
Man bestimmt einen der Server als Primary Name Server. Alle anderen sind dann Secondary Name Server.
Änderungen in den Resource Records nimmt man in der Datenbank des Primary Name Servers vor. Die Secondary Name Server fragen ihn regelmäßig nach Änderungen und bekommen dann aktuelle Informationen geliefert.
Beispiel :
Es soll ein Name Server für die Domain tc.elug.de aufgestellt
werden. Der Computer heißt nameserver.tc.elug.de und habe
die IP-Adresse 192.168.128.1. Die Domain soll außerdem
das Netz 192.168.128.X darstellen. Als weitere Computer gebe es
www (X.2), dbserver (X.3) und
mailserver (X.4) in der Domain.
Der Name Server braucht dazu mindestens folgende Resource Records :
| Domain-Name | Typ | Information |
|---|---|---|
tc.elug.de. |
NS |
nameserver.tc.elug.de. |
tc.elug.de. |
MX |
mailserver.tc.elug.de. |
nameserver.tc.elug.de. |
A |
192.168.128.1 |
www.tc.elug.de. |
A |
192.168.128.2 |
dbserver.tc.elug.de. |
A |
192.168.128.3 |
mailserver.tc.elug.de. |
A |
192.168.128.4 |
128.168.192.in-addr.arpa. |
NS |
nameserver.tc.elug.de. |
1.128.168.192.in-addr.arpa. |
PTR |
nameserver.tc.elug.de. |
2.128.168.192.in-addr.arpa. |
PTR |
www.tc.elug.de. |
3.128.168.192.in-addr.arpa. |
PTR |
dbserver.tc.elug.de. |
4.128.168.192.in-addr.arpa. |
PTR |
mailserver.tc.elug.de. |
Wird der Name Server in einem LAN benutzt, sind noch folgende Resource Records hilfreich :
| Domain-Name | Typ | Information |
|---|---|---|
localhost.tc.elug.de. |
A |
127.0.0.1 |
1.0.0.127.in-addr.arpa. |
PTR |
localhost. |
0.0.127.in-addr.arpa. |
NS |
nameserver.tc.elug.de. |
Für das Forward Mapping müssen in allen Name Servern der Domain
elug.de folgende Resource Records eingetragen werden :
| Domain-Name | Typ | Information |
|---|---|---|
tc.elug.de. |
NS |
nameserver.tc.elug.de. |
nameserver.tc.elug.de. |
A |
192.168.128.1 |
Für das Reverse Mapping muß in allen Name Servern der
Adress-Domain 168.192.in-addr.arpa folgender Resource Record
eingetragen werden :
| Domain-Name | Typ | Information |
|---|---|---|
128.168.192.in-addr.arpa |
NS |
nameserver.tc.elug.de. |
Diese Anbindung nennt man auch Delegation, da die Bearbeitung von Such-Anfragen unserer Domain auf diese Weise zu unserem Name Server delegiert wird.
Wenn man Name Server verwenden will, braucht man nur ihre IP-Adressen in die
Datei /etc/resolv.conf als nameserver einzutragen.
Die Resolver Library benutzt diese Datei, um Name Server zu finden.
Dort kann man auch search-Einträge vornehmen. Diese sind
eine Liste von Domain-Namen, die automatisch hinter einen Domain-Namen
gehängt werden, bevor die Name Server gefragt werden, solange bis
eine positive Antwort kommt.
Dadurch kann für die Computer z. B. der eigenen Domain der Domainname weggelassen werden. Dies sollte jedoch nur für solche Domains erfolgen, deren Name Server schnell erreichbar sind, damit bei externen Domain-Namen keine unnötigen langen Anfragen gemacht werden.
In unserem Fall könnte die Datei so aussehen :
search tc.elug.de
nameserver 192.168.128.1
Hinweis: Es sollte bedacht werden, daß viele Internet-Einwahlprogramme
die IP-Adressen des jeweiligen ISP automatisch in die Datei
/etc/resolv.conf eintragen und sie nach dem Auswählen
wieder restaurieren.
Außerdem wird bei Verwendung des DHCP diese Datei
automatisch komplett erstellt.
Unter neueren Unix-Systemen wird zusätzlich die Datei
/etc/nsswitch.conf benutzt. Hier steht für verschiedene
Informationen die Art und Weise beschrieben, sie zu finden.
Für die Namensauflösung wird dort der Eintrag hosts
verwendet. Dort steht üblicherweise :
hosts: files dns
files steht hier für die Datei /etc/hosts oder
ähnliche Dateien oder Datenbanken, dns steht für den
Domain Name Service. Hier könnte außerdem der
Network Information Service (NIS) angegeben werden.
Auf einigen Systemen gibt es einen Name Service Cache Daemon, der neben DNS-Anfragen auch andere Informationen sammelt. Dieser kann als Ersatz für einen Cacheing-only Name Server verwendet werden.
| Name, Lizenz, Autor, URL | Kurzbeschreibung |
|---|---|
BIND, Open Source,
Internet Software Consortium,
http://www.isc.org/products/BIND/
|
Referenz-Implementation, verbreitet, für viele und große Domains optimiert, umständlich zu konfigurieren, erlaubt Forwarding und Cacheing |
DNRD, GPL,
Brad Garcia,
Wolfgang Zekoll
u. a.,
http://www.quietsche-entchen.de/download/
|
Einfach zu konfigurieren über eine Datei und über Command Line Parameter, Forwarding je nach Anfrage zu verschiedenen Name Servern (Proxy), reduziertes Cacheing, kein TCP-Support |
DJBDNS, (Lizenz?),
D. J. Bernstein,
http://cr.yp.to/djbdns.html
|
Konfiguration über Befehle zur Eingabe und Änderung von Resource Records, Diverse Programme für verschiedene Aufgaben (Cacheing, Server, Admin) |
PDNSD, GPL und BSD,
Thomas Moestl u. a.,
http://home.t-online.de/home/Moestl/
|
Konfiguration über eine Datei und zur Laufzeit über ein Steuerprogramm, permanentes Cacheing für zeitweisen Betrieb ohne externen Name Server |
La MaraDNS, Public Domain,
Sam Trenholme,
http://www.maradns.org/
|
Minimalistisch, Sicherheit (Stabilität) hat Priorität |
Dnsmasq, GPL,
Simon Kelley,
http://thekelleys.org.uk/dnsmasq/doc.html
|
Einfache Konfiguration, Forwarding und Cacheing (Proxy),
benutzt /etc/hosts und /etc/resolv.conf
als Datenbank (Resource Records), unterstützt IPv6,
verwendet Lease-File des DHCP-Servers
|
Die verschiedenen Name Server Pakete enthalten teilweise eigene Programme
zur Abfrage von Name Servern.
Bekannt sind das bereits erwähnte host, das ähnliche
dig und das wohl älteste nslookup,
das auch interaktiv arbeiten kann.
Die Name Server benutzen zwar das selbe standardisierte Protokoll, unterstützen jedoch nicht unbedingt alle seine Ausprägungen. Daher sind nicht alle Abfrageprogramme für alle Name Server geeignet bzw. nur bedingt nutzbar.
arpa, mit Hilfe derer
der FQDN eines Computers mit gegebener IP-Adresse ermittelt
werden kann (Reverse Mapping).