Domain Name System

aus Wikipedia, der freien Enzyklopadie

Domain Name System (DNS)

Familie:	Internetprotokollfamilie
Einsatzgebiet:	Namensauflosung
Ports:	53/UDP 53/TCP 853/TCP (nur mit TLS, RFC 7858[1]) 853/UDP (nur mit DTLS, RFC 8094[2])
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)[3] RFC 1035 (1987)[4]

Das Domain Name System, deutsch Domain-Namen-System,^[5] (DNS) ist ein hierarchisch unterteiltes Bezeichnungssystem in einem meist IP-basierten Netz zur Beantwortung von Anfragen zu Domain-Namen (Namensauflosung).

Das DNS funktioniert ahnlich wie eine Telefonvermittlung: Der Benutzer kennt die Domain (den fur Menschen merkbaren Namen eines Rechners im Internet) - zum Beispiel example.org. Diese sendet er als Anfrage in das Internet. Die Domain wird dann dort vom DNS in die zugehorige IP-Adresse (die ,,Anschlussnummer" im Internet) umgewandelt - zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 - und fuhrt so zum richtigen Rechner.

Das DNS ist ein weltweit auf Tausenden von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in sogenannte Zonen unterteilt, fur die jeweils unabhangige Administratoren zustandig sind. Fur lokale Anforderungen - etwa innerhalb eines Firmennetzes - ist es auch moglich, ein vom Internet unabhangiges DNS zu betreiben.

Hauptsachlich 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 auflost. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken konnen als Zahlenketten. So kann man sich einen Domainnamen wie example.org in der Regel leichter merken als die dazugehorende IP-Adresse 192.0.32.10. Dieser Punkt gewinnt im Zuge der Einfuhrung von IPv6 noch mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet. So lost sich beispielsweise der Name www.kame.net in die IPv4-Adresse 203.178.141.194 und die IPv6-Adresse 2001:200:dff:fff1:216:3eff:feb1:44d7 auf.

Ein weiterer Vorteil ist, dass IP-Adressen - etwa von Web-Servern - relativ risikolos geandert werden konnen. Da Internetteilnehmer nur den (unveranderten) DNS-Namen ansprechen, bleiben ihnen Anderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden konnen, kann sogar eine einfache Lastverteilung per DNS (Load Balancing) realisiert werden.

Mit dem DNS ist auch eine umgekehrte Auflosung von IP-Adressen in Namen (reverse lookup) moglich. 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^[6] und RFC 883^[7] beschrieben. Beide wurden inzwischen von RFC 1034^[3] und RFC 1035^[4] abgelost und durch zahlreiche weitere Standards erganzt. Ursprungliche Aufgabe war es, die lokalen hosts-Dateien abzulosen, die bis dahin fur die Namensauflosung zustandig waren und der enorm zunehmenden Zahl von Neueintragen nicht mehr gewachsen waren. Aufgrund der erwiesenermassen hohen Zuverlassigkeit und Flexibilitat wurden nach und nach weitere Datenbestande in das DNS integriert und so den Internetnutzern zur Verfugung gestellt (siehe unten: Erweiterung des DNS).

DNS zeichnet sich aus durch:

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

Der Domain-Namensraum hat eine baumformige Struktur. Die Blatter und Knoten des Baumes werden als Labels (englisch fur Aufschrift) bezeichnet. Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades.

Labels sind Zeichenketten, die jeweils mindestens ein Byte und maximal 63 Bytes lang sind.^[8] Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird meist weggelassen, gehort rein formal aber zu einem vollstandigen Domainnamen dazu). Somit lautet ein korrekter, vollstandiger Domainname (auch Fully Qualified Domain Name genannt) zum Beispiel www.example.com. und darf inklusive aller Punkte maximal 255 Bytes lang sein.

Ein Domainname wird immer von rechts nach links delegiert und aufgelost, das heisst je weiter rechts ein Label steht, umso hoher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label fur die erste Hierarchieebene von der Wurzel (englisch root). Die erste Ebene (beispielsweise com.) wird als Top-Level-Domain (TLD) bezeichnet, die zweite (beispielsweise example.com.) als Second-Level-Domains usw.

Die Daten des Domain Name Systems sind uber eine Vielzahl von Nameservern weltweit verteilt, die durch Verweise untereinander lose gekoppelt sind. Die Verweise werden Delegierungen (englisch delegations) genannt und folgen der hierarchischen Struktur des Domain-Baums. Durch die Delegierungen wird der Domain-Namensraum in uberschneidungsfreie Bereiche unterteilt, die Zonen genannt werden. Ein oder mehrere autoritative Nameserver sind fur die Auslieferung der Daten einer Zone zustandig. So sind beispielsweise die Root-Nameserver fur die Beantwortung von Anfragen an die Wurzel-Zone zustandig und die Nameserver von Verisign fur die Zone der Top-Level-Domain .com.

Eine Zone besteht aus einer Liste von Resource Records. Der BIND-Nameserver sowie dazu kompatible Nameserver-Software speichert die Resource Records in einer Zonendatei.

Ein Resource Record ist ein Datensatz im Domain Name System. Er besteht aus funf Datenfeldern. Beispiel:

www.example.com. 86400 IN A 93.184.216.34

Name

Der Domainname, unter dem der Resource Record abgelegt ist (beispielsweise www.example.com.).

Time to Live

Maximale Zeit in Sekunden, fur die dieser Record in einem DNS-Cache zwischengespeichert werden kann (beispielsweise 86400 Sekunden = 1 Tag).

