Domain Name Service

ÔĽŅ
Domain Name Service
Domain Name System (DNS)
Familie: Internetprotokollfamilie
Einsatzgebiet: Namensauflösung
Ports: 53/UDP, 53/TCP
DNS im TCP/IP‚ÄĎProtokollstapel:
Anwendung DNS
Transport UDP TCP
Internet IP (IPv4, IPv6)
Netzzugang Ethernet Token
Bus
Token
Ring
FDDI …
Standards:

RFC 1034 (1987)
RFC 1035 (1987)

Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung.

In Analogie zu einer Telefonauskunft soll DNS bei Anfrage mit einem Hostnamen (dem ‚ÄěAdressaten‚Äú im Internet ‚Äď zum Beispiel www.example.org) als Antwort die zugeh√∂rige IP-Adresse (die ‚ÄěAnschlussnummer‚Äú ‚Äď zum Beispiel 192.0.2.42) nennen.

Inhaltsverzeichnis

√úberblick

Das DNS ist ein weltweit auf tausende von Servern verteilter hierarchischer Verzeichnisdienst, der 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 ‚Ästetwa 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 einen Domainnamen wie example.org in der Regel leichter merken als die dazugeh√∂rende IP-Adresse 208.77.188.166.

Ein weiterer Vorteil ist, dass IP-Adressen ‚Ästetwa 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 per DNS (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 enorm 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 (siehe unten: Erweiterung des DNS).

DNS zeichnet sich aus durch:

  • zentrale 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

schematische Darstellung der DNS-Hierarchie

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 eines Pfades. 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 (RFC 1035, 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.example.com..

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:

Zusammenarbeit der einzelnen Nameserver

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 rekursiv oder iterativ.

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 autoritativen 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 Namensserver gesendet. Der DNS-Standard erlaubt aber auch TCP. 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 IPv4-Adresse zugewiesen.
  • Mit dem NS Resource 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 unter Resource Record.

Beispiele:

Der A Resource 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 Resource 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.

$ dig +norecurse @198.41.0.4 www.example.net
net. 172800 IN NS A.GTLD-SERVERS.net.
A.GTLD-SERVERS.net. 172800 IN A 192.5.6.30

$ dig +norecurse @192.5.6.30 www.example.net
example.net. 172800 IN NS a.iana-servers.net.
a.iana-servers.net. 172800 IN A 192.0.34.43

$ dig +norecurse @192.0.34.43 www.example.net
www.example.net. 172800 IN A 192.0.34.166

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 20 und 300 Sekunden.

Beispiel Reverse Lookup

Reverse Lookup findet zu einer IP-Adresse ‚Äď falls vorhanden ‚Äď den Namenseintrag des Eigent√ľmers der Adresse.

1) IP-Adresse zu einem Namen finden:

$ host -a zeitna.de --> (gek√ľrzt)
zeitna.de has address 80.190.249.119
AUTHORITY SECTION:
zeitna.de. 259200 IN NS server1-ns1.udagdns.net

2) Reverse Lookup f√ľr diese IP-Adresse

$ host -a 80.190.249.119 --> (gek√ľrzt)

Trying "119.249.190.80.in-addr.arpa"

ANSWER SECTION:
119.249.190.80.in-addr.arpa. 86400 IN PTR ipx10576.ipxserver.de.

AUTHORITY SECTION:
249.190.80.in-addr.arpa. 86400 IN NS ns1.ipx-server.de.
249.190.80.in-addr.arpa. 86400 IN NS ns2.ipx-server.de.

  • Im ersten Schritt wird die IP-Adresse 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 IP-Adressen 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-Adresse 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-Adresse 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-Adresse geh√∂rt ipxserver.de, einem Anbieter von Rootservern. Die Domain zeitna.de geh√∂rt dem Mieter des Servers.

Aus diesem Beispiel erkl√§rt sich auch die auf den ersten Blick etwas merkw√ľrdige Syntax f√ľr den Eintrag eines Reverse Lookup im Nameserver BIND:

