Next: Muhahaha - oder: Automatisierung Up: Hitchhiker's Guide to the Previous: Daytime Contents

Subsections

DNS

Der Domain Name Service sorgt im Internet unter anderem dafür, dass man statt IP-Adressen (siehe ) "`symbolische"' Namen eingeben kann, zum Beispiel linide.sf.net.

Zusätzlich ist es dafür verantwortlich, dass die E-Mail-Adresse iblech@web.de gültig ist, obwohl auf web.de kein SMTP-Server (siehe ) lauscht. Mehr dazu .

Historie

Am Anfang, als das Internet noch ARPAnet hieß und sehr viel kleiner war, wurden die IP-Adressen mit einer sogenannten hosts-Datei übertragen, wie auch heute noch üblich in LANs. In so einer hosts-Datei⁶⁴ sind alle IP-Adressen mit ihren jeweiligen symbolischen Namen aufgelistet und mit Whitespace⁶⁵ getrennt:

127.0.0.1 localhost     localhost.gnus
10.0.0.3  thestars.gnus thestars
10.0.0.4  mars.gnus     mars

Diese Liste wurde dann, immer wenn sie aktualisiert wurde, an jeden Teilnehmer des Internets übermittelt.

Als jetzt allerdings das Internet immer größer wurde und dementsprechend immer schneller wuchs, waren die Kosten für die Verbreitung der hosts-Datei nicht mehr zu tragen, weswegen ein neuer Dienst entwickelt wurde.

Idee

Beim DNS sind alle Rechner hierarchisch geordnet (siehe Grafik

**Figure 32:** Untergliederung des Namespace
$\includegraphics[scale=0.6]{.cached/639be3de932593df284056bbe3665d33.eps}$

). Angefangen von der Wurzel, ., kann man Hostnamen beliebig weit verschachteln, jede Subdomain ist von ihrer Domain mit einem . getrennt.

Wenn man nun zum Beispiel in einen Browser den Hostnamen linide.sf.net. eingibt, laufen einige Schritte ab, bis der Browser die IP des symbolischen Namens kennt:

"`Hey ., was ist die IP vom Nameserver von net.?"'
"`Hey Nameserver von net., was ist die IP vom Nameserver von .sf.net"'?
"`Hey Nameserver von sf.net., was ist die IP von linide.sf.net?"'

Erst wenn die endgültige IP-Adresse bekannt ist, kann der Browser via normalen HTTP die Seite anfordern.

Vor- und Nachteile

Die Lösung des oben geschilderten Problems der Verteilung der hosts-Datei war damit natürlich gelöst: Jezt brauchte nicht mehr jeder Rechner alle Zuordnungen der IPs zu symbolischen Namen kennen, da es ja jetzt die Möglichkeit gab, sich von der Wurzel . bis zum Ziel "`durchzuhangeln"'.

Heute gehört . der USA⁶⁶. Wenn die USA nur eine einzige Zeile in der Konfigurationsdatei der Root-Nameserver⁶⁷ ändern oder löschen würde, gäbe es kein de. mehr⁶⁸. Das heißt, USA hat absolute Macht über das zentral-organisierte Internet⁶⁹.

Record-Typen

Nun zur technischen Seite von DNS. DNS ist vielmehr als nur ein hosts-Ersatz. Wo das Format der hosts-Datei nur je einer IP-Adresse einen oder mehrere symbolische Namen zuordnen kann, uns keine hierarchische Ordnung besteht, unterstützt DNS viele Record-Typen.

Aktuell gibt es u.A. folgende Record-Typen:

A: Ein A-Record ordnet einem symbolischen Namen eine IP-Adresse zu⁷⁰.
PTR: PTR-Records sind praktisch das Gegenteil der A-Records. Sie ordnen einer IP-Adressen einen (oder mehrere) symbolische Namen zu. Sie sind notwendig für Reverse-Lookups (siehe ).
NS: Dieser Record, der bei eigentlich jeder Domain vorhanden ist, gibt die IP-Adresse des für das "`Domain-Subnetz"' zuständigen Nameservers an. Dies ist notwendig, um das schon angesprochene "`durchhangeln"' zu ermöglichen.
CNAME: Mit diesem Record ist es möglich, einem symbolischen Namen einen anderen symbolischen Namen zuzuordnen. Dies nutzen zum Beispiel eigentlich alle Hosting-Anbieter, die ihren Kunden eigene Domains ohne eigenen Server anbieten. In diesem Fall ist dann die Kundendomain nur ein Link auf DNS-Ebene auf einen der zentralen Server des Unternehmens.
MX: MX-Records werden heute für den Mailverkehr gebraucht, wie gleich noch erläutert wird.

Ausfallsicherung

Wenn man sich ersthafte Gedanken über die Ausfallsicherheit eines bestimmten Servers macht, kommt man oft zum Schluss, ein sogenannten Round-Robin-Verfahren anzuwenden.