Klasse

Fast ausschliesslich ,,IN" fur Internet.

Typ

Datentyp der Nutzdaten (beispielsweise A Resource Record: eine IPv4-Adresse).

Daten

Die eigentlichen Nutzdaten (beispielsweise 93.184.216.34).

Der Abruf eines Resource Records erfolgt unter Angabe von Domainname, Klasse und Typ. Da als Klasse nahezu ausschliesslich ,,IN" verwendet wird, sind in der Praxis lediglich der Domainname und Record-Typ relevant. Es sind mehrere Dutzend Record-Typen spezifiziert, die unterschiedlichen Anwendungszwecken dienen.^[9] Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Zu den am haufigsten verwendeten gehoren die folgenden Record-Typen:

Ausgewahlte Resource-Record-Typen

Typ	Zweck/Beschreibung	Typische Verwendung / Beispiel
SOA	Enthalt grundlegende Zonenparameter (Primary-Nameserver, verantwortliche Person, Seriennummer, Refresh-/Retry-/Expire-Werte, Minimum-TTL).	Beginn einer Zonendatei, z. B. fur example.com.
NS	Gibt an, welche Nameserver fur eine Zone zustandig sind (Delegierung).	Delegierung von example.com auf ns1.example.net. und ns2.example.net.
A	Weist einem Namen eine IPv4-Adresse zu.	www.example.com - 93.184.216.34
AAAA	Weist einem Namen eine IPv6-Adresse zu.	www.example.com - 2001:db8::1234
CNAME	Alias-Eintrag: verweist einen Namen auf einen anderen Namen.	www.example.com - webserver.example.com
MX	Gibt die fur den E-Mail-Empfang zustandigen Mailserver einer Domain an (mit Prioritat).	example.com - 10 mail.example.com
SRV	Beschreibt den Standort (Host, Port, Prioritat, Gewichtung) eines bestimmten Dienstes.	_sip._tcp.example.com - SIP-Server von example.com
PTR	Weist einer IP-Adresse einen Namen zu (Reverse DNS).	34.216.184.93.in-addr.arpa - www.example.com
TXT	Frei definierbarer Text; wird u. a. fur Policies, Metadaten und Schlusselmaterial verwendet.	SPF-Informationen, DKIM-Schlussel oder DMARC-Policy fur example.com
SPF	Historischer RR-Typ fur SPF-Informationen (E-Mail-Sender-Policy); in aktuellen Implementierungen wird SPF ublicherweise ausschliesslich uber TXT-Records veroffentlicht.	Vorhandene SPF-Records werden von vielen Systemen ignoriert, stattdessen wird der TXT-Record ausgewertet.
CAA	Legt fest, welche Zertifizierungsstellen (CAs) fur eine Domain Zertifikate ausstellen durfen.	example.com erlaubt nur Zertifikate von letsencrypt.org
DS	Delegation Signer: stellt in der Elternzone einen kryptographischen Verweis auf den offentlichen Schlussel der Kindzone bereit (DNSSEC-Chain-of-Trust).	DS-Record fur example.com in der Zone .com
DNSKEY	Enthalt die offentlichen Schlussel einer Zone fur DNSSEC-Signaturen.	Validierung signierter Antworten fur example.com
NSEC / NSEC3	Ermoglichen kryptographisch gesicherte negative Antworten (>>Name/Typ existiert nicht<<), indem sie zusammenhangende Bereiche vorhandener Namen und Typen angeben.	Signierte NXDOMAIN- und >>no data<<-Antworten fur example.com
TLSA	Hinterlegt Zertifikatsinformationen fur DANE (z. B. zur Absicherung von TLS-Verbindungen zusatzlich oder alternativ zu klassischen CAs).	_25._tcp.mail.example.com: DANE-Eintrag fur SMTP mit TLS
SVCB	Allgemeiner Service-Beschreibungsrecord, mit dem flexible Angaben zu Diensten und Endpunkten gemacht werden konnen (z. B. alternative Ziele, Protokollparameter).	Angabe mehrerer Ziele/Endpunkte fur einen Dienst unter example.com
HTTPS	Spezialisierter SVCB-Typ fur HTTPS-Dienste; ermoglicht z. B. die Beschreibung von HTTPS-Endpunkten, Protokollparametern und Alternativzielen.	https://example.com mit Angabe eines bevorzugten Endpunkts und ALPN-Parametern

Ein Nameserver ist ein Server, der Namensauflosung anbietet. Namensauflosung ist das Verfahren, das es ermoglicht, Namen von Rechnern bzw. Diensten in eine vom Computer bearbeitbare Adresse aufzulosen (z. B. www.wikipedia.org in 91.198.174.192).

Die meisten Nameserver sind Teil des Domain Systems, das auch im Internet benutzt wird.

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

