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.

 

Beispiel einer hosts-Datei:

 

#

# 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.  

 

Die »Zonen«

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

 

Die Top-Level Domains

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

 

Mitglieder des CORE

ja

.edu

»EDUCATION«              Bildungsorganisation

Network Solutions

nein

.gov

»GOVERNMENT«              US-Regierung

US Government

nein

.int

»INTERNATIONAL«              Internationale Organisation

IANA

nein

.mil

»MILITARY«              US-Militär

US Department of Defense

nein

.net

»NET«              Angebot mit »Bezug zum Internet«

Mitglieder des CORE

ja

.org

»ORGANIZATION«              Nichtkommerzielle Organisation

Mitglieder des CORE

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