Beratung

Berlin
Hamburg
München
Köln
Frankfurt am Main
Stuttgart
Düsseldorf
Dortmund
Essen
Bremen
Dresden
Leipzig
Hannover
Nürnberg
Duisburg
Bochum
Wuppertal
Bonn
Bielefeld
Mannheim
Karlsruhe
Münster
Wiesbaden
Augsburg
Aachen
Mönchengladbach
Gelsenkirchen
Braunschweig
Chemnitz
Kiel
Krefeld
Halle (Saale)
Magdeburg
Freiburg im Breisgau
Oberhausen
Lübeck
Erfurt
Rostock
Mainz
Kassel
Hagen
Hamm
Saarbrücken
Mülheim an der Ruhr
Herne
Ludwigshafen am Rhein
Osnabrück
Oldenburg
Leverkusen
Solingen
Potsdam
Neuss
Heidelberg
Paderborn
Darmstadt
Regensburg
Würzburg
Ingolstadt
Heilbronn
Ulm
Wolfsburg
Göttingen
Offenbach am Main
Pforzheim
Recklinghausen
Bottrop
Fürth
Bremerhaven
Reutlingen
Remscheid
Koblenz
Bergisch Gladbach
Erlangen
Moers
Trier
Jena
Siegen
Hildesheim
Salzgitter
Cottbus
Gera
Kaiserslautern
Witten
Gütersloh
Schwerin
Iserlohn
Zwickau
Düren
Esslingen am Neckar
Ratingen
Flensburg
Hanau
Tübingen
Ludwigsburg
Marl
Lünen
Dessau-Roßlau
Konstanz
Velbert
Minden
Worms
Wilhelmshaven
Villingen-Schwenningen
Marburg
Gießen
Neumünster
Dorsten
Rheine
Lüdenscheid
Castrop-Rauxel
Troisdorf
Viersen
Gladbeck
Delmenhorst
Arnsberg
Bocholt
Lüneburg
Detmold
Bayreuth
Norderstedt
Brandenburg an der Havel
Celle
Bamberg
Dinslaken
Aschaffenburg
Lippstadt
Unna
Aalen
Plauen
Weimar
Neubrandenburg
Kerpen
Fulda
Neuwied
Herford
Grevenbroich
Landshut
Dormagen
Herten
Bergheim
Kempten (Allgäu)
Garbsen
Rosenheim
Wesel
Sindelfingen
Frankfurt (Oder)
Rüsselsheim
Schwäbisch Gmünd
Offenburg
Langenfeld (Rheinland)
Friedrichshafen
Hürth
Hameln
Stralsund
Stolberg (Rheinland)
Göppingen
Euskirchen
Görlitz
Hattingen
Eschweiler
Menden (Sauerland)
Sankt Augustin
Hilden
Greifswald
Baden-Baden
Meerbusch
Bad Salzuflen
Pulheim
Neu-Ulm
Wolfenbüttel
Schweinfurt
Ahlen
Nordhorn
Waiblingen
Neustadt an der Weinstraße
Langenhagen
Bad Homburg vor der Höhe
Willich
Emden
Ibbenbüren
Wetzlar
Gummersbach
Lingen (Ems)
Passau
Bergkamen
Erftstadt
Cuxhaven
Frechen
Speyer
Ravensburg
Wittenberg, Lutherstadt
Kleve
Elmshorn
Peine
Soest
Bornheim
Lörrach
Bad Oeynhausen
Schwerte
Heidenheim an der Brenz
Rastatt
Neunkirchen
Rheda-Wiedenbrück
Frankenthal (Pfalz)
Dülmen
Herzogenrath
Gronau (Westf.)
Böblingen
Hof
Stade
Melle
Hennef (Sieg)
Erkrath
Singen (Hohentwiel)
Gotha
Alsdorf
Freising
Bitterfeld-Wolfen
Leonberg
Neustadt am Rübenberge
Albstadt
Bünde
Fellbach
Erkelenz
Straubing
Kamen
Wismar
Filderstadt
Nordhausen
Brühl (Rheinland)
Lahr/Schwarzwald
Homburg
Amberg
Oberursel (Taunus)
Bad Kreuznach Weinheim
Landau in der Pfalz
Rodgau
Lehrte
Bruchsal
Monheim am Rhein
Bietigheim-Bissingen
Eisenach
Halberstadt
Pinneberg
Dachau
Rottenburg am Neckar
Stendal
Seevetal
Kaarst
Weiden in der Oberpfalz
Kaufbeuren
Oranienburg
Nettetal
Gifhorn
Weißenfels
Lemgo
Freiberg
Borken
Coburg
Memmingen
Wunstorf
Goslar
Eberswalde
Königswinter
Heinsberg
Bautzen
Aurich
Falkensee
Dreieich
Pirmasens
Nürtingen
Laatzen
Ansbach
Löhne
Kirchheim unter Teck
Buxtehude
Siegburg
Bensheim
Völklingen
Mettmann
Freital
Schorndorf
Hückelhoven
Neumarkt in der Oberpfalz
Ahaus
Schwabach
Suhl
Buchholz in der Nordheide
Pirna
Ettlingen
Kamp-Lintfort
Hofheim am Taunus
Warendorf
Maintal
Germering
Haltern am See
Hemer
Würselen
Niederkassel
Voerde (Niederrhein)
Hoyerswerda
Leinfelden-Echterdingen
Sankt Ingbert
Schwäbisch Hall
Saarlouis
Beckum
Coesfeld
Bernau bei Berlin
Ostfildern
Greven
Neu-Isenburg
Mühlhausen
Kempen
Langen
Emsdetten
Bernburg (Saale)
Datteln
Wermelskirchen
Merseburg
Backnang
Sinsheim
Lage
Porta Westfalica
Wesseling
Papenburg
Altenburg
Meppen
Kehl
Erding
Wernigerode
Leer
Naumburg (Saale)
Tuttlingen
Uelzen
Winsen (Luhe)
Fürstenfeldbruck
Goch
Mörfelden-Walldorf
Schwedt/Oder
Riesa
Königs Wusterhausen
Balingen
Zweibrücken
Steinfurt
Schönebeck
Radebeul
Barsinghausen
Geldern
Limburg an der Lahn
Stuhr
Dietzenbach
Korschenbroich
Jülich
Crailsheim
Seelze
Viernheim
Cloppenburg
Fürstenwalde/Spree
Biberach an der Riß
Itzehoe
Rheinfelden (Baden)
Wedel
Georgsmarienhütte
Nienburg/Weser
Bad Vilbel
Deggendorf
Werl
Neuruppin
Rheinberg
Zeitz
Gevelsberg
Vechta
Lampertheim
Herrenberg
Kornwestheim
Ahrensburg
Bad Nauheim
Eisenhüttenstadt
Lohmar
Höxter
Kreuztal
Bramsche
Ganderkesee
Meschede
Radolfzell am Bodensee
Ennepetal
Forchheim
Idar-Oberstein
Weyhe
Merzig
Oer-Erkenschwick
Osterholz-Scharmbeck
Achim
Bad Hersfeld
Delbrück
Güstrow
Weil am Rhein
Werne
Burgdorf
Tönisvorst
Sangerhausen
Waltrop
Emmerich am Rhein
Andernach
Bühl
Northeim
Springe
Oelde
Geesthacht
Haan
Wegberg
Aschersleben
Wedemark
Gaggenau
Taunusstein
Friedberg (Bayern)
Rietberg
Vaihingen an der Enz
Sundern (Sauerland)
Schwelm
Staßfurt
Bretten
Kevelaer
Geilenkirchen
Köthen (Anhalt)
Rendsburg
Zittau
Neuburg an der Donau
Landsberg am Lech
Wetter (Ruhr)
Friedberg (Hessen)
Baesweiler
Kelkheim (Taunus)
Schwandorf
Hamminkeln
Baunatal
Winnenden
Neukirchen-Vluyn
Meißen
Bad Zwischenahn
Leichlingen (Rheinland)
Wangen im Allgäu
Königsbrunn
Bad Neuenahr-Ahrweiler
Rheinbach
Rösrath
Leimen
Henstedt-Ulzburg
Warstein
Mechernich
Lennestadt
Selm
Overath
Mühlheim am Main
Rinteln
Emmendingen
Geislingen an der Steige
Nordenham
Verden (Aller)
Kulmbach
Saalfeld/Saale
Heiligenhaus
Senftenberg
Neckarsulm
Einbeck
Weinstadt
Unterschleißheim
Delitzsch
Brilon
Plettenberg
Griesheim
St. Wendel
Strausberg
Schloß Holte-Stukenbrock
Lauf an der Pegnitz
Garmisch-Partenkirchen
Lohne (Oldenburg)
Wiesloch
Ilmenau
Zirndorf
Rödermark
Hennigsdorf
Reinbek
Lübbecke
Petershagen
Blankenfelde-Mahlow
Hattersheim am Main
Ehingen
Rottweil
Wiehl
Horb am Neckar
Eisleben, Lutherstadt
Olpe
Sprockhövel
Mühlacker
Limbach-Oberfrohna
Rathenow
Schmallenberg
Heppenheim (Bergstraße)
Espelkamp
Bad Honnef
Norden
Olching
Achern
Arnstadt
Verl
Butzbach
Salzkotten
Übach-Palenberg
Lindau (Bodensee)
Attendorn
Friedrichsdorf
Bedburg
Pfungstadt
Ellwangen (Jagst)
Varel
Hann. Münden
Ditzingen
Mosbach
Glauchau
Herdecke
Roth
Hohen Neuendorf
Weiterstadt
Spremberg
Syke
Markkleeberg
Bad Oldesloe
Bingen am Rhein
Meckenheim
Lüdinghausen
Burg
Pfaffenhofen an der Ilm
Ingelheim am Rhein
Netphen
Salzwedel
Obertshausen
Harsewinkel
Schleswig
Ludwigsfelde
Walsrode
Helmstedt
Waldkraiburg
Weingarten
Rudolstadt
Wallenhorst
Dillenburg
Stutensee
Korbach
Wertheim
Freudenstadt
Osterode am Harz
Warburg
Groß-Gerau
Remseck am Neckar
Geretsried
Idstein
Ronnenberg
Calw
Wipperfürth
Zerbst/Anhalt
Starnberg
Sondershausen
Apolda
Herzogenaurach
Werdau
Haren (Ems)
Sehnde
Isernhagen
Waldshut-Tiengen
Alfter
Unterhaching
Öhringen
Jüchen
Werder
Eckernförde
Vreden
Nagold
Teltow
Radevormwald
Bad Mergentheim
Moormerland
Senden (Bayern)
Sonneberg
Stadthagen
Rees
Lengerich
Husum
Lindlar
Vaterstetten
Metzingen
Westerstede
Fröndenberg/Ruhr
Blankenburg (Harz)
Leutkirch im Allgäu
Bad Harzburg
Blieskastel
Annaberg-Buchholz
Soltau
Rotenburg (Wümme)
Überlingen
Greiz
Schwetzingen
Duderstadt
Karben
Wandlitz
Weilheim in Oberbayern
Bad Soden am Taunus
Meiningen
Xanten
Neusäß
Gelnhausen
Büren
Riedstadt
Eppingen
Groß-Umstadt
Wülfrath
Coswig
Edewecht