Ein autoritativer Nameserver ist verantwortlich fur eine Zone. Seine Informationen uber diese Zone werden deshalb als gesichert angesehen. Fur jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgefuhrt. Aus Redundanz- und Lastverteilungsgrunden 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 uber 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 andern, 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 Eintrage besitzt ein eigenes Verfallsdatum (TTL time to live), nach dessen Ablauf der Eintrag aus dem Cache geloscht wird. Die TTL wird dabei durch einen autoritativen Nameserver fur diesen Eintrag festgelegt und wird nach der Anderungswahrscheinlichkeit des Eintrages bestimmt (sich haufig andernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umstanden bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, wenn sich die Daten zwischenzeitlich geandert haben.

Ein Spezialfall ist der Caching-Only-Nameserver. In diesem Fall ist der Nameserver fur keine Zone verantwortlich und muss alle eintreffenden Anfragen uber weitere Nameserver (Forwarder) auflosen. Dafur stehen verschiedene Strategien zur Verfugung:

Zusammenarbeit der einzelnen Nameserver

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

Delegierung

Teile des Namensraumes einer Domain werden oft an Subdomains mit dann eigens zustandigen Nameservern ausgelagert. Ein Nameserver einer Domane kennt die zustandigen Nameserver fur diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.

Weiterleitung (forwarding)

Falls der angefragte Namensraum ausserhalb der eigenen Domane liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.

Auflosung uber die Root-Nameserver

Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die Root-Nameserver 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 ausschliesslich iterative Anfragen. Sie waren sonst mit der Anzahl der Anfragen schlicht uberlastet.

Anders konzipierte Namensauflosungen durch Server, wie der NetWare Name Service oder der Windows Internet Naming Service, sind meistens auf Local Area Networks beschrankt und werden zunehmend von der Internetprotokollfamilie verdrangt.

Ein Resolver ist eine Software-Komponente, die per DNS-Protokoll Informationen von einem Nameserver abruft.^[10] Die Anwendung, zum Beispiel ein Webbrowser, fordert per Programmierschnittstelle vom Resolver die Auflosung eines Domainnamens an. Der Resolver fuhrt entweder eine rekursive oder iterative Namensauflosung durch und gibt die Antwort an die Anwendung zuruck.

Im rekursiven Modus schickt der Resolver eine rekursive Anfrage an den ihm zugeordneten Nameserver. Hat dieser die gewunschte Information nicht im eigenen Datenbestand, so kontaktiert der Nameserver weitere Server - und zwar solange, bis er eine positive oder negative Antwort erhalt. Der Nameserver, der die rekursive Anfrage bearbeitet, verwendet selbst einen eigenen Resolver zur Abfrage anderer Nameserver. Ein Nameserver, der rekursive Namensauflosung anbietet, wird als rekursiver Nameserver oder teilweise auch als rekursiver Resolver bezeichnet.^[10]

Im iterativen Modus bekommt der Resolver entweder den gewunschten Resource Record oder einen Verweis auf weitere Nameserver, die er selbst als Nachstes fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver, bis er von dem autoritativen Nameserver eine verbindliche Antwort erhalt. Wahrend beim rekursiven Modus dem angefragten Nameserver die vollstandige Auflosung uberlassen wird, muss beim iterativen Modus der Resolver selbst durch wiederholte (iterative) Anfragen die Auflosung ubernehmen.

Jedes Betriebssystem mit TCP/IP-Netzwerkfunktionalitat enthalt einen Resolver. Ublicherweise handelt es sich dabei um einen simplen Resolver, der ausschliesslich rekursive Anfragen an einen konfigurierbaren Nameserver stellen kann. Ein solcher Resolver wird als Stub-Resolver (von englisch stub: Stumpf oder Stummel) bezeichnet.^[10]

Bekannte Kommandozeilen-Programme zur Namensauflosung sind nslookup, host und dig.

DNS-Anfragen werden normalerweise per UDP Port 53 zum Namensserver gesendet. Der DNS-Standard fordert aber auch die Unterstutzung von TCP fur Fragen, deren Antworten zu gross fur UDP-Ubertragungen sind.^[11] Ursprunglich betrug die maximal zulassige Lange einer DNS-Nachricht uber UDP 512 Bytes.^[12] Mit Extended DNS (EDNS) wurde diese Grossenbeschrankung aufgehoben und kann variabel zwischen Client und Server gewahlt werden.^[13] Beim DNS Flag Day 2020, einer Informationsinitiative von DNS-Software- und DNS-Service-Anbietern, wurde eine standardmassige Maximallange von 1232 Bytes empfohlen.^[14] Die maximal mogliche Nachrichtenlange wird durch die Maximum Transmission Unit begrenzt. Der Einsatz von IP-Fragmentierung ist zwar moglich, wird aber nicht empfohlen.^[14][15]

Uberlange Antworten werden abgeschnitten ubertragen, sodass sie die maximal mogliche Nachrichtenlange des Antwortenden nicht ubersteigen, und mit dem Header-Flag Truncated (TC) als solches markiert. Der Anfragende kann daraufhin die Anfrage uber TCP wiederholen.^[16] Bei TCP betragt die maximale Nachrichtenlange 65.535 Bytes.^[17] Die Verwendung von persistenten Verbindungen und Pipelining ist moglich.^[18] Zonentransfers werden stets uber TCP durchgefuhrt, wobei die Nachrichtenlangenbeschrankung dafur nicht relevant ist.^[17]

Angenommen, ein Client will eine Verbindung zu einem Webserver unter dem Domainnamen de.wikipedia.org. aufbauen. Dazu braucht er dessen IP-Adresse. In den folgenden Schritten wird ein exemplarischer Ablauf beschrieben. Bei Verwendung von IPv4 ruft der Client den A Resource Record und bei IPv6 den AAAA Resource Record ab. Bei Dual-Stack fragt der Client beide Adresstypen gleichzeitig ab und wahlt die zu verwendende Zieladresse uber einen Algorithmus aus, wobei standardmassig IPv6 bevorzugt wird.^[19]

1. Das Betriebssystem des Clients verwendet zunachst lokale Mechanismen zur Namensauflosung, wie beispielsweise eine Hosts-Datei. Diese Mechanismen sind kein Bestandteil des Domain Name Systems und sind hier nur der Vollstandigkeit halber erwahnt. Falls sie kein Ergebnis liefern, beginnt die eigentliche DNS-Namensauflosung.
2. Der (Stub-)Resolver des Betriebssystems fragt den Domainnamen de.wikipedia.org. beim zugeordneten Nameserver ab. Die IP-Adresse des Nameservers wurde entweder manuell eingetragen oder automatisch per DHCP, DHCPv6 oder NDP zugewiesen.
3. Hat der angefragte Nameserver den Namen im DNS-Cache zwischengespeichert, antwortet er damit, was die Namensauflosung abschliesst (siehe letzter Punkt). Andernfalls erbringt er die Funktionalitat eines rekursiven Resolvers.
4. Der rekursive Resolver fragt einen der 13 Root-Nameserver nach de.wikipedia.org. Der Root-Nameserver antwortet mit einem Verweis auf die Nameserver der Top-Level-Domain .org. Der Verweis besteht aus mehreren NS Resource Records sowie aus Glue Records (A und AAAA Resource Records), die die IP-Adressen der Nameserver von org. enthalten.
5. Der rekursive Resolver fragt einen der Nameserver von org. nach de.wikipedia.org. Der Nameserver antwortet mit einem Verweis auf die Nameserver von wikipedia.org., bestehend aus NS Resource Records und Glue Records.
6. Der rekursive Resolver fragt einen der Nameserver von wikipedia.org. nach de.wikipedia.org. Dieser ist autoritativ fur die Zone wikipedia.org. und antwortet mit den angefragten A oder AAAA Resource Records.
7. Der rekursive Resolver schickt die Antwort an den Client zuruck, welcher nun zum Beispiel eine HTTPS-Verbindung zu der IP-Adresse von de.wikipedia.org. aufbauen kann.

Da sich das DNS als zuverlassig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere grossere Erweiterungen eingefuhrt. Ein Ende dieses Trends ist nicht absehbar.

Die manuelle Anderung von DNS-Eintragen ist mit Aufwand verbunden. Durch DNS-Caching kann es zudem mehrere Stunden oder sogar Tage dauern, bis sich eine Anderung im Netz verbreitet hat. Dynamisches DNS ermoglicht die automatisierte Aktualisierung von DNS-Eintragen. In Kombination mit der Verwendung eines niedrigen Time-to-Live-Werts konnen Resource Records mit geringem Aufwand und geringer Zeitverzogerung aktualisiert werden. Ein typischer Einsatzzweck ist die automatische Aktualisierung von A oder AAAA Resource Records bei der Verwendung von dynamischen IP-Adressen.

Dynamisches DNS kann ein Sicherheitsrisiko darstellen, falls die Schnittstelle zur Aktualisierung von DNS-Eintragen nicht gegen unautorisierte Zugriffe abgesichert ist. Bei einer REST-API kann die Absicherung durch den Einsatz von HTTPS und einer Authentifizierung des Clients erfolgen. Bei DNS-Update kann die Absicherung per TSIG erfolgen.

Bisher waren die Labels auf alphanumerische Zeichen und das Zeichen ,-' eingeschrankt. Moglich, aber nicht standardkonform, ist bei Subdomains zudem ,_'. Dieser begrenzte Zeichenvorrat hangt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprunglich) in den USA entwickelt wurde. Damit waren in vielen Landern gebrauchliche Schriftzeichen (im deutschen Sprachraum zum Beispiel die Umlaute a, o und u sowie ss) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprunglich nicht in Domainnamen moglich.