$ $ORIGIN 249.190.80.in-addr.arpa.
$TTL 86400
119 IN PTR ipx10576.ipxserver.de.

  • Die beiden ersten Zeilen setzen die Basis und die TTL f√ľr die folgenden Eintr√§ge.
  • Die dritte Zeile setzt den Namen f√ľr die IP-Adresse 119 im Subnetz von Zeile 1.

Erweiterung des DNS

Da sich das DNS als zuverl√§ssig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere gr√∂√üere Erweiterungen eingef√ľhrt. Ein Ende dieses Trends ist nicht absehbar.

Dynamisches DNS

Im klassischen DNS ist es aufwendig, 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.

Das 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 ‚Ästwie 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 schweizerische 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 Verwendung 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 abgelegte 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. 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 noch einen anderen Dienst zur Namensaufl√∂sung ‚Äď WINS, der eine √§hnliche Funktion zur Verf√ľgung stellt, allerdings ein ganz anderes Protokoll verwendet.

DNS-Serververbund

Es ist m√∂glich, mehrere DNS-Server zu verbinden. Die als Master bezeichneten Server sind f√ľr eine oder mehrere Domains verantwortlich und √ľbertragen deren Adressen an ihre Slaves. Z.¬†B. kann eine Firma mit mehreren Standorten an einem Platz einen Master f√ľr ihr internes DNS betreiben, der die Server in den Au√üenstellen versorgt. Der Zonentransfer geht bei BIND √ľber TCP (per Default Port 53) und erfordert normalerweise, durch seine Konfiguration, Authentifizierung. Die Slaves werden aktualisiert, wenn sich die Seriennummer f√ľr eine Zonendatei √§ndert. Die Freigabe f√ľr den Transferport sollte man per Firewall an die IP-Adresse des Masters binden. Bei anderen Softwarepaketen werden die Daten unter Umst√§nden auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.

DNS und Lastverteilung

Wenn man f√ľr einen Namen mehrere IP-Adressen angibt, werden diese in zyklischer Reihenfolge ausgegeben. Die Clients verwenden √ľblicherweise die erste Angabe. Dies kann man ausnutzen, um einem Namen mehrere Server zuzuweisen, auf welche die Last dann verteilt wird. Der Nameserver hat allerdings keine Kontrolle dar√ľber, wie h√§ufig die Clients den Namen abfragen. Im Idealfall wertet der Client die TTL aus; viele Browser oder Mailclients tun dies allerdings nicht.

DNS-Sicherheit

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.

Angriffsformen

Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passwörter, 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.

DDOS-Angriff auf Nameserver

Bei einer Distributed-Denial-of-Service-Attacke werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen √ľberlastet, so dass legitime Anfragen nicht mehr beantwortet werden k√∂nnen. Gegen DDOS-Angriffe auf Nameserver gibt es zur Zeit keine Abwehrm√∂glichkeit. Als vorbeugende Ma√ünahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw. ein verteiltes Netz mit m√∂glichst vielen Servern zu installieren. Solch eine Attacke ist jedoch aufwendig, denn man muss mindestens eine so leistungsschnelle Leitung besitzen wie der Server selbst, was also schwer realisierbar ist. Botnetze und dergleichen werden bei solchen Attacken h√§ufig eingesetzt.

DNS-Amplification-Angriff

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

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 sp√§ter, m√∂glicherweise ungepr√ľft, verwendet.

Offener DNS-Server

Wer einen autoritativen DNS-Server f√ľr seine eigenen Domains betreibt, muss nat√ľrlich f√ľr Anfragen von beliebigen IP-Adressen 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, ausschlie√ülich f√ľr den lokalen Host (localhost) sowie 172.16.1.4 beantwortet werden. Alle anderen IP-Adressen 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. ICCP DP kann zus√§tzlich zugelassen werden. Dies variiert jedoch je nach Proxy-Eigenschaften.

Ein offener DNS-Server kann auch eine Falle sein, wenn er gef√§lschte IP-Adressen zur√ľckgibt, siehe Pharming.