Dabei konfiguriert man mehrere Server auf die gleiche Arbeit, zum Beispiel die Webpräsenz von IBM zu liefern. Dann benutzt man A-Records, um einem symbolischen Namen (zum Beispiel www.ibm.com.) mehrere IP-Adressen (die IP-Adressen der Server⁷¹) zuzuordnen.

Der Browser, bzw. die Name-Resolver-Bibliothek des Betriebssystems, pickt sich dann eine IP-Adresse heraus, die dann verwendet wird. So wird zum einen die Last gleichmäßig auf die verfügbaren Server verteilt und die Ausfallsicherheit erhöht (ist ein Server unerreichbar, wird der nächste genommen).

Ein schönes Beispiel dafür sind die rsync-Server von GNU Gentoo/Linux (siehe Screenshot

**Figure 33:** Ein symbolischer Name - mehrere IP-Adressen
$\begin{figure}\begin{center}\begin{small} \begin{verbatim}iblech@thestars ible... ...ipe 2 iblech@thestars iblech $\end{verbatim} \end{small}\end{center}\end{figure}$

): Bei jedem erneuten Ping-Aufruf wird eine andere IP-Adresse angepingt.

Unter Linux gibt es den Befehl host, der einige Informationen über symbolische Namen gibt. Ausgeführt mit rsync.de.gentoo.org. als Argument erhält man:

rsync.de.gentoo.org has address 62.75.149.3
rsync.de.gentoo.org has address 62.138.61.2
rsync.de.gentoo.org has address 62.245.182.9
rsync.de.gentoo.org has address 80.190.233.33
rsync.de.gentoo.org has address 134.147.32.57
rsync.de.gentoo.org has address 137.226.34.228
rsync.de.gentoo.org has address 141.12.220.13
rsync.de.gentoo.org has address 141.71.54.40
rsync.de.gentoo.org has address 160.45.117.66
rsync.de.gentoo.org has address 194.97.4.250
rsync.de.gentoo.org has address 199.108.109.25
rsync.de.gentoo.org has address 213.131.230.230
rsync.de.gentoo.org has address 217.172.182.32