Ein mittlerweile etablierter Ansatz zur Vergrosserung des Zeichenvorrats ist die 2003 in RFC 3490^[20] eingefuhrte und 2010 mit RFC 5890^[21] aktualisierte Internationalisierung von Domainnamen (IDNA). Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensatze mit den bislang zulassigen Zeichen kodiert. Die erweiterten Zeichensatze werden dabei zunachst normalisiert, um unter anderem Grossbuchstaben auf Kleinbuchstaben abzubilden, und anschliessend per Punycode auf einen ASCII-kompatiblen String abgebildet. IDNA erfordert eine Anpassung der Netzwerkanwendungen (zum Beispiel Webbrowser), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verandert zu werden. Im deutschsprachigen Raum konnen seit Marz 2004 deutsche, liechtensteinische, osterreichische und schweizerische Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden. Auch bei anderen Top-Level-Domains, insbesondere im asiatischen Raum, ist die Verwendung von internationalisierten Domainnamen moglich.

1999 beschrieb Paul Vixie im RFC 2671^[22] einige kleinere, abwartskompatible Erweiterungen am Domain Name System, die als Extended DNS Version 0 bezeichnet werden. Durch Einsatz eines Pseudo-Records als Header-Erweiterung kann der Anfragende zusatzliche Optionen setzen. Insbesondere kann er ubermitteln, dass er UDP-Antworten grosser als 512 Bytes entgegennehmen kann. DNSSEC-fahige Server und Resolver mussen EDNS beherrschen.