Ratgeber

Informationen und Tipps zum Domainrecht

Für Inhalt, Vollständigkeit und Aktualität der Informationen übernehmen wir keine Gewähr.

Domain Name System (DNS)

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Seine Hauptaufgabe ist die Umsetzung von „Internetadressen“ in die zugehörige IP-Adresse. 

Überblick 

Das DNS ist eine weltweit auf tausende von Servern verteilte hierarchische Datenbank, die den Namensraum des Internets verwaltet. Dieser Namensraum ist in so genannte Zonen unterteilt, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen – etwa innerhalb eines Firmennetzes – ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben. 

Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen (forward lookup) benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenkolonnen. So kann man sich den Domainnamen wikipedia.org leichter merken als die dazugehörende IP-Adresse 145.97.39.155. 

Ein weiterer Vorteil ist, dass IP-Adressen – etwa von Web-Servern – relativ risikolos geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine rudimentäre Lastverteilung (Load Balancing) realisiert werden. 

Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse lookup) möglich. In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen Inverssuche bekannt ist. 

Das DNS wurde 1983 von Paul Mockapetris entworfen und in RFC 882 und 883 beschrieben. Beide wurden inzwischen von RFC 1034 und RFC 1035 abgelöst und durch zahlreiche weitere Standards ergänzt. Ursprüngliche Aufgabe war es, die lokalen hosts-Dateien abzulösen, die bis dahin für die Namensauflösung zuständig waren und die der exponentiell zunehmenden Zahl von Neueinträgen nicht mehr gewachsen waren. Aufgrund der erwiesenermaßen hohen Zuverlässigkeit und Flexibilität wurden nach und nach weitere Datenbestände in das DNS integriert und so den Internetnutzern zur Verfügung gestellt. 