Spamabwehr

Bei Schwarzen Listen (auch 'RBL'; Abk√ľrzung f√ľr engl. Realtime Blackhole Lists) z.¬†B. gegen Spammer, wird DNS angewendet, um abzufragen, ob ein Domainname oder eine IP-Adresse 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 diesen 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.

Detaillierte Informationen finden sich unter Domain-Registrierung.

Bonjour bzw. 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 Multicast DNS (‚Äě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‚Äú.

Nameserversoftware

Auswahl bekannter Software f√ľr Namesaufl√∂sung.

  • BIND (Berkeley Internet Name Domain) ist der Ur-Nameserver und heute noch die meistgebrauchte Nameserversoftware, nicht zuletzt da er die Referenzimplementation der meisten RFCs zu DNS darstellt. BIND ist quelloffene Software.
  • 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.
  • 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.
  • MaraDNS ist ein Nameserver, bei dem die Entwickler besonderen Wert auf Sicherheit legen.
  • Microsoft Windows DNS ist ein in Windows-Servern enthaltener DNS-Server, der dynamische Updates, Zonentransfer und Notification unterst√ľtzt. Zonendaten k√∂nnen in den aktuellen Versionen im Active Directory oder in Zonendateien gespeichert und repliziert werden.
  • MyDNS ist eine weitere quelloffene Software, die insbesondere auf MySQL- und PostgreSQL-Datenbanken spezialisiert ist.
  • NSD ist optimiert f√ľr Server die ausschlie√ülich autoritative Antworten besonders schnell liefern sollen.
  • 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.
  • 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.
  • 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.

Weblinks


Wikimedia Foundation.

Schlagen Sie auch in anderen W√∂rterb√ľchern nach:

  • Domain Name Service ‚ÄĒ Domain Name Service, ¬† DNS ‚Ķ   Universal-Lexikon

  • Domain Name Service ‚ÄĒ Domain Name System Pour les articles homonymes, voir DNS. Pile de protocoles 7 ‚ÄĘ Application 6 ‚ÄĘ ‚Ķ   Wikip√©dia en Fran√ßais

  • Domain Name Service ‚ÄĒ ¬†¬†¬†Abbreviated DNS, sometimes referred to as Domain Naming System. A distributed addressing system that resolves the domain name into the numeric IP address. DNS lets you use the Internet without having to remember long lists of cryptic numbers.… ‚Ķ   Dictionary of networking

  • domain name service ‚ÄĒ noun A service provided by the Domain Name System ‚Ķ   Wiktionary

  • Domain Name Service ‚ÄĒ noun the software which connects domain names to IP addresses, enabling them to be located by anyone accessing the internet ‚Ķ   Australian English dictionary

  • Domain Name Service ‚ÄĒ Internet service which translates site names into their numerical addresses, DNS ‚Ķ   English contemporary dictionary

  • Domain name scams ‚ÄĒ are types of Intellectual property scams or confidence scams in which unscrupulous domain name registrars attempt to generate revenue by tricking businesses into buying, listing or converting a domain name. The Office of Fair Trading has outlined ‚Ķ   Wikipedia

  • domain name ‚ÄĒ A registered address for an organization or an individual for use on the Internet. Domain names are hierarchical with the parts separated by full stops, known as dots. The highest hierarchical part is called the top level domain; this identifies… ‚Ķ   Big dictionary of business and management

  • Domain-Name-System ‚ÄĒ auch Domain Name Service; Internetservice, welches den Namensraum im Internet verwaltet und den Namen einer Domain in numerische IP Adressen √ľbersetzt ‚Ķ   Lexikon der Economics

  • domain name ‚ÄĒ ¬†¬†¬†In the Domain Name Service (DNS), an easy to remember name that identifies a specific Internet host, as opposed to the hard to remember numeric IP address. ¬†¬†¬†See also bang path ‚Ķ   Dictionary of networking


Share the article and excerpts

Direct link
… Do a right-click on the link above
and select ‚ÄúCopy Link‚ÄĚ

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.