Eine weitere aktuelle Erweiterung des DNS stellt ENUM (RFC 2916^[23]) dar. Diese Anwendung ermoglicht die Adressierung von Internet-Diensten uber Telefonnummern, also das ,,Anwahlen" von per Internet erreichbaren Geraten mit dem aus dem Telefonnetz bekannten Nummerierungsschema. Aus dem breiten Spektrum der Einsatzmoglichkeiten bietet sich insbesondere die Verwendung fur Voice-over-IP-Diensten an.

Mit der RFID konnen auf speziellen RFID-Etiketten abgelegte IDs - sogenannte elektronische Produktcodes oder EPCs - beruhrungslos gelesen werden. Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten uber das zugehorige Objekt enthalt. Der Object Name Service (ONS) wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer (NAPTR).

Zur Filterung von Spam-Mails uberprufen viele Mailserver den DNS-Eintrag des sendenden Mailservers routinemassig mit Hilfe des Reverse-DNS-Lookups. Dieser muss nicht nur auch vorwarts wieder korrekt auflosen und auf die IP-Adresse des sendenden Systems zeigen (Forward-confirmed reverse DNS), sondern muss auch dem im SMTP-Protokoll genannten HELO-Hostnamen des sendenden Systems entsprechen.

Mittels Sender Policy Framework wird versucht, den Versand von gefalschten Absendern durch Dritte moglichst zu unterbinden. Zu jeder Mail-Domain wird dabei uber einen speziellen SPF Resource Record explizit aufgelistet, von welchen Servern und IP-Netzen mit E-Mails dieser Domain zu rechnen ist. SPF steht jedoch wegen zahlreicher technischer Schwierigkeiten, beispielsweise bei Weiterleitungen, in der Kritik.

Auch der Anti-Spam-Mechanismus DKIM greift auf Eintrage im DNS zuruck, indem sendende Mailserver in DNS-TXT-Records ihren Public-Key veroffentlichen, mit dem die Signatur ihrer ausgehenden E-Mails verifiziert werden kann.

Neben den IP-Adressen konnen DNS-Namen auch ISDN-Nummern, X.25-Adressen, ATM-Adressen, offentliche Schlussel, Text-Zeilen usw. zugeordnet werden. In der Praxis sind derartige Anwendungsfalle aber die Ausnahme.

DNS ist nicht auf das Internet beschrankt. Es ist ohne weiteres moglich und mit der Definition vertraglich, fur die Auflosung 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 konnen.

Bei grosseren Firmen oder Organisationen ist haufig 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 konnen dadurch sehr komplizierte Konstellationen entstehen.

Der DNS-Server BIND kann auch mit DHCP zusammenarbeiten und damit fur jeden Client im Netz eine Namensauflosung ermoglichen.

Unter Windows gibt es noch einen anderen Dienst zur Namensauflosung - WINS, der eine ahnliche Funktion zur Verfugung stellt, allerdings ein anderes Protokoll verwendet.

Es ist moglich, mehrere DNS-Server zu verbinden. Die primaren Server sind fur eine oder mehrere Domains verantwortlich. Die sekundaren Server aktualisieren nach einer Anderung selbst die Daten, der Primare verteilt diese Daten nicht automatisiert. Die Abholung der Daten wird uber einen Zonentransfer realisiert.

Beispielsweise kann eine Firma mit mehreren Standorten an einem Platz einen primaren Server fur ihr internes DNS betreiben, der die Server in den Aussenstellen versorgt. Der Zonentransfer geht bei BIND uber TCP (per Default Port 53) und erfordert empfohlenerweise Authentifizierung. Die sekundaren Server aktualisieren sich, wenn sich die Seriennummer fur eine Zonendatei andert oder sie eine entsprechende Nachricht vom primaren Server erhalten. Die Freigabe fur den Transferport sollte man per Firewall an die IP-Adresse des primaren Servers binden. Bei anderen Softwarepaketen werden die Daten unter Umstanden auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.

Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur. Eine Storung kann erhebliche Kosten nach sich ziehen und eine Verfalschung von DNS-Daten Ausgangspunkt von Angriffen sein.

Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschliessend Passworter, PINs, Kreditkartennummern usw. zu erhalten. In seltenen Fallen wird versucht, den Internet-DNS durch Denial-of-Service-Attacken komplett auszuschalten und so das Internet lahmzulegen. Ausserdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.

Bei einem Distributed-Denial-of-Service-Angriff werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen uberlastet, so dass legitime Anfragen nicht mehr beantwortet werden konnen. Gegen DDoS-Angriffe auf Nameserver gibt es zurzeit keine Abwehrmoglichkeit. Als vorbeugende Massnahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw. ein verteiltes Netz mit moglichst vielen Servern zu installieren. Um eine grosse Anzahl DNS-Anfragen zu erzeugen, werden bei solchen Angriffen Botnetze eingesetzt.

Ein DDoS-Angriff kann unbeabsichtigt einen DNS-Server betreffen und zum Ausfall bringen, wenn der Domainname des Angriffsziels wiederholt aufgelost wird ohne zwischengespeichert zu werden. Der Effekt auf DNS-Server wird verhindert, wenn das DDoS-Schadprogramm DNS-Caching verwendet.

Die DNS Amplification Attack ist ein Denial-of-Service-Angriff, bei der nicht der DNS-Server selbst das eigentliche Angriffsziel ist, sondern ein Dritter. Ausgenutzt wird, dass ein DNS-Server in manchen Fallen auf kurze Anfragen sehr lange Antworten zurucksendet. Durch eine gefalschte Absenderadresse werden diese an die IP-Adresse des Opfers gesendet. Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substanziell verstarken und so den Internet-Zugang seines Angriffsziels storen.