DNS zeichnet sich aus durch:

  • dezentrale Verwaltung
  • hierarchische Strukturierung des Namensraums in Baumform
  • Eindeutigkeit der Namen
  • Erweiterbarkeit

Komponenten des DNS

Das DNS besteht aus drei Hauptkomponenten:

  • Domain-Namensraum
  • Nameserver
  • Resolver

Domain-Namensraum 

Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels. Label sind Zeichenketten (alphanumerisch, als einziges Sonderzeichen ist ‚-‘ erlaubt), die mindestens ein Zeichen und maximal 63 Zeichen lang sind, mit einem Buchstaben beginnen müssen und nicht mit '-' enden dürfen (RFC1035, Abschnitt „2.3.1. Preferred name syntax“). Die einzelnen Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Ein korrekter, vollständiger Domainname (auch Fully Qualified Domain-Name (FQDN) genannt) lautet etwa www.wikipedia.de. 

Ein Domainname darf inklusive aller Punkte maximal 255 Zeichen lang sein. 

Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (engl. root). Diese erste Ebene wird auch als Top-Level-Domain (TLD) bezeichnet. 

Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records meist in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist. Anstelle von Zonendatei wird meist der etwas allgemeinere Ausdruck Zone verwendet. 

Nameserver 

Nameserver sind zum einen Programme, die Anfragen zum Domain-Namensraum beantworten. Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme laufen, als Nameserver bezeichnet. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern. 

Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer. 

Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen RAM ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als Caching bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umständen aber auch bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefern kann, wenn sich die Daten zwischenzeitlich geändert haben. 

