Spezielle
Kapitel aus Technologiefolgenabschätzung:
Rechtliche und Technische Aspekte im Zusammenhang mit E-Commerce
353079
Dipl.Ing. Michael Sonntag
Technische Grundlagen
des Domain-Name Systems (DNS)
Seminarteilnehmer:
Auzinger Robert 9255496, 881
Schrattenecker Andreas 9155062, 881
Das Domain Name System (DNS) wurde
geschaffen, um Rechnern statt den IP-Adressen auch logische Namen zuordnen zu
können. Dies erfolgte in den Anfängen des Internet über eine zentral gehaltene
Datei (/etc/hosts auf UNIX Systemen) /etc/hosts des Network
Information Centers (NIC) die an alle Rechner jeder Domain regelmäßig
mittels ftp verschickt wurde und die jeder IP-Adresse eindeutig einen Namen
zuordnete. Damals war der Adreßraum noch flach, jedoch wurde im Laufe der Zeit
eine größere Hierarchie nötig.
#
# HOSTS-Datei für System 190.136.66.12
#
# IP-Adresse Host-Name Kommentar
190.136.66.12
gerd # PC Gerd
190.136.66.44 eva # PC Eva
190.136.69.12 norbert #
PC Norbert
190.136.70.25 willi #
AXP-Rechner Willi
Als das Internet wuchs, war eine mittels ftp verschickte hosts-Datei
für jeden Rechner nicht mehr möglich. Das Aktualisieren einer solchen Datei
wäre zu aufwendig und würde das Netzwerk zu sehr belasten. /etc/hosts
ist mittlerweile zu einer Datenbank angewachsen und wird in Zonen
aufgeteilt und von dedizierten Rechnern, den Domain Name Servern,
innerhalb der Zone verwaltet. Jeder Domain Name Server sieht also nur
einen Teil des gesamten Domain Name Space.
Eine Domain besteht aus einzelnen Namen, die durch Punkte voneinander
getrennt sind. Der Aufbau des DNS ist hierarchisch, wobei jede Hierarchieebene
Zone genannt und von einem Name Server verwaltet wird. Die oberste
Hierarchieebene im DNS stellen die sogenannten Root-Server dar, die das
Root-Verzeichnis (die sogenannte»Null-Domain«) des DNS verwalten. Im Prinzip
sind diese Root-Server »nur« dafür zuständig, Auskunft darüber zu geben,
welcher Nameserver für angefragte Top-Level-Domains zuständig ist, falls
darunterliegende Nameserver keine Auskunft geben können.
Die nächste Hierarchiestufe stellen die autoritativen Nameserver der
Top-Level-Domains dar. Für jede konnektierte Top-Level-Domain (z.B. ».com«,
».edu«, ».de« usw.) existiert ein eigener Nameserver, der von einem sogenannten
NIC (»Network Information Center«) betrieben wird und somit eine eigene
Top-Level-Domain-Zone bildet. In einer Top-Level-Domain-Zone kann nun beim
zuständigen NIC eine Domain beantragt werden. Innerhalb dieser Domain-Zone kann
nun vom Domain-Administrator, der die Domain beantragt hat, beliebig
weiterstrukturiert werden. Für einen Web-Server richtet man idealerweise einen
Server namens »www.« ein, für einen FTP-Server »ftp.« usw. Natürlich ließen
sich aber innerhalb der Domain-Zone weitere, eigenständige Subdomain-Zonen
einrichten
Zur Zeit gibt es zwei Sorten von Top-Level Domains. Einerseits die
sogenannten Generic TLD und die Country TLD.
Die Generic Top Level Domains (gTLD)
Bei den gTLD handelt es sich um die globalen Top Level Domains, die
unabhängig von einer nationalen TLD sind, jedoch nicht alle frei beantragt
werden können:
TLD |
Genere |
Zuständiger NIC |
Frei beantragbar |
.arpa |
Einrichtung des ARPANet nur systeminterne Nutzung |
|
nein |
.com |
»COMMERCIAL« Kommerz |
ja |
|
.edu |
»EDUCATION« Bildungsorganisation |
nein |
|
.gov |
»GOVERNMENT« US-Regierung |
nein |
|
.int |
»INTERNATIONAL« Internationale Organisation |
nein |
|
.mil |
»MILITARY« US-Militär |
nein |
|
.net |
»NET«
Angebot mit »Bezug zum Internet« |
ja |
|
.org |
»ORGANIZATION« Nichtkommerzielle Organisation |
ja |
Die Country Top Level Domains (cTLD)
Neben den Generic Top-Level-Domains existieren die Country
Top-Level-Domains, bestehend aus den Länderkennzeichnungen nach ISO 3166. Zur
Zeit betreiben allerdings noch nicht alle Länder ihre Domain. Viele nationale
Vergabestellen verwenden unterhalb ihrer nationalen TLD eigene
Spartenkennzeichnungen, z.B. ».co.uk« für kommerzielle Domains in
Großbritannien. Außerdem können in vielen Ländern Domains nur beantragt werden,
wenn dort ein eigener fester Wohn- bzw. Firmensitz vorhanden ist.
z.B.:
.at Österreich
.de Deutschland
usw.
Verwaltung im DNS
Prinzipiell gilt, daß jede Zone zuerst einmal von einem sogenannten
Primary Name Server verwaltet werden muß. Er enthält verbindlich als Autorität
alle Zoneninformationen und repräsentiert diese allen anderen Nameservern,
insbesondere den hierarchisch höherstehenden, da ein höherstehender Nameserver
auf Anfrage nach dem Nameserver seine Adresse liefert.
Zur Sicherheit muß jede Zone
von mindestens einem (oder auch mehreren) anderen Nameserver verbindlich
repräsentiert werden, einem sogenannten Secondary Name Server. Ein Secondary
Name Server muß exakt die gleichen Zoneninformationen des Primary Name Server
führen, um als Secondary Name Server für ihn gelten zu können. Aus diesem Grund
bezieht ein Secondary Name Server die Zoneninformationen direkt vom Primary
Name Server und auch nur von dort, d.h. manuelle Änderungen an
Zoneninformationen können grundsätzlich nur an der Datenbank eines Primary Name
Servers vorgenommen werden, alle seine Secondary Name Server synchronisieren
ihre Datenbanken periodisch mit ihm.
Insgesamt existieren drei Hauptkomponenten, aus denen sich das DNS
zusammensetzt:
1.
Der
Domain Name Space, ein baumartiger, hierarchisch strukturierter
Namensraum und die Resource Records. Das sind Datensätze, die den
Knoten zugeordnet sind.
2.
Name Server sind Name Server Programme bzw. Rechner, die die Informationen
über die Struktur des Domain Name Space verwalten und aktualisieren. Ein Name
Server hat normalerweise nur eine Teilsicht des Domain Name Space zu verwalten.
3.
Resolver: Sie stellen die aufrufbare Schnittstelle für die Kommunikation
zwischen einem Benutzerprozess und einem NS dar. Sie sind in der Lage,
Informationen aus Nameservern zu extrahieren und dem aufrufenden Prozess
(Socketverbindung) zur Verfügung zu stellen.
Rekursive und iterative Anfragen
Es gibt prinzipiell zwei Abfragestrategien im DNS:
Man kann die NS Top-Down fragen bis die gesuchte Antwort gefunden ist, oder man
kann einen Nameserver beauftragen, diese Aufgabe zu erledigen. Resolver
verwenden eben diese zwei Methoden um Namenauflösung zu erreichen. Dafür
brauchen sie die IP-Adresse von mindestens einem NS, der in der Lage ist, auch
nicht-lokale Fragen zu beantworten. Der Resolver kann nun seine Frage stellen
mit gleichzeitigem Verlangen nach „recursion“ oder „no recursion“. Im ersten
Fall muß der gefragte NS, wenn erforderlich, andere NS kontaktieren, bis er die
Frage des Resolvers vollständig beantwortet hat. Im zweiten Fall gibt der
gefragte NS eine Liste von Nameservern zurück, die diese Frage beantworten
könnten. Der Resolver ist dann für die weitere Namensauflösung verantwortlich.
Es gibt sogenannte Stub-Resolver, die nur die
rekursive Methode verwenden. Die Full-Resolver können auf beide Methoden
zurückgreifen. Resolver die Teil einer Applikation sind, sind in der Regel
Stub-Resolver. Dies vereinfacht die Implementierung
Wenn ein NS eine rekursive Anfrage erhält, die er
mit seinen lokal gespeicherten Daten nicht beantworten kann, muß er einen
anderen NS fragen. Er könnte eine rekursive Anfrage an diesen NS senden, und
somit diesen mit der vollständigen Beantwortung der Frage beauftragen, oder mit
iterative Anfragen die Namensauflösung selbst übernehmen. Derzeitige
Implementationen verwenden die zweite Methode.
In der folgenden Darstellung stellt der Resolver
eine rekursive Anfrage an den Nameserver. Dieser löst mit iterativen Anfragen
den Namen auf.
Caching
Alle Nameserver speichern die aus früheren Anfragen
erhaltenen Kenntnisse über den Domainnamensraum. Wenn zum Beispiel ein
Nameserver den Namen fim.uni-linz.ac.at aufgelöst hat, hat er in diesem Prozess
die Adressen der Nameserver, die für uni-linz.ac.at, .ac.at und .at
verantwortlich sind, erhalten. Wenn jetzt ein Resolver nach der Adresse von
gup.uni-linz.ac.at fragt, kann der Nameserver sofort bei uni-linz.ac.at mit der
Auflösung starten. Somit kann der Auflöungsprozess erheblich beschleunigt, und
die Netzwerk- und Nameserverbelastung reduziert werden. Natürlich werden die
erhaltenen Daten nicht ewig lange gespeichert, sondern laufen nach einer
vorgegebenen Zeit ab. Diese Zeit wird durch das TTL-Feld in den Recource
Records festgelegt.
Literatur:
Paul Albitz & Cricket Liu: DNS and BIND,O’REILLY, 1998
Gerhard Lienemann: TCP/IP-Grundlagen Protokolle und Routing, HEISE,
2000
Bernhard Kreinz: DNS – Aus der Sicht des Webmasters, Barnes Enterprises
http://userpage.fu-berlin.de/~mr94/dns/node3.html