Beim DNS-Spoofing handelt es sich um eine Angriffsklasse von Maskierungsangriffen, die das Ziel haben eine falsche Identitat vorzugeben. Dafur wird die DNS-Antwort an einen Client verandert um ihn auf einen anderen, meist vom Angreifer kontrollierten Dienst fehlzuleiten.

DNS-Cache-Poisoning bezeichnet ein Angriffsszenario, welches in die Angriffsklasse des DNS-Spoofing fallt. Dabei werden einem anfragenden Client zusatzlich zu der korrekten Antwort, manipulierte Daten ubermittelt, die dieser in seinen Cache ubernimmt und spater, moglicherweise ungepruft, verwendet.

Wer einen autoritativen DNS-Server fur seine eigenen Domains betreibt, muss naturlich fur Anfragen von beliebigen IP-Adressen offen sein. Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z. B. fur Angriffe auf Root-Server), erlaubt BIND es, die Antworten auf die eigenen Domains einzuschranken. Beispielsweise bewirkt die Option allow-recursion {127.0.0.1; 172.16.1.4;};, dass rekursive Anfragen, d. h. Anfragen auf andere Domains, ausschliesslich fur den lokalen Host (localhost) sowie 172.16.1.4 beantwortet werden. Alle anderen IP-Adressen bekommen nur auf Anfragen auf eigene Domains eine Antwort.

Ein offener DNS-Server kann auch eine Falle sein, wenn er gefalschte IP-Adressen zuruckgibt, siehe Pharming.

Mehr als zehn Jahre nach der ursprunglichen Spezifikation wurde DNS um Security-Funktionen erganzt. Folgende Verfahren sind verfugbar:

Bei DNSSEC (Domain Name System Security Extensions) wird von einem asymmetrischen Kryptosystem Gebrauch gemacht. Neben der Server-Server-Kommunikation kann auch die Client-Server-Kommunikation gesichert werden. Dies soll die Manipulation der Antworten erschweren.

Bei DNS over TLS sollen sowohl DDoS-Angriffe, die Manipulation der Antworten als auch das Ausspahen der gesendeten Daten verhindert werden. Dazu werden die DNS-Abfragen per Transport Layer Security (TLS) abgesichert.^[24]

DNS over QUIC soll die Vorteile von DoT und DoH kombinieren. DoQ soll gute Privatsphare und Sicherheit bieten, eine geringe Latenz aufweisen und nicht blockierbar sein.^[25] RFC 9250^[26] der Internet Engineering Task Force beschreibt DoQ.^[27]

DNS over HTTPS andert das DNS-System grundlegend. Anfragen finden hier auf Anwendungsebene statt. Anwendungen wie beispielsweise der Webbrowser fragen direkt beim DNS-Server an, anstatt die Anfrage an das Betriebssystem weiterzuleiten. Dadurch sehen DNS-Anfragen aus wie normaler Internetverkehr und konnen somit nicht gezielt abgefangen bzw. blockiert werden.^[24]

Cloudflare und Google bieten offentliche DoH-Webserver an. Mozilla Firefox unterstutzt DoH ab Version 60 als experimentelle Funktion. Mozilla stellt in Zusammenarbeit mit Cloudflare einen DoH-Server bereit, der strenge Privatsphare-Anforderungen erfullen muss.^[24][28]

DNS kann uber virtuelle private Netzwerke (VPNs) und Tunneling-Protokolle betrieben werden. Eine Anwendung, die seit 2019 so weit verbreitet ist, dass sie ein eigenes, haufig verwendetes Akronym rechtfertigt, ist DNS over Tor.

Bei TSIG (Transaction Signatures) handelt es sich um ein einfaches, auf symmetrischen Schlusseln beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern und Updates von Clients gesichert werden kann.

Um DNS-Namen im Internet bekannt machen zu konnen, muss der Besitzer die Domain, die diesen Namen enthalt, registrieren. Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind. Domain-Registrierungen werden von Organisationen (Registries, z. B. Verisign oder Afilias) vorgenommen, die dazu von der IANA bzw. ICANN autorisiert wurden. Registrierungen sind (von wenigen Ausnahmen abgesehen) gebuhrenpflichtig. Fur Domains unter .de ist die DENIC zustandig. In den allermeisten Fallen konnen Domains bei den Registries nur uber Zwischenhandler, sogenannte Registrare wie Godaddy oder 1&1 Internet SE registriert werden, die mit den Registries entsprechende Vertrage abgeschlossen haben.