Ein Spezialfall ist der Caching Only Nameserver. In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver (Forwarder) auflösen. Dafür stehen verschiedene Strategien zur Verfügung: 

Strategien 

Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien: 

Delegierung

Teile des Namensraumes einer Domain werden oft an Subdomains mit dann eigens zuständigen Nameservern ausgelagert. Ein Nameserver einer Domäne kennt die zuständigen Nameserver für diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.

Weiterleitung (forwarding)

Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.

Auflösung über die Root-Server

Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Server befragt. Dazu werden in Form einer statischen Datei die Namen und IP-Adressen der Root-Server hinterlegt. Es gibt 13 Root-Server (Server A bis M). Die Root-Server beantworten ausschließlich iterative Anfragen. Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet.

Resolver

Schematische Darstellung der rekursiven und iterativen DNS-Abfrage 

Resolver sind einfach aufgebaute Software-Module, die auf dem Rechner eines DNS-Teilnehmers installiert sind und die Informationen von Nameservern abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie, falls notwendig, zu einem FQDN und übermittelt sie an einen normalerweise fest zugeordneten Nameserver. Ein Resolver arbeitet entweder iterativ oder rekursiv. 

Im rekursiven Modus schickt der Resolver eine rekursive Anfrage an den ihm zugeordneten Nameserver. Hat dieser die gewünschte Information nicht im eigenen Datenbestand, so kontaktiert der Nameserver weitere Server, und zwar solange bis er entweder eine positive Antwort oder bis er von einem authoritativen Server eine negative Antwort erhält. Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung ihrem Nameserver. 

Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder einen Verweis auf weitere Nameserver, die er als nächstes fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver bis er von einem eine verbindliche Antwort erhält. 

Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser. Übliche Resolver von Clients arbeiten ausschließlich rekursiv, sie werden dann auch als Stub-Resolver bezeichnet. Nameserver besitzen in der Regel eigene Resolver. Diese arbeiten gewöhnlich iterativ. 

Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup, host und dig. Weitere Informationen zur iterativen/rekursiven Namensauflösung finden sich unter rekursive und iterative Namensauflösung. 

Protokoll

DNS-Anfragen werden normalerweise per UDP Port 53 zum Nameserver gesendet. Der DNS-Standard erlaubt aber auch das TCP Protokoll. Falls kein Extended DNS verwendet wird (EDNS), beträgt die maximal zulässige Länge des DNS-UDP-Pakets 512 Bytes. Überlange Antworten werden daher abgeschnitten übertragen. Durch Setzen des Truncated-Flags wird der anfragende Client über diesen Sachverhalt informiert. Er muss dann entscheiden, ob ihm die Antwort reicht oder nicht. Gegebenenfalls wird er die Anfrage per TCP Port 53 wiederholen.

Zonentransfers werden stets über Port 53 TCP durchgeführt. Die Auslösung von Zonentransfer erfolgt aber gewöhnlich per UDP.

Aufbau der DNS-Datenbank

Das Domain Name System kann als verteilte Datenbank mit baumförmiger Struktur aufgefasst werden. Beim Internet-DNS liegen die Daten auf einer Vielzahl von weltweit verstreuten Servern, die untereinander über Verweise – in der DNS-Terminologie Delegationen genannt – verknüpft sind.

In jedem beteiligten Nameserver existieren eine oder mehrere Dateien – die so genannten Zonendateien – die alle relevanten Daten enthalten. Bei diesen Dateien handelt es sich um Listen von Resource Records. Von fundamentaler Bedeutung sind zwei Record-Typen:

