IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - Services - Domain Name Service



Domain Name Service

Ohne DNS hätten wir heute nicht das Problem der Domainverknappung. Denn dann müsste jeder User anstatt www.it-academy.cc direkt eine ip wie 213.229.11.74 in den Browser tippen. Nun ein Blick hinter dieses sinnvolle und unbedingt notwendige Service.


Autor: Martin Puaschitz (onestone)
Datum: 23-01-2002, 19:06:28
Referenzen: Albitz P. & Liu C. - DNS and BIND; O'Reily 1998
Schwierigkeit: Fortgeschrittene
Ansichten: 5853x
Rating: 4.67 (3x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



4

1.1. Geschichtlicher Überblick

 

In den 70er Jahren war das ARPAnet (der erste Vorbote des heutigen Internets) im Vergleich zu heute noch sehr klein. Jeder Computer konnte anfänglich nur über seine eindeutige IP-Adresse erreicht werden. Da sich dies auf die Dauer als recht schwierig herausstellte, wurde ein neues Service entwickelt. Durch diesen Dienst wurde es möglich, einen Rechner anstatt seiner IP-Adresse mit seinem Namen zu erreichen. Anfänglich wurde diese "Datenbank" in einer Datei zentral gespeichert. Doch als das Internet immer größer wurde, war es für die einzelnen Administratoren unmöglich, aufgrund des ständigen Anwachsens von Rechnern im Internet, diese Datei in gleicher Geschwindigkeit anzupassen.

 

Um dieses Problem unter Kontrolle zu bekommen, wurde ein System namens JEEVES von Paul Mockapetris entwickelt. Eine spätere Version war BIND (=Berkeley Internet Name Domain), geschrieben für Berkeley 4.3SD Unix Betriebssysteme.

 

Paul Mockapetris war verantwortlich für das Konzept und die Architektur des Projekts. 1984 veröffentliche das RFC 882 und 883 sowie später 1034 und 1035. Diese RFCs wurden im Laufe der Zeit sehr oft von verschiedensten anderen Autoren argumentiert und erweitert.

1.2. Das Domain-Name-Service in Kürze

 

Das Domain-Name-Service ist im eigentlichen Sinn eine Datenbank. Dies erlaubt lokale Kontrolle über die jeweiligen Segmente in der gesamten Datenbank und Erreichbarkeit der einzelnen Segmente durch ein "Client-Server" System. Vor allem Sicherheit und Performance war für die Entwickler sehr wichtig.

 

Die Programme, die diesen Dienst anbieten, heißen "Nameserver". Nameserver bieten DNS-Informationen über die Segmente, die sie verwalten müssen, anderen Servern an. Diese werden "Resolver" genannt und holen, je nach Situation, gewünschte oder benötigte Daten von den Servern ab.

 

Die Struktur des Domain Name Service ähnelt sehr einem normalen Dateisystem. Die gesamte Datenbank ist als verkehrtes Baumdiagramm aufzufassen, mit dem Ursprung oben. Jeder Bereich (=Node) im System hat einen Text, der ihn vor seinen "Eltern", also den übergeordneten, identifiziert. Jeder dieser Nodes kann auch einen weiterer Punkt von untergeordneten Nodes beinhalten. Jede Domain bzw. jedes Verzeichnis kann auch in verschiedene Partitionen unterteilt werden, welche dann "Subdomains" genannt werden.

 

Das interessante an DNS ist, dass jeder Domain von verschiedenen Organisationen delegiert werden kann. Jede Organisation kann somit ihre eigenen Subdomains (z.B. subdomain.domain.at) ohne weitere Kosten oder andere Firmen einrichten.

 

Warum also diese komplizierte System? Ganz einfach, weil die Datei HOSTS.TXT einfach nicht mehr alle Daten beinhalten konnte - es waren einfach zu viele geworden. Es war ebenso interessant, dass jede Organisation, die unter einer Domäne erreichbar war, z.B. Firma.com ihre Rechner einheitlich benennen konnte. So ist also der Rechner mit dem Namen alf einheitlich auch unter alf.firma.com erreichbar. Dies nennt man "unique Domain name".

1.3. Wer muss DNS verwenden?

 

Die ganze Sache scheint ja relativ kompliziert. Dennoch verwendet jeder, der im Internet Daten verschickt, also Internetseiten ansieht, E-Mails versendet, Terminalsessions aufbaut, usw. DNS. Die Ausnahme würde rein theoretisch sein, wenn jemand statt www.it-academy.cc z.B. 213.229.11.74 eintippen würde. Hier würde der DNS-Server übergangen werden, da er nicht gebraucht wird. Es existieren allerdings auch Applikationen, die diese IP-Adressen in Domainnamen umändern. Sie sehen: Ohne DNS kann das Internet im heutigen Umgang kaum noch funktionieren, es ist einfach schon viel zu groß!

 

1.3.1. Muss ich jetzt DNS verwenden?

 

Ja. Aber das heißt nicht, dass Sie selbst einen DNS-Server betreiben müssen. Im Normalfall stellt man in seinem Betriebssystem ein, welche Name-Server verwendet werden sollen. Die Daten hierfür erhalten Sie von ihrem Provider. In viele Fällen wird es allerdings heute schon so gehandhabt, dass auch diese automatisch ihrem Computer zugewiesen werden, sobald Sie sich beim Provider einwählen.

1.4. Wie funktioniert DNS grundsätzlich?

 

Prinzipiell ist DNS lediglich eine Datenbank mit indexierten Domainnamen. Jeder Domain ist nur ein Pfad in einem großen invertierten Baum, der Domain Name Space genannt wird. Dieser ähnelt stark bekannten UNIX-Dateisystemen. Der Baum hat eine Spitze ganz oben, diese heißt „the root“. Von dort teilt sich der gesamte Domain Name Space in die weiteren Pfade neu auf. Die maximale Anzahl an Pfaden ist 127, aber keine Angst, die werden Sie nie erreichen.

 

1.5. Domain Names

 

Jeder Punkt in diesem Baum hat neben einer IP-Adresse auch einen Namen (ohne Punkte!), der bis zu 63 Zeichen lang sein darf. Der einzige Name, der kein Zeichen beinhaltet, ist the root vorbehalten. Der Domainname eines Host ist, von seinem jeweiligen Punkt im Baumdiagramm ausgehend, die Sequenz von Namen auf dem Pfad von diesem Punkt bis zu the root (also der Spitze des Baumes). Diese Sequenz wird immer durch Punkte unterteilt.

 

Ein Hostname heißt also z.B www.it-academy.cc. (der Punkt am Ende verdeutlich nur, dass hier the root erreicht wurde, also die oberste Spitze). Diese heißen dann fully qualified Domain name, auch als FQDN abgekürzt. Der Vollständigkeit halber: Wenn nur von the root an sich die Rede ist, verwendet man allgemein ‚.' um diesen Namen darzustellen.

 

Besonders wichtig ist, dass kein Punkt innerhalb des Systems mehr oder weniger den gleichen Namen erhalten darf. Jeder Name darf nur einmal auf der Welt vorhanden sein. Ähnliche Regeln haben auch Dateisysteme in Windows, Unix und allen anderen Betriebssystemen. Absolute Pfade dürfen nicht die gleichen Namen besitzen.

Auf der anderen Seite darf firma.at. und firma.com. nebeneinander bestehen. Hier sind zwar die Rechnernamen gleich, allerdings nicht die Domainendungen .at. und .cc. (mehr zu diesen ein wenig später). Die Abbildung 5.3 verdeutlicht dies.     

Grafik 5.3

1.6. Domains

 

Ein Domain ist ein nur ein weiterführender Ast innerhalb des Domain Name Space. Der Domainname einer Domain ist der gleiche wie der Domainname eines Punktes, welcher den obersten Punkt des gesamten Domains bildet. Grafik 5.4 zeigt ein mögliches Beispiel hierfür auf.

 

Grafik 5.4

 

Jeder Subdomain (also z.B. hausmeister.it-academy.cc.) ist Teil der gesamten Domain (it-academy.cc.). Jeder Domain kann mehrere Subdomains haben  (wie zuvor bereits erwähnt maximal 127). Deshalb entstehen dadurch komplexere Baumsysteme als bisher. Ein Beispiel für Subdomains sind in Grafik 5.5 zu finden.

 

Grafik 5.5

 

Ein Domain ist also lediglich ein Unterverzeichnis des Domain Name Space. Jeder Host wird von seinem Domain-Name repräsentiert. Die Hosts sind alle Domain names, die auf spezielle Informationen (z.B. verschiedene Webserver) auf individuellen Geräten zeigen. Diese host-Reihe ist meist logisch aufgebaut, oft aufgrund der geographischen Lage. Ein einfaches Beispiel sind die Landes-TLDs. Aufgrund der Endung ‚.at' bzw. ‚.ch' ist es möglich zwischen Österreich und der Schweiz zu unterscheiden.

 

Es ist allerdings nicht notwendig, für verschiedene Dienste mehrere Geräte, und somit auch mehrere Domain-Names zu verwenden. Es ist auch möglich it-academy.cc für Webbrowsing, Datenübertragungen oder Mailübertragungen zu verwenden.

 

Ein einfacher Weg, herauszufinden, ob ein Domain eine Subdomäne oder eine Domäne selbst ist, ist der folgende: Sie vergleichen einfach die Namen. Wenn sie hausmeister.it-academy.cc sehen, wissen Sie, dass Hausmeister ein Subdomain von it-academy.cc ist (da diese ja auf .cc endet). Um es klar dazulegen ist allerdings auch it-academy eine Subdomain von .cc, wird allerdings normalerweise nicht als Subdomain bezeichnet. Natürlich wäre auch .cc ein Subdomain von "." - dies ist dann aber nur noch Theorie.

1.7. Der Internet Domain Name Space

 

Bis jetzt haben wir nur von reiner Theorie gesprochen. Im Internet ist, wie vieles, alles ein wenig anders. Das Domain Name System im Internet untersteht in weiterer Folge keinen besonderen Regeln. Es ist auch deutsprachigen Firmen aus A, CH oder D gestattet ihre Homepage unter .cc (Coconut Islands) abzulegen (auch wenn die Geographen hier etwas entgegensetzen könnten!). Ähnlich sieht es in der Vergabe der SubDomains aus. Sie können ihren Rechnern verschiedenste Namen oder Zeichensätze geben (sie müssen nur DNS-konform sein). Egal ob Sie Ihren Rechner nach Ihrem Ehepartner, nach Ihren Kindern oder nach Ihrem Hund nennen, hier gibt es keine gesonderten Regeln.

1.8. Top Level Domains

 

Die einstigen top-level Domains sind wie folgt unterteilt:

 

com      für Kommerzielle Organisationen wie Hewlett-Packard (hp.com).

edu       Lehreinrichtigungen wie Universitäten. Ein Beispiel: U.C. Berkeley (berkeley.edu).

gov       Einrichtungen der amerikanischen Behörden wie die NASA (nasa.gov)

net       Networking organisations wie die NSFNET (NSF.net).

org       Hauptsächlich non-kommerzielle Organisationen-

int        Internationale Organisationen, wie z.B. die NATO (nato.int)

 

Ein weiterer Top Level Domain war damals .ARPA, welcher noch innerhalb des ARPAnet's verwendet wurde. Jeder Rechner hatte damals die Endung .ARPA nach seinem Hostname.

 

Sie bemerken sicherlich, dass viele dieser TLD's nach Amerikanischem Prinzip erstellt wurden. Bis heute ist es nur dem US-Militär gestattet die Endung .mil zu verwenden, ähnlich wie .edu oder .gov. Für mehr Informationen über neue TLD's ist die Homepage http://www.gtld-mou.org/ sehr dienlich. Um mehr über länderbezogene TLD's zu erfahren, ist das Dokument ISO 3166 sehr interessant.

1.9. Domainnamen verstehen

 

Jetzt möchte ich einige Beispiele zur Hilfe nehmen, um das gesamte System noch einmal ein wenig näher zu erklären.

 

martin.intern.it-academy.cc

 

In diesem Fall sehen Sie, dass it-academy.cc der eigentliche Domain ist. "Intern" davor mag heißen, dass es sich um einen internen Bereich handelt, wo entweder Informationen gespeichert sind, oder es Rechner im internen Netzwerk sind. "Martin" bezeichnet im weiteren Fall anscheinend einen Namen aus der internen Crew.

 

Winnie.corp.hp.com

 

Der Domain hp.com gehört der Firma Hewlett-Packard und ist eine kommerzielle Firma (man erkennt dies an .com). Der Subdomain corp ist z.B. der Bereich des Management, winnie der Rechner des CEO (Chief Executive Officer) der Firma (dies ist jetzt erfunden!).

1.10. Delegation

 

Domainnamen werden bei bestimmten Stellen geordert. Diese sind jeweils für eine bestimmte Art von Domänenamen verantwortlich. In Österreich ist es zum Beispiel www.nic.at, die sich um neue Domains kümmert. Hier kann jeder *.at, *.co.at oder *.ac.at Domains bestellen. Sie sehen, jede Behörde, die Domänen verwaltet, kann die TLD erneut unterteilen, also eigentlich Subdomains machen. Denn ".at" ist ja auch nur ein Subdomain von "." (the root - Sie erinnern sich!).

 

Eine gleiche Delegation erfolgt, wenn ein Domain beantragt wird. Sobald die Registrierung vorgenommen und genehmigt wurde, wird die Verantwortung auf die Person oder Firma, die den Domain gekauft hat, übertragen. Ein Beispiel: Der Domain it-academy.cc wird bei enic.cc beantragt. Sobald die Registrierung fertig ist, liegt es in der Verantwortung des Besitzers weitere Subdomains zu gestalten. Somit können dann Subdomains wie intern.it-academy.cc oder XYZ.it-academy.cc einfach eingetragen werden. Dafür ist nicht mehr die zuständige Registrierungsbehörde (in dem fall enic.cc) zuständig, sondern der Registrar selbst.

1.11. Name Server und deren Zonen

 

Die Programme, welche die Informationen über die Domain-Daten speichern, heißen Nameserver. Nameserver haben im Großen und Ganzen die Aufgabe, komplette Informationen über einen Teil des Domain Name Space bereitzustellen. Dieser Teil der Information wird Zone genannt. In einer Zone werden die Informationen über einen Domain, als Beispiel wieder it-academy.cc, gespeichert. Sobald ein Nameserver diese Aufgabe für eine Domain übernimmt, wird er als authority für diese Zone bezeichnet. Es ist natürlich möglich, dass ein einziger Server mehrere Zonen, also Domains, verwaltet.

 

Der Unterschied zwischen einer Zone und einem Domain ist wichtig: Alle top-level-Domains (.com, .net, .at, .cc usw.) wie eben  *.cc oder *.at sind in kleinere Zonen zerstückelt worden. Das heißt im Klartext, dass sich die Registrierungsstellen von *.cc und *.at nicht darum kümmern, die beiden Zonen zu hosten, sondern nur die Delegation (siehe oben!) an den Registrar weitergeben. Was bleibt also übrig für die Registrierungsstellen von den Domainendungen? Ganz einfach. *.at ist zuständig, die jeweiligen Delegationsinformationen bereitzustellen, damit Anfragen weitergeleitet werden. Mehr dazu allerdings ein wenig später!

 

Ein simples Beispiel, wie die Registrierung von *.at Domänen und deren Zonen aufgebaut sind ist in Grafik 5.6 zu finden.

 

Grafik 5.6

 

Natürlich kann man auch die Zonen, die „unterhalb" von .at liegen (puaschitz.at) in weitere Subdomains aufteilen. Dies geschieht vom jeweiligen Registrar der Domäne. Diese Subdomains sind durch einfache Eintragungen in der Nameserver-Zone möglich. Eine Grafik, wie diese Domainstruktur aussehen kann finden Sie in Grafik 5.7.

 

Grafik 5.7

 

Wahrscheinlich ist es jetzt klarer, warum jeder Nameserver immer nur eine eigene Zone lädt, und nicht gleich die gesamte Domain. Man kann sich vorstellen, wie lange der Nameserver brauchen würde, um die gesamte *.com Domain zu laden.

1.12. Verschiedene Typen von Nameservern

 

Das DNS Protokoll unterscheidet zwischen zwei verschiedenen Arten von NameServern. Auf der einen Seite sind es die primary masters, auf der anderen die secondary masters. Ein primary master einer Zone liest die Daten für eine Zone von seinem eigenen System und stellt diese Daten dann zur Verfügung. Ein secondary master kopiert diese Zonendatei lediglich vom primary master. Sobald der secondary master gestartet wird, sucht er auf dem primary master die Zone und überprüft, ob sich etwas geändert hat (anhand einer Art Versionsnummer). Wenn ja, wird die Zone sogleich übertragen. Dies wird normalerweise Zone-Transfer genannt.

 

Beide Nameserver gelten als authorative für diese Zone. Sobald der primary master aus irgendwelchen Gründen nicht erreichbar sein sollte, wird einfach der secondary master kontaktiert, der dann die von ihm zuletzt gespeicherte Zone zu Verfügung stellt und die gewünschten Informationen liefert. Weiters hat es auch administrative Zwecke, einen secondary master zu betreiben. Es muss die Zone nicht händisch kopiert werden, sobald weitere Nameserver für die Zone vorhanden sein müssen.

 

Noch wichtig anzumerken ist, dass ein primary master natürlich gleichzeitig auch ein secondary master einer anderen Zone sein kann. Genauso wie ein Nameserver mehrere Zonen als primary und mehrere als secondary verwalten kann.

1.13. Auflösung mit Nameservern

 

Natürlich ist es mit jedem Nameserver auch möglich, Informationen aus dem Domain Name Space abzufragen. Hierzu benötigt der Nameserver gar nicht viele Informationen. Lediglich die Adresse der Root- Nameserver (Sie erinnern sich, diese haben ja die Einträge über ihre Subdomains; hier sind jetzt allerdings *.at. oder *.cc. gemeint). Durch Ansprechen dieser Rechner ist es möglich, immer die jeweilige Information zu erlangen.

1.14. Die Root-Nameserver

 

Die Root- Nameserver sind, wie schon gesagt, authoritative über die Domainendungen, die über die gesamte Welt verteilt sind. Hierunter fallen alle TLD’s, die es überhaupt gibt. Der Rootserver kann dem anfragenden Nameserver zumindest Auskunft darüber geben, welcher Nameserver für die gewünscht Adresse wiederum authoritative ist. Somit fragt der Nameserver den zuständigen Nameserver für die TLD an und erbittet nähere Auskünfte nach weiteren Nameservern oder eine direkte Auflösung der Frage. Somit wandert der Nameserver entlang des Baumdiagramms immer weiter nach unten, bis er irgendwann auf einen trifft, der explizite Aussagen treffen kann.

 

Ein Beispiel soll diese Theorie verdeutlichen: Der Nameserver 213.229.11.74 bittet um Auflösung von „intern.shop.orf.at“. Der Nameserver fragt bei den rootservern an, wer denn für „.at“ eigentlich zuständig ist. Sobald er diese Adresse hat, fragt er bei dem Nameserver von .at nach, wer denn für orf.at zuständig sei. Mit der nun bekannten Adresse wendet er sich an den nächsten Nameserver ob dieser nicht weiß, welche IP-Adresse intern.shop.orf.at hat. Leider weiß orf.at auch noch nichts genaueres und verweißt auf shop.orf.at. Endlich kann jemand eine Aussage tätigen. Der genannte Nameserver ist der primary master von shop.orf.at und hat somit in seinen Zonendaten auch die IP-Adresse des Rechners „intern“. Sobald die IP-Adresse übertragen ist, gibt sie der zuerst anfragende Nameserver aus. Die folgende Grafik 5.8 soll dieses Schema ein wenig anschaulicher darstellen.

 

Grafik 5.8

 

Wie Sie aus der obigen Abbildung erkennen können, gibt es große Differenzen bei der Arbeitsverteilung der einzelnen Namesrver. Vier davon haben lediglich den ihrer Ansicht nach besten weiteren Weg herausgegeben und nicht wie der erste Nameserver die Anfrage selbst weiterverfolgt. Warum wird der Resolver nicht direkt an die verschiedenen Nameserver weitergeleitet? Ganz einfach, er kann es nicht. Der Resolver schickt seine Anfrage lediglich an seinen zuständigen Nameserver (in seinem Netzwerk, bei seinem Provider).  Dort wird die Anfrage verarbeitet. Der Resolver an sich erhält nur die Daten zurück, die er angefordert hat.

 

Diese Art der Anfrage nennt man „recursive query“. Der Resolver schickt seine Anfrage an seinen zuständigen Nameserver ab. Dieser überprüft, ob er die Daten gespeichert hat (mehr über caching später). Falls nicht, geht er systematisch vor, um an den zuständigen Nameserver zu gelangen.

 

Das Gegenteil von „rekursiv“ ist „interativ“. Interative Aussagen der Nameserver sind natürlich nicht so arbeitsaufwändig wie die rekursiven. Warum? Ganz einfach. Der jeweilige Nameserver gibt immer nur die beste Antwort weiter, die er bereits weiß. Weiß er nichts, kann er auch nicht weiterhelfen – und tut es auch nicht. Solange der Nameserver die gewünschten Daten nicht hat, verweist er den Anfragenden lediglich an andere Nameserver weiter. Unsere Abbildung 5.9 soll diesen Weg erneut verdeutlichen.

 

Grafik 5.9

1.15. IP-Adressen in Domainnamen umwandeln

 

Bisher haben wir immer nur von der Möglichkeit gesprochen, Domainnamen in IP-Adressen umzuwandeln. Es gibt allerdings auch einige Anwendungsgebiete, wo der umgekehrte Weg sehr hilfreich sein kann. So ist es zum Beispiel, wenn in log-files anstatt einer IP-Adresse gleich die Domain steht, viel einfacher diese zu lesen.

Doch diese umgekehrte Auflösung ist deutlich komplexer. Eigentlich müsste ein Nameserver, der eine IP-Adresse in einen Domain umwandeln möchte, vorweg jeden Domain im gesamten Domain-Name-Space in eine IP-Adresse umwandeln und dann vergleichen, mit welcher IP-Adresse die zu suchende korrespondiert. Doch diese Methode ist undurchführbar.

 

Stattdessen wurde das System des in-addr.ARPA eingeführt. Da es ja einfacher ist, die Daten eines Domains herauszubekommen, wird ein Teil des Domain Name Space dafür benutzt Adressen als Labels zu speichern.

 

Jeder eindeutige Rechnername im Domain in-addr.ARPa ist anhand von IP-Adressen definiert. Der in-addr.ARPA Domain kann in diesem fall 256 SubDomains (0-255) besitzen, jeder korrespondiert zu jedem möglichen Wert des ersten Teiles einer IP-Adresse (?.?.?.255). Jeder dieser Subdomains kann wiederum 256 SubDomains beinhalten), diese korrespondieren zum zweiten Teil der IP-Adresse (?.?.255.255). Letztendlich, beim vierten Level, ergibt der vierte Subdomain den vollständigen Domainnamen bzw. die IP-Adresse.

 

Dieses System gibt den Domain in-addr.ARPA eine gewaltige Größe, die für den gesamten Adressenraum im Internet verwendet werden kann. Die Abbildung 5.10 vereinfacht diese Darstellung.

 

Grafik 5.10

 

Ganz wichtig zu bemerken ist, dass, wenn Sie den Domain jetzt korrekt lesen, er verkehrt erscheint. Dies resultiert ja daraus, dass sie von „the root“ nach unten lesen müssen. Somit ist die Adresse von z.B. winnie.corp.hp.com 15.16.192.152, da der in-addr.ARPA subdomain 152.192.16.15.in-addr.ARPA, welcher auf winnie.corp.hp

[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06246
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1154
Comments: 0