Noch mehr Informationen sind verfügbar mit der Option -a (siehe Screenshot

**Figure 34:** Diese Informationen könnte man auch in die Konfigurationsdatei des BIND Nameservers eintragen
$\begin{figure}\begin{center}\begin{small} \begin{verbatim}Trying ''rsync.de.ge... ...s from 80.81.7.3 ...$

Dort sieht man auch die zuständigen Nameserver (udns2.ultradns.net. und udns1.ultradns.net.).

MX-Records

Wie im Kapitel über SMTP erläutert, muss es für jede Mail einen Ziel-SMTP-Server geben, der sich für sie zuständig fühlt. Dieser Servername wird eigentlich durch den Teil nach dem @ der E-Mail-Adresse bestimmt. Aber wenn man mal einen einfachen Portscan (siehe ) auf einen solchen Server (zum Beispiel web.de) durchführt, wird man feststellen, dass dort der SMTP-Service gar nicht angeboten wird.

Die Lösung des Problems liegt im MX-Record: Für praktisch jede Domain, die Mail erhalten soll, gibt es einen oder mehrere MX-Records. Diese Records stellen dann zum Beispiel die Zuordnung "`der Mailserver für web.de. ist smtp.web.de"' her.

So kann auch der Mailverkehr temporär auf einen Backup-Server umgeleitet werden, wenn der Haupt-Server zum Beispiel gerade gewartet wird.

Anscheinend ist für die Lamer zu schwer, statt @web.de @smtp.web.de einzugeben...

Abfragbar⁷² ist diese Information unter Linux mit Hilfe des schon erwähnten host-Befehls (siehe Screenshot

**Figure 35:** Mit host den MX-Server einer Domain herausfinden
$\begin{figure}\begin{center}\begin{small} \begin{verbatim}Trying ''web.de'' ;;... ...tes from 10.0.0.3 ...$

). Von Bedeutung sind diesmal aber nur die MX-Records, im Beispiel mx-ha02.web.de und mx-ha01.web.de. Auch hier gibt es also Redundanz: Fällt mx-ha02.web.de aus, so wird von den SMTP-Servern mx-ha01.web.de benutzt.

Reverse-Lookups

Manchmal kennt mal aber schon die IP-Adresse und möchte den symbolischen Namen haben.

Um dies zu ermöglichen, könnte man entweder alle denkbaren Namen bruteforcen (schlecht) oder sich der PTR-Records bedienen (gut).

Nur für diese Reverse-Lookups wurde ein eigene Syntax entwickelt: Möchte man zum Beispiel den symbolischen Namen der IP-Adresse 10.0.0.3 erhalten, feuert man einfach einen Request nach 3.0.0.10.in-addr.arpa. ab. Als Antwort erhält man dann den Namen (im Beispiel thestars.gnus.).

Der Grund für das Umdrehen der IP-Adresse liegt in der Wertigkeit der einzelnen Abschnitte: Beim DNS ist der letzte Teil (die Top-Level-Domain) der höherwertigste. Bei IP-Adressen ist es gerade umgekehrt: Die .3 im Beispiel definiert nur die einzelne Node, die 10. aber ein sehr großes Subnetz.

Übrigens nutzen viele SMTP-Server Reverse-Lookups aus, wenn sie überprüfen wollen, ob sie ihrem "`Gesprächspartner"' trauen können: Sie gehen davon aus, dass, falls es möglich ist, die IP des Gegenübers in einen symbolischen Namen aufzulösen, der Remote-Server wohl einer Firma (= gut) angehören muss. Falls nicht, wird von einem Spammer ausgeganen und die Verbindung geschlossen.

Whois

Möchte man Informationen über Domains erhalten, benutzt man das Whois-Protokoll, welches von eigentlich allen Registrierungsstellen für Domains (NICs⁷³) angeboten wird.

Über Whois erfährt man zum Beispiel, wem die Domain gehört, wer der technische Verwalter ist und wer die Nameserver dieser Domain verwaltet.

Da Whois nur eine einzige Zeile als Eingabe erwartet, ist es sehr leicht zu bedienen: Möchte man zum Beispiel Informationen über die Domain linux.de. erhalten, so stellt man einfach eine Verbindung zum Whois-Server der NIC von de. (whois.denic.de.) auf Port 43 her und gibt

>linux.de

ein. Die Antwort enthält dann neben der Copyright-Notiz und dem Disclaimer die gewünschten Informationen:

<% Copyright (c)2002 by DENIC
<%
<% Restricted rights.
<%
<%
<% Except for agreed Internet operational purposes, no
<% part of this information may be reproduced, stored in a
<% retrieval system, or transmitted, in any form or by any
<% means, electronic, mechanical, recording, or otherwise,
<% without prior permission of the DENIC on behalf of
<% itself and/or the copyright holders. Any use of this
<% material to target advertising or similar activities
<% are explicitly forbidden and will be prosecuted. The
<% DENIC requests to be notified of any such activities
<% or suspicions thereof.
<
<domain:      linux.de
<descr:       Christian Huettermann
<descr:       Herrenberger Str. 14
<descr:       D-72070 Tuebingen
<
<nserver:     ns1.headlight.de
<nserver:     ns2.headlight.de
<status:      connect
<changed:     20030514 194438
<source:      DENIC
<
<[admin-c]
<Type:         PERSON
<Name:         Christian Huettermann
<Address:      Herrenberger Str. 14
<City:         Tuebingen
<Pcode:        72070
<Country:      DE
<Remarks:      ID #205
<Changed:      20030506 140641
<Source:       DENIC
<
<[tech-c][zone-c]
<Type:         ROLE
<Name:         HEADLIGHT Housing Factory Hostmaster
<Address:      Adlerstr. 41
<City:         Stuttgart
<Pcode:        70199
<Country:      DE
<Phone:        +49-711-2840-160
<Fax:          +49-711-2840-166
<Email:        hostmaster@headlight.de
<Changed:      20030115 104650
<Source:       DENIC
<

Das Ausgabeformat ist dabei abhängig von der NIC, deren Whois-Server üblicherweise whois.nic.tld⁷⁴ zu finden ist.

Footnotes

...-Datei ⁶⁴: gespeichert in /etc auf guten Systemen
... Whitespace ⁶⁵: Alles, was auf dem Bildschirm leer erscheint, also zum Beispiel der Blank und der Tabulator
... USA ⁶⁶: no comment.
... Root-Nameserver ⁶⁷: Es gibt aus Gründen der Redundanz 26
... mehr ⁶⁸: Zumindest nach ein paar Stunden, wenn alle möglichen Caches aktualisiert sind
... Internet ⁶⁹: Allerdings kann jeder beliebiger Computer, wenn entsprechend eingerichtet, Root-Nameserver sein. So gibt es Bewegungen, wie etwa OpenNIC (http://www.opennic.glue/), die eigene Root-Nameserver anbieten und demokratisch organisiert sind. Dort gibt es auch andere Top-Level-Domains, zum Beispiel geek. und parody..
... zu ⁷⁰: Ein symbolischer Name kann aber durchaus auch mehrere IP-Adressen besitzen, siehe .
... Server ⁷¹: Oftmals benutzt man auch nur eine IP-Adresse und verwendet dann, ohne Hilfe von DNS, einen eigenen Server, der die Last selbstständig auf die anderen verteilt.
...Abfragbar ⁷²: Diese Abfrage ist übrigens vollkommen legitim und legal. SMTP-Server führen exakt das gleiche aus, wenn sie Mails zustellen
... (NICs ⁷³: Network Information Centers
...whois.nic.tld⁷⁴: tld steht für die Top-Level-Domain

Next: Muhahaha - oder: Automatisierung Up: Hitchhiker's Guide to the Previous: Daytime Contents

Ingo Blechschmidt 2003-08-07