Mit dem A Resource Record werden die eigentlichen Daten definiert: Einem Namen wird eine IP(v4)-Adresse zugewiesen.

Mit dem NS-Record werden die Verknüpfungen der Server untereinander realisiert.

Mit diesen beiden Record-Typen lässt sich prinzipiell das gesamte klassische DNS aufbauen. Für Verwaltungszwecke sind aber weitere Typen erforderlich, wie zum Beispiel der SOA Record. Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Dieser Prozess ist noch nicht abgeschlossen. Eine umfassende Liste findet sich hier.

Beispiele:

Der A-Record de.wikipedia.org. A 145.97.39.155 definiert: Dem Namen de.wikipedia.org ist die IP-Adresse 145.97.39.155 zugewiesen.

Der NS-record wikipedia.org NS ns0.wikimedia.org. definiert: Die Zonendatei für die Domain wikipedia.org befindet sich auf dem Server ns0.wikimedia.org.

Beispiel Namensauflösung

Im Beispiel wird www.example.net in drei Schritten mit Hilfe des Resolver-Tools dig iterativ „per Hand“ aufgelöst. Ausgangspunkt ist der Root-Server A.root-servers.net. Dessen Adresse (198.41.0.4) ist in Nameservern und Resolvern fest einkonfiguriert. Der Rootserver enthält für die Domain net eine Delegation (NS-Record) zum Server A.GTLD-SERVERS.net. Dieser wiederum verweist für die Domain example.net auf den Server a.iana-servers.net, der schließlich den gesuchten Eintrag www.example.net enthält. Die Ausgabe ist auf das Wesentliche gekürzt.

Bei den von den nicht-zuständigen Nameservern zusätzlich ausgegebenen A-Records handelt es sich um Glue Records. Die Zahl vor ‚IN‘ bedeutet die TTL (Time To Live) in Sekunden. Sie besagt, wie lange der Client die Antwort im Cache behalten darf, bevor er neu anfragen muss. Bei dynamischen IP-Adressen liegt diese Zahl meistens zwischen 60 (Minimum) und 300 Sekunden.

Beispiel Reverse Lookup

Reverse Lookup findet zu einer IP-Adresse – falls vorhanden – den Namenseintrag des Eigentümers der Adresse.

Im ersten Schritt wird die IP umgeformt, damit man sie – wie bei DNS üblich – von rechts nach links lesen kann. Dabei wird die Domain 'in-addr.arpa' hinzugefügt.

Hinter dieser Domain verbergen sich Nameserver, bei denen IPs namentlich registriert werden können (es gibt keinen Zwang, dies zu tun). Da nach der Umformung die höherwertige Gruppe rechts steht, ist eine Auflösung von rechts nach links einfach.

In der ANSWER SECTION sieht man, dass die IP 'ipxserver.de' gehört.

In der AUTHORITY SECTION sieht man, dass das Subnetz 80.190.249.0/24 ebenfalls zu 'ipxserver' gehört.

Die zusätzlichen Domains, die auf dieser IP liegen, sieht man nicht. Wie man sieht, können Lookup und Reverse Lookup unterschiedliche AUTHORITY SECTIONs haben. Die Erklärung hierfür ist einfach: Die IP gehört 'ipxserver.de', einem Anbieter von Rootservern. Die Domain 'zeitna.de' gehört dem Mieter des Servers.

Erweiterung des DNS

Da sich das DNS sowohl als zuverlässig als auch flexibel erwiesen hat, wurden im Laufe der Jahre mehrere größere Erweiterungen eingeführt. Ein Ende dieses Trends ist nicht absehbar.

Dynamischer DNS

Im klassischen DNS ist es aufwändig, einem Namen eine neue IP-Adresse zuzuordnen. Das zugehörige Zonenfile muss (meist manuell) geändert und der Nameserver neu geladen werden. Zeitliche Verzögerungen bis hin zu mehreren Tagen sind üblich. Mit Dynamischem DNS sind Änderungen durch Senden eines entsprechenden DNS-Requests ohne Zeitverzug möglich.

Der Dynamische DNS gilt als Sicherheitsrisiko, da ohne spezielle Vorkehrungen jedermann DNS-Einträge löschen oder verändern kann. In Zusammenhang mit DHCP ist Dynamisches DNS nahezu zwingend erforderlich, da einem User häufig neue IP-Adressen zugewiesen werden. Der DHCP-Server sendet dazu bei jeder Adressänderung eine entsprechende Mitteilung an den Nameserver.

Internationalisierung