Apple hat bei der Entwicklung von macOS mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermoglichen soll. Zum einen wurde Multicast DNS (,,mDNS") eingefuhrt, das die Namensauflosungen in einem LAN ohne einen dedizierten Namensserver erlaubt. Zusatzlich wurde noch DNS-SD (fur ,,DNS Service Discovery") eingefuhrt, die die Suche (,,Browsing") nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermoglicht. mDNS und DNS-SD sind bisher keine offiziellen RFCs des IETF, sind aber trotzdem bereits in verschiedenen (auch freien) Implementierungen verfugbar. Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen ,,Zeroconf" zusammen, als Bestandteil von OS X auch als ,,Rendezvous" bzw. ,,Bonjour". Die meisten Linux-Distributionen unterstutzen diese Erweiterung z. B. mit der avahi-Implementierung von Zeroconf.

Standardmassig wird der DNS-Servern durch den Mobilfunkanbieter ausgewahlt, oder durch die Anwendung die gerade genutzt wird. Mozilla Firefox verwendet bspw. Cloudflare um DNS-Anfragen aufzulosen. Innerhalb eines Netzwerkes, oder lokal auf einem Gerat, kann jedoch nach eigener Praferenz ein DNS-Server eingestellt werden.

Seit der Debatte um das Zugangserschwerungsgesetz (2008) und Zensur im Internet im Allgemeinen gibt es eine Reihe von alternativen DNS-Anbietern, die Domains nach eigener Aussage nicht zensieren. Beispiele sind Organisationen wie Digitalcourage, Freifunk Munchen^[29] oder Digitale Gesellschaft. Auch von Privatpersonen werden alternative DNS-Server bereitgestellt.^[30][31]

Es kann unterschiedliche Grunde geben einen DNS-Server zu nutzen, der mit Schwarzen Listen arbeitet, also bestimmte Anfragen an Webseiten nicht auflost. So konnen gezielt Werbetreibende blockiert werden (siehe auch: Werbeblocker), auch gibt es Anbieter, die versprechen, die Cybersicherheit oder die Privatsphare zu verbessern. Das Blockieren von nicht jugendfreien Inhalten ist ein weiterer Einsatzzweck. Technisch betrachtet handelt es sich bei der Verwendung von Filterlisten um eine Zensur von Inhalten. Die Grenzen zur Meinungszensur sind jedoch unscharf und werden subjektiv empfunden. Einige Anbieter fuhren Blocklisten uber Fake-News-Websiten; die Kriterien, nach denen die Einordnung erfolgt, sind hierbei teilweise nicht offengelegt. Grosse Anbieter, die blockierende DNS-Server betreiben, sind unter anderen: Quad9, Mullvad und Adguard. Die EU kundigte 2022 an, einen eigenen DNS-Server etablieren zu wollen (DNS4EU), dieser soll ebenfalls mit Filterlisten arbeiten und Netzsperren umsetzen.^[32]

Namecoin ist der erste Fork von Bitcoin aus dem Jahr 2011 und findet Anwendung als Kryptowahrung sowie als Key-Value Store fur Domainnamen und Identitaten. Als alternatives verteiltes Domain Name System (DNS) ausserhalb des ICANN-Namensraumes werden Transaktionen zum Registrieren, Aktualisieren und Ubertragen von Domains auf der Blockchain aufgezeichnet. Zur Auflosung der .bit-Adressen werden ein Browserplugin oder ein lokaler Namecoin DNS-Server benotigt. Ebenso wie Bitcoin ist Namecoin ein dezentrales Peer-to-Peer-System, das keiner Zensur unterliegt.^[33] Die Software ist Open Source und wird auf GitHub gehostet.^[34]

Einem Bericht von Trend Micro zufolge wurden .bit-Domains seit 2013 vermehrt auch von Cyberkriminellen genutzt.^[35] Vornehmlich aus diesem Grund hat das OpenNIC-Projekt im Sommer 2019 seine DNS-Auflosung von .bit-Domains eingestellt.^[36]

Auswahl bekannter Software fur Namensauflosung.

• BIND (Berkeley Internet Name Domain) ist die meistgebrauchte Nameserversoftware und gilt als Referenzimplementierung der meisten RFCs zu DNS. Die erste Version von BIND war die erste offentlich verfugbare Nameserver-Implementierung.
• CoreDNS ist ein in Go geschriebener DNS-Server der Cloud Native Computing Foundation.
• Bei djbdns hat der Autor Daniel J. Bernstein eine Pramie fur das Finden von Sicherheitsproblemen ausgeschrieben. Djbdns wird von Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht.
• Dnsmasq ist ein Nameserver und DHCP-Server mit eingeschrankter Funktionalitat. Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelost. Dnsmasq verfugt uber keinen vollstandigen Resolver: unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert.
• Knot DNS ist ein autoritativer Nameserver, der von CZ.NIC entwickelt wird, dem Betreiber von .cz.
• Microsoft Windows DNS ist eine der wenigen kommerziellen Nameserver-Implementierungen als Teil der Produktreihe Microsoft Windows Server. Der Nameserver unterstutzt dynamische Updates, Zonentransfers und Notification. Zonendaten konnen in den aktuellen Versionen im Active Directory oder in Zonendateien gespeichert und repliziert werden.
• Name Server Daemon ist ein autoritativer Nameserver, der zum Einsatz als Top-Level-Domain- und Root-Nameserver entwickelt wurde. NSD kompiliert Antworten statisch vor, um die Server-Performance zu optimieren. Dynamische Zoneninhalte oder Round Robin werden nicht unterstutzt.
• PowerDNS ist ein Nameserver, der Zonen aus SQL-Datenbanken, LDAP-Verzeichnissen und anderen Backends lesen kann. PowerDNS begann als kommerzielle Implementierung und ist seit 2002 unter der GPL lizenziert.
• Unbound ist ein DNS-Resolver, der DNSSEC-Validierung und Caching unterstutzt. Unbound kann als Softwarebibliothek in Anwendungen eingebunden werden.

• RFCs
  • RFC: 1034 - Domain Names - Concepts and Facilities. 1987 (englisch).
  • RFC: 1035 - Domain Names - Implementation and Specification. 1987 (englisch).
  • RFC: 2181 - Clarifications to the DNS Specification. (englisch).
  • RFC: 2782 - A DNS RR for specifying the location of services (DNS SRV). (englisch).
• Multicast DNS
• Funktionsweise und Verwaltung des DNS als Poster
• Beitrage des Chaos Computer Clubs
  • Zensur durch DNS-Server: DNS Howto
  • Podcast zum Thema DNS: Chaosradio Express 099 - Domain Name System
• Julia Evans: Life of a DNS query. Wizard Zines (DNS-Abfrage als Comic)

1. | RFC: 7858 - Specification for DNS over Transport Layer Security (TLS). Mai 2016 (englisch).
2. | RFC: 8094 - DNS over Datagram Transport Layer Security (DTLS). Februar 2017 (englisch).
3. | ^{a b} RFC: 1034 - Domain Names - Concepts and Facilities. 1987 (englisch).
4. | ^{a b} RFC: 1035 - Domain Names - Implementation and Specification. 1987 (englisch).
5. | Artikel 4 Nr. 14 der Richtlinie (EU) 2016/1148
6. | Paul Mockapetris: RFC: 882 - Domain Names - Concepts and Facilities. November 1983 (englisch).
7. | Paul Mockapetris: RFC: 883 - Domain Names - Implementation and Specification. November 1983 (englisch).
8. | RFC: 2181 - Clarifications to the DNS Specification. Abschnitt 11: Name syntax. (englisch).
9. | iana.org
10. | ^{a b c} RFC: 8499 - DNS Terminology. Januar 2019 (englisch).
11. | RFC: 7766 - DNS Transport over TCP - Implementation Requirements. Marz 2010, Abschnitt 1: Introduction. (englisch). "This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. [...] It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts."
12. | RFC: 1035 - Domain Names - Implementation and Specification. 1987, Abschnitt 2.3.4: Size limits. (englisch).
13. | RFC: 6891 - Extension Mechanisms for DNS (EDNS(0)). April 2013, Abschnitt 6.2.5: Payload Size Selection. (englisch).
14. | ^{a b} dnsflagday.net
15. | bsi.bund.de
16. | RFC: 6891 - Extension Mechanisms for DNS (EDNS(0)). April 2013, Abschnitt 4.3: UDP Message Size. (englisch).
17. | ^{a b} RFC: 5936 - DNS Zone Transfer Protocol (AXFR). Juni 2010, Abschnitt 2: AXFR Messages. (Ende; gem#ss RFC:1035, englisch).
18. | RFC: 7766 - DNS Transport over TCP - Implementation Requirements. Marz 2010, Abschnitt 6.2: Recommendations. (englisch).
19. | RFC: 6724 - Default Address Selection for Internet Protocol Version 6 (IPv6). September 2012, Abschnitt 2.1: Policy Table. (englisch). "Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available."
20. | RFC: 3490 - Internationalizing Domain Names in Applications (IDNA). Marz 2003 (englisch).
21. | RFC: 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. August 2010 (englisch).
22. | RFC: 2671 - Extension Mechanisms for DNS (EDNS0). August 1999 (englisch).
23. | RFC: 2916 - E.164 number and DNS. September 2000 (englisch).
24. | ^{a b c} Carsten Strotmann, Jurgen Schmidt: DNS mit Privacy und Security vor dem Durchbruch. Ehemals im Original (nicht mehr online verfugbar); abgerufen am 25. Juli 2018.@1@2Vorlage:Toter Link/www.heise.de (Seite nicht mehr abrufbar. Suche in Webarchiven)
25. | DoQ soll nicht manipulierbar sein, die gleiche Privatsphare wie DoT bieten, eine geringe Latenz wie unverschlusseltes DNS uber UDP und nicht blockierbar sein wie DoH. Abgerufen am 28. Januar 2021.
26. | RFC: 9250 - DNS over Dedicated QUIC Connections. Mai 2022 (englisch).
27. | Verbesserte Namensauflosung: IETF veroffentlicht RFC zum Internetprotokoll QUIC. In: heise online. Abgerufen am 20. Juli 2022.
28. | Patrick McManus: Improving DNS Privacy in Firefox. Abgerufen am 26. Juli 2018 (englisch).
29. | DNS-over-HTTPS und DNS-over-TLS Unterstutzung. ffmuc.net
30. | Vertrauenswurdige DNS-Server. Abgerufen am 19. Februar 2021.
31. | Encrypted DNS Resolvers. Abgerufen am 3. Mai 2021 (englisch).
32. | EU will eigenen DNS-Server mit Filterlisten und Netzsperren. Abgerufen am 16. Oktober 2023.
33. | Kevin Helms: How to Obtain and Use .Bit Privacy Domains. In: Bitcoin News. 7. Marz 2017, abgerufen am 19. Marz 2020 (englisch).
34. | Namecoin. Abgerufen am 6. Marz 2020 (englisch, Projektwebsite).
35. | .bit - The next Generation of Bulletproof Hosting. In: abuse.ch. 25. September 2017, abgerufen am 19. Marz 2020 (englisch).
36. | Catalin Cimpanu: OpenNIC drops support for .bit domain names after rampant malware abuse. In: ZDNet. 17. Juli 2019, abgerufen am 19. Marz 2020 (englisch).

Abgerufen von ,,https://de.wikipedia.org/w/index.php?title=Domain_Name_System&oldid=263573937"

Kategorien:

• Domain Name System
• Internet-Anwendungsprotokoll
• Internetstandard

Versteckte Kategorie:

• Wikipedia:Weblink offline