Bisher waren die Label – wie beschrieben – auf alphanumerische Zeichen und das Zeichen ‚-‘ eingeschränkt. Dies hängt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprünglich) in den USA entwickelt wurde. Allerdings gibt es in vielen Ländern Zeichen, die nicht in einem Label verwendet werden konnten (im deutschen Sprachraum zum Beispiel die Umlaute ä, ö und ü) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch). Namen mit diesen Zeichen waren ursprünglich nicht DNS-fähig.

Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490 beschriebene Internationalisierung von Domain Namen IDNA. Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit zulässigen Zeichen kodiert, also auf derzeit gültige Namen abgebildet. Die erweiterten Zeichensätze werden dabei zunächst gemäß dem Nameprep-Algorithmus (RFC 3491) normalisiert und anschließend per Punycode (RFC 3492) auf den für DNS verwendbaren Zeichensatz abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (z. B. Web-Browser), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verändert zu werden. Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizer Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei einigen anderen Top-Level-Domains, insbesondere im asiatischen Raum, ist die Nutzung von IDNA möglich.

Extended DNS

1999 beschrieb Paul Vixie im RFC 2671 einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als EDNS Version 0 bezeichnet werden. Durch Verwendung von bis dahin reservierten, aber ungenutzten Header-Codes, kann der Anfragende festlegen, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. Außerdem wurde es möglich andere Label-Typen zu nutzen. DNSSEC-fähige Server und Resolver müssen EDNS beherrschen.

Verwaltung von Telefonnummern

Eine weitere aktuelle Erweiterung des DNS stellt ENUM (RFC 2916) dar. Diese Anwendung ermöglicht die Adressierung von Internet-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Nummerierungsschema. Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für Voice over IP Services an.

RFID-Unterstützung

Mit der Radio Frequency Identification können auf speziellen RFID-Etiketten abliegende IDs – so genannte Elektronische Produktcodes oder EPCs – berührungslos gelesen werden. Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten über das zugehörige Objekt enthält. Der Object Naming Service ONS wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer NAPTR.

Spam-Abwehr

Zur Filterung von Spam-Mails überprüfen viele Mailserver routinemäßig mit Hilfe des DNS die Absenderadressen eingehender Mails. Als erster Schritt wird dabei der MX Record ermittelt. Aus der so erhaltenen IP-Adresse wird per reverse Lookup ein Name erfragt. Dieser muss mit dem ursprünglichen Absendernamen identisch sein, sonst wird die Mail verworfen. Ein Spammer ist dann nicht mehr in der Lage, beliebige Absenderadressen zu erfinden, sondern muss auf registrierte DNS zurückgreifen.

Mittels Sender Policy Framework kann wesentlich wirkungsvoller verifiziert werden, dass ein Absendername gültig ist. Zu jeder Mail-Domain wird dabei über einen speziellen SPF Resource Record explizit aufgelistet, wer aus dieser Domain heraus Mails versenden darf (im Idealfall nur ein einziger Server).

Sonstiges

Neben den IP-Adressen können DNS-Namen auch ISDN-Nummern, X.25-Adressen, ATM-Adressen, öffentliche Schlüssel, Text-Zeilen usw. zugeordnet werden. In der Praxis sind derartige Anwendungsfälle aber die Ausnahme.

DNS im lokalen Netz

DNS ist nicht auf das Internet beschränkt. Es ist ohne weiteres möglich und mit der Definition verträglich, für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und dort die entsprechenden Adressen einzutragen. Mit dem Werkzeug Webmin lässt sich dies auch ohne tiefgehende Kenntnisse bewerkstelligen. Der einmalige Aufwand zur Installation lohnt sich auch bei relativ kleinen Netzen, da dann alle Adressen im Netz zentral verwaltet werden können.

Bei größeren Firmen oder Organisationen ist häufig ein aus lokalem und Internet DNS bestehendes Mischsystem (Split-DNS) anzutreffen. Die internen Nutzer greifen auf das lokale und die externen auf das Internet-DNS zu. In der Praxis können dadurch sehr komplizierte Konstellationen entstehen.

Der DNS-Server BIND kann auch mit DHCP zusammenarbeiten und damit für jeden Client im Netz eine Namensauflösung ermöglichen.

Unter Windows gibt es den Dienst WINS, der eine ähnliche Funktion zur Verfügung stellt, allerdings ein ganz anderes Protokoll verwendet. WINS wurde durch Active Directory abgelöst und gilt heute als veraltet.

DNS-Security

Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Eine Störung kann erhebliche Kosten nach sich ziehen und eine Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein. Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt. Folgende Verfahren sind verfügbar:

    * Bei TSIG (Transaction Signatures) handelt es sich um ein einfaches, auf symmetrischen Schlüsseln beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern gesichert werden kann.

    * Bei DNSSEC (DNS Security) wird von einem asymmetrischen Kryptosystem Gebrauch gemacht, mit dem nahezu alle DNS-Sicherheitsanforderungen erfüllt werden können. Neben der Server-Server-Kommunikation wird auch die Client-Server-Kommunikation gesichert.

Angriffe

Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passworte, PINs, Kreditkartennummern usw. zu erhalten. In seltenen Fällen wird versucht, den Internet-DNS durch Denial of Service Attacken komplett auszuschalten und so das Internet lahmzulegen. Außerdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.

DNS-Spoofing

Beim DNS-Spoofing wird einem anfragenden Client eine Antwort mit einer falschen IP-Adresse untergeschoben, so dass dieser auf eine falsche Web-Seite gelenkt wird.

Cache Poisoning

Beim Cache Poisoning werden einem anfragenden Client zusätzlich zur korrekten Antwort manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und möglicherweise später ungeprüft verwendet.

DNS-Amplification-Angriff

Die DNS Amplification Attack ist ein Denial-of-Service-Angriff, bei dem nicht der DNS selbst das eigentliche Angriffsziel ist, sondern ein unbeteiligter Dritter. Ausgenutzt wird, dass DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksenden. Diese werden auf die IP-Adresse des Opfers gelenkt. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substantiell verstärken und so den Internet-Zugang seines Angriffziels stören.

Offener DNS-Server

Wer einen autoritativen DNS-Server für seine eigenen Domains betreibt, muss natürlich für Anfragen von beliebigen IP's offen sein. Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z.B. für Angriffe auf Root-Server), erlaubt Bind es, die Antworten auf die eigenen Domains einzuschränken. Z.B. bewirkt die Option 'allow-recursive {127.0.0.1; 172.16.1.4;};' es, dass rekursive Anfragen, d.h. Anfragen auf andere Domains, nur für den Localhost und für 172.16.1.4 beantwortet werden. Alle anderen IP's bekommen nur auf Anfragen auf eigene Domains eine Antwort.

Eine zusätzliche Sicherheitsmaßnahme ist es, für Input von außen nur Udp zuzulassen.

Spamabwehr

Bei Schwarzen Listen z. B. gegen Spammer, wird DNS angewendet, um abzufragen, ob ein Domainname gelistet ist: Der Client schickt eine DNS-Anfrage an den Rbl-Server. Dieser antwortet mit '127.0.0.1', wenn die Adresse nicht gelistet ist, sonst mit '127.0.0.x', x>1. Der Wert von 'x' kann noch zusätzliche Informationen über die gelistete Adresse enthalten. Da der Bereich 127.0.0.0/8 für Localhost reserviert ist, sind Missdeutungen nicht möglich.

Domain-Registrierung

Um DNS-Namen im Internet bekannt machen zu können, muss der Besitzer die Domain, die diese Namen enthält registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registrars) vorgenommen, die dazu von der IANA bzw. ICANN autorisiert wurden. Registrierungen sind (von wenigen Ausnahmen abgesehen) gebührenpflichtig. Für Domains unter .de ist die DENIC zuständig.

Bonjour/Zeroconf

Apple hat bei der Entwicklung von Mac OS X mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll. Zum einen wurde MulticastDNS („mDNS“) eingeführt, das die Namensauflösungen in einem LAN ohne einen dedizierten Namensserver erlaubt. Zusätzlich wurde noch DNS-SD (für „DNS Service Discovery“) eingeführt, die die Suche („Browsing“) nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermöglicht. mDNS und DNS-SD sind bisher keine offiziellen RFCs des IETF, sind aber trotzdem bereits in verschiedenen (auch freien) Implementationen verfügbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „Zeroconf“ zusammen, als Bestandteil von Mac OS X auch als „Rendezvous“ bzw. „Bonjour“.

DNS-Analyse und Fehlersuche

Störungen oder Fehler im DNS können vielfältige Folgeprobleme verursachen, deren Zusammenhang mit DNS nicht immer offensichtlich ist. Es sollte daher Grundregel jeder Strategie zur Fehlersuche sein, sich von der ordnungsgemäßen Funktion des DNS zu überzeugen. Zur Untersuchung werden in der Regel zwei Quellen heran gezogen:

1. DNS-Server-Logs/Configs

Die Konfigurations- und Log-Dateien des jeweiligen DNS-Servers. Dieser Schritt setzt voraus, dass Zugang zum DNS-Server gegeben ist. Vorteil: Es wird direkt auf die Quelle zugegriffen, die das Verhalten bestimmt. Nachteil: Es können gewöhnlich nur die Logfiles der eigenen Nameserver untersucht werden.

2. DNS-Client/-Server-Kommunikation

Der Daten-Verkehr der DNS-Server und DNS-Clients oder – bei bestimmten Problemen – zwischen verschiedenen DNS-Servern. Dies geschieht über Aufzeichnung und Auswertung des Datenverkehrs über das Mittel der LAN-Analyse durch so genannte Sniffer. Vorteil: Es werden (je nach Messpunkt) alle DNS-Vorgänge aller DNS-Teilnehmer erfasst und ausgewertet. Nachteil: Es werden nur die Wirkungen, nicht aber unbedingt die Ursachen sichtbar.

In komplexen Umgebungen müssen Firewall- und Router-Admins hinzugezogen werden. Die Diagnose wird in vielen Fällen durch das DNS-Caching erschwert. Fehlerhafte Einträge bis hin zu ungültigen Zonen können sich für Stunden bis Wochen in den einzelnen Servern halten. Die Konsistenz des Datenbestandes geht dadurch verloren: Zu ein und dem selben Zeitpunkt können unterschiedliche Server unterschiedliche DNS-Daten besitzen.

Nameserversoftware

Auswahl bekannter Software für Namesauflösung.

BIND (Berkeley Internet Name Domain) ist der Ur-Nameserver und heute noch die meistgenutzte Nameserversoftware, nicht zuletzt da er die Referenzimplementation der meisten RFCs zu DNS darstellt. BIND ist quelloffene Software.

Dnsmasq ist ein einfacher DNS- und DHCP-Server für kleine Netze. Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelöst. Unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert.

djbdns gilt als sehr sicher und erfreut sich steigender Beliebtheit, wird aber von Daniel J. Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht.

PowerDNS war eine kostenpflichtige Implementierung, die inzwischen auch unter der GPL erhältlich ist und vor allem für das direkte Betreiben von Zonen aus SQL-Datenbanken und LDAP-Verzeichnissen bekannt ist.

MyDNS ist eine weitere quelloffene Software, die insbesondere auf MySQL- und PostgreSQL-Datenbanken spezialisiert ist.

Xyria:DNSd ist ein performance-optimierter DNS-Server, der etwa doppelt so schnell ist wie Bind. Xyria:DNSd ist derzeit noch recht minimalistisch und unterstützt keine Zonetransfers (außer etwa via SSH), dafür aber extrem sicher und stabil.

NSD ist optimiert für Server die ausschließlich autoritative Antworten besonders schnell liefern sollen.

Microsoft Windows DNS ist ein in Windows 2003 Server enthaltener DNS-Server, der Dynamische Updates, Zonentransfer und Notification unterstützt. Zonendaten können im Active Directory oder in Zonendateien gespeichert und repliziert werden.

UltraDNS ist ein kommerzieller managed DNS Service von NeuStar Ultra Services. Diese Firma bietet auch ein DNSshield an, das DNS in einer Alliance mit verschiedenen ISPs absichert und ist damit spezialisiert auf DNS großer Webseiten. Auch ein Teil der Root-Level-DNS ist hier gesichert. Das Internet Systems Consortium (ISC) sichert den F-Root Server hier ab.


Dieser Artikel basiert auf dem Artikel Domain-Name-System aus der freien Enzyklopädie Wikipedia und steht unter der GNU-Lizenz für freie Dokumentation. In der Wikipedia ist eine Liste der Autoren verfügbar.

Adelebsen Ahnatal Allendorf Bad Harzburg Lauterberg Sachsa Baunatal Beverungen Bovenden Brakel Calden Clausthal-Zellerfeld Dassel Duderstadt Einbeck Eschwege Friedland Gleichen Göttingen Großalmerode Gudensberg Hann Hann. Hannoversch Münden Hardegsen Heiligenstadt Herzberg Hessisch-Lichtenau Höxter Hofgeismar Holzminden Kalefeld Kassel Katlenburg-Lindau Kaufungen Kreiensen Leinefelde Lohfelden Niestetal Nordhausen Nörten-Hardenberg Northeim Moringen Mühlhausen Osterode Rosdorf Schauenburg Seesen Sondershausen Staufenberg Uslar Vellmar Warburg Wernigerode Witzenhausen Wolfhagen Worbis Zierenberg

sitemap            

just law Rechtsanwälte, Groner-Tor-Straße 8, 37073 Göttingen   info@justlaw.de

www.justlaw.de