Domain Name System

Das Domain Name System ( DNS ) ist ein hierarchischer und verteilter Namendienst , der ein Benennungssystem für Computer , Dienste und andere Ressourcen im Internet und anderen IP -Netzwerken bereitstellt. Es verknüpft verschiedene Informationen mit den Domainnamen ( Identifikationszeichenfolgen ), die den jeweiligen Entitäten zugewiesen werden. Vor allem übersetzt es leicht zu merkende Domainnamen in die numerischen IP-Adressen, die zum Auffinden und Identifizieren von Computern, Diensten und Geräten mithilfe der zugrunde liegenden Netzwerkprotokolle benötigt werden . ^{[ 1 ]} Das Domain Name System ist seit 1985 ein wesentlicher Bestandteil der Funktionalität des Internets.

Das Domain Name System (DNS) delegiert die Verantwortung für die Vergabe von Domainnamen und deren Zuordnung zu Internetressourcen, indem es für jede Domain autoritative Nameserver festlegt . Netzwerkadministratoren können die Zuständigkeit für Subdomains ihres zugewiesenen Namensraums an andere Nameserver delegieren. Dieser Mechanismus bietet einen verteilten und ausfallsicheren Dienst und wurde entwickelt, um eine einzige große zentrale Datenbank zu vermeiden. Darüber hinaus spezifiziert das DNS die technische Funktionalität des Datenbankdienstes , der seinen Kern bildet. Es definiert das DNS-Protokoll, eine detaillierte Spezifikation der im DNS verwendeten Datenstrukturen und Datenkommunikationsmechanismen , als Teil der Internetprotokollfamilie .

Das Internet verwendet zwei Hauptnamensräume : die Domainnamenhierarchie und den IP- Adressraum . ^{[ 2 ]} Das Domain Name System (DNS) verwaltet die Domainnamenhierarchie und stellt Übersetzungsdienste zwischen ihr und dem Adressraum bereit. Internet-Nameserver und ein Kommunikationsprotokoll implementieren das DNS. Ein DNS-Nameserver speichert die DNS-Einträge für eine Domain und beantwortet Anfragen an seine Datenbank.

Die häufigsten Arten von Einträgen in der DNS-Datenbank sind SOA-Einträge (Start of Authority ), IP-Adressen ( A und AAAA ), SMTP- Mailserver (MX), Nameserver (NS), PTR-Einträge ( Reverse DNS Lookup ) und CNAME -Einträge (Domain Name Alias ). Obwohl die DNS-Datenbank ursprünglich nicht als universelle Datenbank gedacht war, wurde sie im Laufe der Zeit erweitert, um Einträge für weitere Datentypen zu speichern – entweder für automatische Abfragen wie DNSSEC -Einträge oder für Anfragen von Nutzern wie RP-Einträge ( Responsible Person ). Als universelle Datenbank wird die DNS-Datenbank auch zur Bekämpfung von Spam ( unerwünschten E-Mails ) eingesetzt, indem sie Sperrlisten speichert . Die DNS-Datenbank wird üblicherweise in einer strukturierten Textdatei, der Zonendatei , gespeichert; es sind aber auch andere Datenbanksysteme üblich.

Das Domain Name System nutzte ursprünglich das User Datagram Protocol (UDP) als Transportprotokoll über IP. Bedenken hinsichtlich Zuverlässigkeit, Sicherheit und Datenschutz führten zur Verwendung des Transmission Control Protocol (TCP) sowie zahlreicher weiterer Protokollentwicklungen.

Eine häufig verwendete Analogie zur Erklärung des DNS ist, dass es als Telefonbuch des Internets fungiert, indem es für Menschen verständliche Computer- Hostnamen in IP-Adressen übersetzt. Beispielsweise wird der Hostname www.example.cominnerhalb der Domain example.com in die Adressen 93.184.216.34 ( IPv4 ) und 2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ) übersetzt. Das DNS kann schnell und transparent aktualisiert werden, sodass sich der Standort eines Dienstes im Netzwerk ändern kann, ohne dass die Endbenutzer beeinträchtigt werden, da sie weiterhin denselben Hostnamen verwenden. Benutzer profitieren davon, indem sie aussagekräftige URLs und E-Mail-Adressen verwenden , ohne wissen zu müssen, wie der Computer die Dienste tatsächlich findet.

Eine wichtige und allgegenwärtige Funktion des DNS ist seine zentrale Rolle in verteilten Internetdiensten wie Cloud-Diensten und Content Delivery Networks (CDNs) . ^{[ 3 ]} Greift ein Nutzer über eine URL auf einen verteilten Internetdienst zu, wird der Domainname der URL in die IP-Adresse eines Servers in der Nähe des Nutzers übersetzt. Die hier genutzte Schlüsselfunktionalität des DNS besteht darin, dass verschiedene Nutzer gleichzeitig unterschiedliche Übersetzungen für denselben Domainnamen erhalten können – ein wesentlicher Unterschied zur traditionellen Vorstellung eines DNS als Telefonbuch. Dieser Prozess der Zuordnung von Servern in der Nähe von Nutzern mithilfe des DNS ist entscheidend für schnellere und zuverlässigere Antworten im Internet und wird von den meisten großen Internetdiensten genutzt. ^{[ 4 ]}

Das DNS spiegelt die Struktur der administrativen Verantwortung im Internet wider. ^{[ 5 ]} Jede Subdomain ist eine Zone administrativer Autonomie, die einem Manager übertragen wurde. Bei von einer Registry betriebenen Zonen werden die administrativen Informationen häufig durch die RDAP- und WHOIS- Dienste der Registry ergänzt . Mithilfe dieser Daten lassen sich Einblicke in einen bestimmten Host im Internet gewinnen und die Verantwortlichkeit dafür nachverfolgen. ^{[ 6 ]}

Die Verwendung eines einfacheren, einprägsameren Namens anstelle der numerischen Hostadresse geht auf die ARPANET- Ära zurück. Das Stanford Research Institute (heute SRI International ) pflegte eine Textdatei namens HOSTS.TXT , die Hostnamen den numerischen Adressen von Computern im ARPANET zuordnete. ^{[ 7 ] [ 8 ]} Elizabeth Feinler entwickelte und pflegte das erste ARPANET-Verzeichnis. ^{[ 9 ] [ 10 ]} Die Verwaltung der numerischen Adressen, der sogenannten Liste zugewiesener Nummern, oblag Jon Postel am Information Sciences Institute (ISI) der University of Southern California , dessen Team eng mit SRI zusammenarbeitete. ^{[ 11 ]}

Die Adressen wurden manuell vergeben. Computer, einschließlich ihrer Hostnamen und Adressen, wurden der Hauptdatei hinzugefügt, indem man sich während der Geschäftszeiten telefonisch an das SRI Network Information Center (NIC) unter der Leitung von Feinler wandte. ^{[ 12 ]} Später richtete Feinler auf einem Server im NIC ein WHOIS- Verzeichnis ein, um Informationen über Ressourcen, Kontakte und Entitäten abzurufen. ^{[ 13 ]} Sie und ihr Team entwickelten das Konzept der Domänen. ^{[ 13 ]} Feinler schlug vor, dass Domänen auf dem Standort der physischen Adresse des Computers basieren sollten. ^{[ 14 ]} Computer in Bildungseinrichtungen hätten beispielsweise die Domäne „edu“ . ^{[ 15 ]} Sie und ihr Team verwalteten die Host Naming Registry von 1972 bis 1989. ^{[ 16 ]}

Anfang der 1980er-Jahre erwies sich die Pflege einer zentralen Hosttabelle als langsam und umständlich, und das entstehende Netzwerk benötigte ein automatisiertes Namenssystem, um technische und personelle Probleme zu lösen. Postel beauftragte Paul Mockapetris mit der Ausarbeitung eines Kompromisses zwischen fünf konkurrierenden Lösungsvorschlägen . Mockapetris entwickelte stattdessen 1983 an der University of Southern California das Domain Name System (DNS) . ^{[ 12 ] [ 17 ]}

Die Internet Engineering Task Force veröffentlichte die ursprünglichen Spezifikationen in RFC 882 und RFC 883 im November 1983. ^{[ 18 ] [ 19 ]} Diese wurden im Januar 1986 in RFC 973 aktualisiert. ^{[ 20 ]}

1984 entwickelten vier Studenten der UC Berkeley – Douglas Terry, Mark Painter, David Riggle und Songnian Zhou – die erste Unix- Nameserver- Implementierung für die Berkeley Internet Name Domain, kurz BIND . ^{[ 21 ]} 1985 überarbeitete Kevin Dunlap von DEC die DNS-Implementierung grundlegend. Mike Karels , Phil Almquist und Paul Vixie übernahmen daraufhin die Wartung von BIND. Das Internet Systems Consortium (ISC) wurde 1994 von Rick Adams , Paul Vixie und Carl Malamud eigens für die Entwicklung und Wartung von BIND gegründet. BIND-Versionen ab 4.9.3 wurden vom ISC mit Unterstützung seiner Sponsoren entwickelt und gewartet. Als Co-Architekten und -Programmierer veröffentlichten Bob Halley und Paul Vixie im Mai 1997 die erste produktionsreife Version von BIND 8. Seit 2000 haben über 43 verschiedene Kernentwickler an BIND mitgewirkt. ^{[ 22 ]}

Im November 1987 lösten die RFCs 1034 ^{[ 23 ]} und 1035 ^{[ 5 ]} die DNS-Spezifikationen von 1983 ab. Mehrere weitere Request for Comments (RFCs) schlugen Erweiterungen der DNS-Kernprotokolle vor. ^{[ 24 ]}

Der Domainnamenraum besteht aus einer Baumdatenstruktur . Jeder Knoten oder jedes Blatt im Baum besitzt eine Bezeichnung und null oder mehrere Ressourceneinträge (Resource Records, RR), die Informationen zum Domainnamen enthalten. Der Domainname selbst besteht aus der Bezeichnung, rechts angehängt durch einen Punkt, und dem Namen des übergeordneten Knotens. ^{[ 23 ] : §3.1}

Der Baum ist in Zonen unterteilt, beginnend mit der Wurzelzone . Eine DNS-Zone kann beliebig viele Domänen und Subdomänen enthalten, je nach Wahl des Zonenmanagers. DNS kann auch nach Klassen partitioniert werden , wobei die einzelnen Klassen als Array paralleler Namensraumbäume betrachtet werden können. ^{[ 23 ] : §4.2}

Die administrative Zuständigkeit für eine Zone kann durch die Schaffung zusätzlicher Zonen aufgeteilt werden. Die Autorität über die neue Zone wird einem designierten Nameserver übertragen . Die übergeordnete Zone verliert ihre Autorität für die neue Zone. ^{[ 23 ] : §4.2}

Die endgültigen Beschreibungen der Regeln für die Bildung von Domainnamen finden sich in RFC 1035, RFC 1123, RFC 2181 und RFC 5892. Ein Domainname besteht aus einem oder mehreren Teilen, technisch als Labels bezeichnet , die üblicherweise verkettet und durch Punkte getrennt werden, wie zum Beispiel example.com.

Die ganz rechts stehende Bezeichnung gibt die Top-Level-Domain an ; beispielsweise gehört der Domainname www.example.com zur Top-Level-Domain .com .

Die Domänenhierarchie verläuft von rechts nach links; jede Bezeichnung links spezifiziert eine Unterteilung oder Subdomäne der rechts stehenden Domäne. Beispielsweise spezifiziert die Bezeichnung „ example“ eine Subdomäne der .com- Domäne, und „www“ ist eine Subdomäne von example.com. Dieser Unterteilungsbaum kann bis zu 127 Ebenen umfassen. ^{[ 25 ]}

Ein Label kann null bis 63 Zeichen lang sein, da die Länge auf 6 Bit begrenzt ist. Das Null-Label der Länge null ist für die Root-Zone reserviert. Der vollständige Domainname darf in seiner Textdarstellung 253 Zeichen (bzw. 254 mit dem abschließenden Punkt) nicht überschreiten. ^{[ 23 ]} In der internen Binärdarstellung des DNS benötigt diese maximale Länge von 253 Zeichen 255 Oktette Speicherplatz, da zusätzlich die Länge des ersten Labels und das letzte Null-Byte gespeichert werden. ^{[ 5 ]} Die Länge von 255 Zeichen wird nur mit mindestens 6 Labels erreicht (einschließlich des letzten Null-Labels). ^{[ 5 ]}

Obwohl es keine technischen Beschränkungen gibt, die die Verwendung beliebiger, durch ein Oktett darstellbarer Zeichen in Domainnamen-Labels verhindern, verwenden Hostnamen ein bevorzugtes Format und einen bevorzugten Zeichensatz. Die in Labels zulässigen Zeichen sind eine Teilmenge des ASCII- Zeichensatzes und bestehen aus den Buchstaben a bis z , A bis Z , den Ziffern 0 bis 9 und dem Bindestrich. Diese Regel ist als LDH-Regel (Buchstaben, Ziffern, Bindestrich) bekannt. Domainnamen werden unabhängig von Groß- und Kleinschreibung interpretiert. ^{[ 26 ]} Labels dürfen nicht mit einem Bindestrich beginnen oder enden. ^{[ 27 ]} Eine weitere Regel besagt, dass Top-Level-Domainnamen nicht ausschließlich aus Ziffern bestehen dürfen. ^{[ 27 ]}

Der im DNS zulässige, begrenzte ASCII-Zeichensatz verhinderte die Darstellung von Namen und Wörtern vieler Sprachen in ihren jeweiligen Alphabeten oder Schriften. Um dies zu ermöglichen, genehmigte ICANN das System „Internationalizing Domain Names in Applications“ (IDNA). Mit diesem System wandeln Benutzeranwendungen wie Webbrowser Unicode- Zeichenketten mithilfe von Punycode in den gültigen DNS-Zeichensatz um . 2009 genehmigte ICANN die Einführung internationalisierter länderspezifischer Top-Level-Domains ( ccTLDs ) . Darüber hinaus haben viele Registrierungsstellen der bestehenden Top-Level-Domains ( TLDs ) das IDNA-System gemäß den RFCs 5890, 5891, 5892 und 5893 übernommen.

Das Domain Name System (DNS) wird von einem verteilten Datenbanksystem verwaltet , das auf dem Client-Server-Modell basiert . Die Knoten dieser Datenbank sind die Nameserver . Jede Domain verfügt über mindestens einen autoritativen DNS-Server, der Informationen über diese Domain und die Nameserver aller ihr untergeordneten Domains veröffentlicht. Die oberste Ebene der Hierarchie bilden die Root-Nameserver , die bei der Namensauflösung einer Top-Level-Domain ( TLD ) abgefragt werden .

Ein autoritativer Nameserver ist ein Nameserver, der auf DNS-Anfragen nur Antworten auf Daten liefert, die von einer ursprünglichen Quelle, beispielsweise dem Domainadministrator, oder durch dynamische DNS-Methoden konfiguriert wurden, im Gegensatz zu Antworten, die durch eine Anfrage an einen anderen Nameserver erhalten werden, der lediglich einen Datencache verwaltet.

Ein autoritativer Nameserver kann entweder ein primärer oder ein sekundärer Server sein. Historisch gesehen wurden die Begriffe Master/Slave und primär/sekundär mitunter synonym verwendet ^{[ 28 ]} , heute wird jedoch die Bezeichnung „sekundär“ bevorzugt. Ein primärer Server speichert die Originalkopien aller Zoneneinträge. Ein sekundärer Server nutzt einen speziellen automatischen Aktualisierungsmechanismus im DNS-Protokoll, um in der Kommunikation mit seinem primären Server eine identische Kopie der primären Einträge zu gewährleisten.

Jeder DNS-Zone muss ein Satz autoritativer Nameserver zugewiesen werden. Dieser Satz von Servern wird in der übergeordneten Domainzone mit Nameserver-Einträgen (NS-Einträgen) gespeichert.

Ein autoritativer Server signalisiert seinen Status als Lieferant verbindlicher und als autoritativ geltender Antworten durch Setzen eines Protokollflags, des sogenannten „ Authoritative Answer “ -Bits ( AA- Bit ) , in seinen Antworten. ^{[ 5 ]} Dieses Flag wird üblicherweise prominent in der Ausgabe von DNS-Verwaltungstools wie dig wiedergegeben , um anzuzeigen, dass der antwortende Nameserver für den betreffenden Domainnamen autoritativ ist. ^{[ 5 ]}

Wenn ein Nameserver als autoritativer Server für einen Domainnamen bestimmt wird, für den er keine autoritativen Daten besitzt, tritt ein Fehler auf, der als „lahme Delegation“ oder „lahme Antwort“ bezeichnet wird. ^{[ 29 ] [ 30 ]}

Domain Name Resolver ermitteln die für den betreffenden Domainnamen zuständigen Domain Name Server durch eine Abfolge von Abfragen, beginnend mit der Domainbezeichnung auf der obersten Ebene (Top-Level-Domain).

Für den ordnungsgemäßen Betrieb des Domain Name Resolvers wird ein Netzwerk-Host mit einem initialen Cache ( Hints ) der bekannten Adressen der Root-Nameserver konfiguriert. Die Hints werden regelmäßig von einem Administrator aktualisiert, indem ein Datensatz aus einer zuverlässigen Quelle abgerufen wird.

Sofern der Resolver keine zwischengespeicherten Datensätze zur Beschleunigung des Prozesses besitzt, beginnt die Namensauflösung mit einer Anfrage an einen der Root-Server. Im Normalbetrieb antworten die Root-Server nicht direkt, sondern verweisen auf autoritativere Server. Beispielsweise wird eine Anfrage für „www.wikipedia.org“ an die org -Server weitergeleitet. Der Resolver fragt nun die weitergeleiteten Server ab und wiederholt diesen Vorgang iterativ, bis er eine autoritative Antwort erhält. Das Diagramm veranschaulicht diesen Prozess für den Host mit dem vollqualifizierten Domainnamen „www.wikipedia.org“.

Dieser Mechanismus würde die Root-Server stark belasten, wenn jede Namensauflösung im Internet den Startpunkt auf der Root-Seite erfordern würde. In der Praxis wird in DNS-Servern Caching eingesetzt, um die Root-Server zu entlasten. Dadurch sind Root-Nameserver tatsächlich nur an einem relativ geringen Anteil aller Anfragen beteiligt.

Theoretisch reichen autoritative Nameserver für den Betrieb des Internets aus. Da jedoch nur autoritative Nameserver in Betrieb sind, muss jede DNS-Anfrage mit rekursiven Anfragen in der Root-Zone des Domain Name Systems beginnen, und jedes Benutzersystem müsste eine Resolver-Software implementieren, die rekursive Operationen unterstützt. ^{[ 31 ]}

Um die Effizienz zu steigern, den DNS-Verkehr im Internet zu reduzieren und die Leistung von Endbenutzeranwendungen zu verbessern, unterstützt das Domain Name System (DNS) DNS-Cache-Server. Diese speichern DNS-Abfrageergebnisse für einen in der Konfiguration ( TTL ) des jeweiligen Domainnamens festgelegten Zeitraum. Typischerweise implementieren solche Cache-DNS-Server auch den rekursiven Algorithmus, der zur Namensauflösung vom DNS-Root bis zu den autoritativen Nameservern der abgefragten Domain erforderlich ist. Durch die Implementierung dieser Funktion im Nameserver profitieren Benutzeranwendungen von einer effizienteren Entwicklung und einem reibungsloseren Betrieb.

Die Kombination von DNS-Caching und rekursiven Funktionen in einem Nameserver ist nicht zwingend erforderlich; die Funktionen können für spezielle Zwecke auch unabhängig voneinander auf Servern implementiert werden.

Internetdienstanbieter (ISPs) stellen ihren Kunden üblicherweise rekursive und zwischenspeichernde Nameserver zur Verfügung. Darüber hinaus nutzen viele Heimnetzwerk-Router DNS-Caches und Rekursion, um die Effizienz im lokalen Netzwerk zu verbessern.

Die Clientseite des DNS wird als DNS-Resolver bezeichnet. Ein Resolver ist für die Initiierung und Sequenzierung der Anfragen verantwortlich, die letztendlich zur vollständigen Auflösung (Übersetzung) der gesuchten Ressource führen, z. B. zur Übersetzung eines Domainnamens in eine IP-Adresse. DNS-Resolver werden anhand verschiedener Anfragemethoden klassifiziert, beispielsweise rekursiv , nicht-rekursiv und iterativ . Ein Auflösungsprozess kann eine Kombination dieser Methoden verwenden. ^{[ 23 ]}

Bei einer nicht-rekursiven Anfrage fragt ein DNS-Resolver einen DNS-Server ab, der entweder einen Eintrag liefert, für den der Server autoritativ ist, oder ein Teilergebnis ohne weitere Serverabfrage bereitstellt. Im Falle eines DNS-Resolvers mit Cache liefert die nicht-rekursive Anfrage an seinen lokalen DNS-Cache ein Ergebnis und reduziert die Last auf vorgelagerten DNS-Servern, indem DNS-Ressourceneinträge nach einer ersten Antwort von diesen Servern für eine gewisse Zeit zwischengespeichert werden.

Bei einer rekursiven Anfrage fragt ein DNS-Resolver einen einzelnen DNS-Server ab, der wiederum im Auftrag des Anfragenden weitere DNS-Server abfragen kann. Beispielsweise sendet ein einfacher Stub-Resolver auf einem Heimrouter typischerweise eine rekursive Anfrage an den DNS-Server des Internetanbieters. Bei einer rekursiven Anfrage beantwortet der DNS-Server die Anfrage vollständig, indem er bei Bedarf weitere Nameserver abfragt. Im Normalbetrieb sendet ein Client eine rekursive Anfrage an einen zwischengespeicherten rekursiven DNS-Server, der anschließend nicht-rekursive Anfragen stellt, um die Antwort zu ermitteln und diese als einzelne Antwort an den Client zurückzusenden. Der Resolver oder ein anderer DNS-Server, der rekursiv im Auftrag des Resolvers agiert, verhandelt die Nutzung des rekursiven Dienstes mithilfe von Bits in den Anfrage-Headern. DNS-Server sind nicht verpflichtet, rekursive Anfragen zu unterstützen.

Das iterative Abfrageverfahren ist ein Prozess, bei dem ein DNS-Resolver eine Kette von einem oder mehreren DNS-Servern abfragt. Jeder Server leitet den Client an den nächsten Server in der Kette weiter, bis der aktuelle Server die Anfrage vollständig auflösen kann. Beispielsweise würde die Auflösung von www.example.com zunächst einen globalen Root-Server, dann einen „com“-Server und schließlich einen „example.com“-Server abfragen.

Nameserver in Delegierungen werden anhand ihres Namens und nicht anhand ihrer IP-Adresse identifiziert. Das bedeutet, dass ein auflösender Nameserver eine weitere DNS-Anfrage stellen muss, um die IP-Adresse des Servers zu ermitteln, an den er weitergeleitet wurde. Wenn der in der Delegierung angegebene Name eine Subdomain der Domain ist, für die die Delegierung erfolgt, entsteht eine Zirkelbezüge .

In diesem Fall muss der Nameserver, der die Delegierung vornimmt, auch eine oder mehrere IP-Adressen für den in der Delegierung genannten autoritativen Nameserver bereitstellen. Diese Information wird als Glue-Record bezeichnet . Der delegierende Nameserver stellt diesen Glue-Record in Form von Einträgen im Abschnitt „Additional“ der DNS-Antwort bereit und übermittelt die Delegierung im Abschnitt „Authority“ der Antwort. Ein Glue-Record ist eine Kombination aus Nameserver und IP-Adresse.

Wenn beispielsweise der autoritative Nameserver für example.org ns1.example.org ist, versucht ein Computer, www.example.org aufzulösen, zunächst ns1.example.org aufzulösen. Da ns1 in example.org enthalten ist, muss example.org zuerst aufgelöst werden, was eine zirkuläre Abhängigkeit darstellt. Um diese Abhängigkeit aufzulösen, fügt der Nameserver der Top-Level-Domain org zusammen mit der Delegierung für example.org sogenannte Glue-Records hinzu. Diese Glue-Records sind Adressdatensätze, die IP-Adressen für ns1.example.org bereitstellen. Der Resolver verwendet eine oder mehrere dieser IP-Adressen, um einen der autoritativen Server der Domain abzufragen und so die DNS-Abfrage abzuschließen.

Ein gängiger Ansatz zur Reduzierung der DNS-Abfragelast besteht darin, die Ergebnisse der Namensauflösung lokal oder auf zwischengeschalteten Resolver-Hosts zwischenzuspeichern. Jedes DNS-Abfrageergebnis hat eine Gültigkeitsdauer (Time-to-Live, TTL), die angibt, wie lange die Informationen gültig bleiben, bevor sie verworfen oder aktualisiert werden müssen. Diese TTL wird vom Administrator des autoritativen DNS-Servers festgelegt und kann von wenigen Sekunden bis zu mehreren Tagen oder sogar Wochen reichen. ^{[ 32 ]}

Aufgrund dieser verteilten Caching-Architektur werden Änderungen an DNS-Einträgen nicht sofort im gesamten Netzwerk verbreitet, sondern erfordern, dass alle Caches nach Ablauf der TTL-Gültigkeit aktualisiert werden. RFC 1912 enthält grundlegende Regeln zur Bestimmung geeigneter TTL-Werte.

Einige Resolver können TTL-Werte überschreiben, da das Protokoll Caching für bis zu 68 Jahre oder gar kein Caching unterstützt. Negatives Caching , d. h. das Speichern der Information, dass ein Datensatz nicht existiert, wird von den für eine Zone autoritativ zuständigen Nameservern bestimmt. Diese müssen den SOA-Eintrag ( Start of Authority ) angeben, wenn sie melden, dass keine Daten des angeforderten Typs vorhanden sind. Der Wert des Minimum- Felds des SOA-Eintrags und die TTL des SOA-Eintrags selbst werden verwendet, um die TTL für die negative Antwort festzulegen.

Eine Reverse-DNS-Abfrage ist eine DNS-Abfrage nach Domainnamen, wenn die zugehörige IP-Adresse bekannt ist. Mehrere Domainnamen können einer IP-Adresse zugeordnet sein. Das DNS speichert IP-Adressen als speziell formatierte Domainnamen in Pointer-Einträgen (PTR-Einträgen) innerhalb der Infrastruktur-Top-Level-Domain arpa . Für IPv4 lautet diese Domain in-addr.arpa, für IPv6 ip6.arpa. Die IP-Adresse wird für IPv4 als Name in umgekehrter Oktett-Reihenfolge und für IPv6 als Name in umgekehrter Nibble-Reihenfolge dargestellt.

Bei einer Reverse-Lookup-Anfrage wandelt der DNS-Client die Adresse in die entsprechenden Formate um, bevor er den Namen gemäß der Delegierungskette nach einem PTR-Eintrag abfragt, wie bei jeder DNS-Anfrage. Angenommen, die IPv4-Adresse 208.80.152.2 ist Wikimedia zugewiesen, dann wird sie als DNS-Name in umgekehrter Reihenfolge dargestellt: 2.152.80.208.in-addr.arpa. Wenn der DNS-Resolver eine PTR-Anfrage erhält, fragt er zunächst die Root-Server ab, die auf die Server der American Registry for Internet Numbers (ARIN) für die Zone 208.in-addr.arpa verweisen. Die ARIN-Server delegieren 152.80.208.in-addr.arpa an Wikimedia, an das der Resolver eine weitere Anfrage für 2.152.80.208.in-addr.arpa sendet, was zu einer autoritativen Antwort führt.

Nutzer kommunizieren in der Regel nicht direkt mit einem DNS-Resolver. Die DNS-Auflösung erfolgt stattdessen transparent in Anwendungen wie Webbrowsern , E-Mail-Clients und anderen Internetanwendungen. Wenn eine Anwendung eine Anfrage stellt, die eine Namensauflösung erfordert, sendet sie eine solche Anfrage an den DNS-Resolver im lokalen Betriebssystem, der dann die notwendige Kommunikation übernimmt.

Der DNS-Resolver verfügt fast immer über einen Cache (siehe oben), der die letzten Anfragen enthält. Kann der Cache die Anfrage beantworten, gibt der Resolver den Wert aus dem Cache an das anfragende Programm zurück. Enthält der Cache die Antwort nicht, sendet der Resolver die Anfrage an einen oder mehrere festgelegte DNS-Server. Bei den meisten Heimanwendern stellt der Internetanbieter (ISP) diesen DNS-Server bereit: Der Benutzer hat die Adresse des Servers entweder manuell konfiguriert oder sie per DHCP festlegen lassen. Wenn Systemadministratoren jedoch eigene DNS-Server konfiguriert haben, verweisen ihre DNS-Resolver auf separat verwaltete Nameserver der Organisation. In jedem Fall folgt der abgefragte Nameserver dem oben beschriebenen Prozess , bis er entweder ein Ergebnis findet oder nicht. Anschließend sendet er sein Ergebnis an den DNS-Resolver zurück. Hat er ein Ergebnis gefunden, speichert der Resolver dieses für die spätere Verwendung im Cache und gibt es an die anfragende Software zurück.

Einige große Internetdienstanbieter haben ihre DNS-Server so konfiguriert, dass sie gegen Regeln verstoßen, beispielsweise durch Missachtung von TTLs oder indem sie anzeigen, dass ein Domainname nicht existiert, nur weil einer seiner Nameserver nicht antwortet. ^{[ 33 ]}

Einige Anwendungen, wie beispielsweise Webbrowser, verwenden einen internen DNS-Cache, um wiederholte Abfragen über das Netzwerk zu vermeiden. Dies kann die Fehlersuche bei DNS-Problemen erschweren, da dadurch der Verlauf dieser Daten verschleiert wird. Diese Caches verwenden typischerweise sehr kurze Speicherzeiten in der Größenordnung von einer Minute. ^{[ 34 ]}

Internet Explorer stellt eine bemerkenswerte Ausnahme dar: Versionen bis einschließlich IE 3.x speichern DNS-Einträge standardmäßig 24 Stunden lang im Cache. Internet Explorer 4.x und spätere Versionen (bis einschließlich IE 8) reduzieren den Standard-Timeout-Wert auf eine halbe Stunde; dieser Wert kann durch Ändern der Standardkonfiguration angepasst werden. ^{[ 35 ]}

Wenn Google Chrome Probleme mit dem DNS-Server erkennt, wird eine spezifische Fehlermeldung angezeigt.

Das Domain Name System umfasst noch einige weitere Funktionen und Merkmale.

Hostnamen und IP-Adressen müssen nicht zwingend in einer Eins-zu-eins-Beziehung stehen. Mehrere Hostnamen können einer einzigen IP-Adresse zugeordnet sein, was beim virtuellen Hosting nützlich ist , bei dem viele Websites von einem einzigen Host bereitgestellt werden. Alternativ kann ein einzelner Hostname auch mehreren IP-Adressen zugeordnet werden, um Fehlertoleranz und Lastverteilung auf mehrere Serverinstanzen innerhalb eines Unternehmens oder im globalen Internet zu ermöglichen.

DNS erfüllt neben der Übersetzung von Namen in IP-Adressen noch weitere Zwecke. Beispielsweise nutzen Mail Transfer Agents (MTAs ) DNS, um den optimalen Mailserver für die E-Mail- Zustellung zu finden : Ein MX-Eintrag stellt eine Zuordnung zwischen einer Domain und einem Mailserver her; dies kann eine zusätzliche Ebene der Fehlertoleranz und Lastverteilung bieten.

Das DNS dient der effizienten Speicherung und Verteilung von IP-Adressen gesperrter E-Mail-Hosts. Eine gängige Methode besteht darin, die IP-Adresse des betreffenden Hosts in die Subdomain einer übergeordneten Domain einzufügen und diese Domain in einen entsprechenden Eintrag aufzulösen, der eine positive oder negative Kennzeichnung enthält.

Zum Beispiel:

• Die Adresse 203.0.113.5 steht auf der Sperrliste. Sie verweist auf 5.113.0.203.blocklist.example , welche zu 127.0.0.1 aufgelöst wird .
• Die Adresse 203.0.113.6 ist nicht gesperrt und verweist auf 6.113.0.203.blocklist.example . Dieser Hostname ist entweder nicht konfiguriert oder wird zu 127.0.0.2 aufgelöst .

E-Mail-Server können die Datei blocklist.example abfragen, um herauszufinden, ob ein bestimmter Host, der sich mit ihnen verbindet, auf der Sperrliste steht. Viele solcher Sperrlisten, entweder kostenpflichtig oder kostenlos, stehen E-Mail-Administratoren und Anti-Spam-Software zur Verfügung.

Um Ausfallsicherheit bei Computer- oder Netzwerkausfällen zu gewährleisten, werden üblicherweise mehrere DNS-Server für jede Domain bereitgestellt. Auf der obersten Ebene des globalen DNS existieren dreizehn Gruppen von Root-Nameservern , von denen zusätzliche Kopien weltweit über Anycast- Adressierung verteilt sind.

Dynamic DNS (DDNS) aktualisiert einen DNS-Server mit der IP-Adresse eines Clients in Echtzeit, beispielsweise beim Wechsel zwischen Internetdienstanbietern oder mobilen Hotspots oder wenn sich die IP-Adresse administrativ ändert.

Das DNS-Protokoll verwendet zwei Arten von DNS-Nachrichten, Anfragen und Antworten; beide haben dasselbe Format. Jede Nachricht besteht aus einem Header und vier Abschnitten: Frage, Antwort, Autorität und einem zusätzlichen Leerzeichen. Ein Header-Feld ( Flags ) steuert den Inhalt dieser vier Abschnitte. ^{[ 23 ]}

Der Header besteht aus folgenden Feldern: Identifikation , Flags , Anzahl der Fragen , Anzahl der Antworten , Anzahl der Authority Resource Records (RRs) und Anzahl der zusätzlichen RRs . Jedes Feld ist 16 Bit lang und erscheint in der angegebenen Reihenfolge. Das Identifikationsfeld dient dem Abgleich von Antworten mit Anfragen. Nach dem Flags-Wort endet der Header mit vier 16-Bit-Ganzzahlen, die die Anzahl der Datensätze in den folgenden Abschnitten in derselben Reihenfolge enthalten.

Transaktions-ID: 16 Bit

Transaktions-ID

Flags: 16 Bit

Das Flaggenfeld besteht aus folgenden Unterfeldern:

QR: 1 Bit

Gibt an, ob es sich bei der Nachricht um eine Anfrage (0) oder eine Antwort (1) handelt.

OPCODE: 4 Bit

Der Typ kann QUERY (Standardabfrage, 0), IQUERY (inverse Abfrage, 1) oder STATUS (Serverstatusanfrage, 2) sein.

AA: 1 Bit

Eine autoritative Antwort gibt an, ob der DNS-Server für den abgefragten Hostnamen autoritativ ist.

TC: 1 Bit

TrunCation bedeutet, dass diese Nachricht aufgrund ihrer Länge gekürzt wurde.

RD: 1 Bit

Rekursion gewünscht, zeigt an, ob der Client eine rekursive Abfrage wünscht.

RA: 1 Bit

Die Meldung „Recursion Available“ in einer Antwort gibt an, ob der antwortende DNS-Server Rekursion unterstützt.

Z: 1 Bit; (Z) == 0

Null, reserviert für zukünftige Verwendung.

AD: 1 Bit

Die Angabe „Authentic Data“ in einer Antwort gibt an, ob der antwortende DNS-Server die Daten verifiziert hat.

CD: 1 Bit

Die Option „Deaktiviert“ in einer Abfrage bedeutet, dass nicht verifizierte Daten in einer Antwort akzeptabel sind.

RCODE: 4 Bit

Der Antwortcode kann NOERROR (0), FORMERR (1, Formatfehler), SERVFAIL (2), NXDOMAIN (3, Nicht existierende Domäne) usw. sein. ^{[ 36 ]}

Anzahl der Fragen: 16 Bit

Anzahl der Fragen.

Anzahl der Antworten: 16 Bit

Anzahl der Antworten.

Anzahl der Authority RRs: 16 Bit

Anzahl der Datensätze der Autoritätsressource.

Anzahl zusätzlicher RRs: 16 Bit

Anzahl zusätzlicher Ressourcendatensätze.

Der Fragenteil hat ein einfacheres Format als das Ressourcendatensatzformat, das in den anderen Abschnitten verwendet wird. Jeder Fragendatensatz (in der Regel gibt es nur einen pro Abschnitt) enthält die folgenden Felder:

Der Domänenname wird in einzelne Bezeichnungen zerlegt, die anschließend verkettet werden; jeder Bezeichnung wird die Länge dieser Bezeichnung vorangestellt. ^{[ 37 ]}

Das Domain Name System (DNS) definiert eine Datenbank mit Informationselementen für Netzwerkressourcen. Diese Informationselemente werden kategorisiert und mithilfe von DNS-Eintragstypen , den sogenannten Resource Records (RRs), organisiert. Jeder Eintrag besitzt einen Typ (Name und Nummer), eine Gültigkeitsdauer ( Time-to-Live ), eine Klasse und typspezifische Daten. Resource Records desselben Typs bilden ein Resource Record Set (RRset) ohne festgelegte Reihenfolge. DNS-Resolver liefern bei einer Anfrage das gesamte Set zurück, Server können jedoch zur Lastverteilung eine Round-Robin-Sortierung implementieren. Die Domain Name System Security Extensions (DNSSEC) hingegen verarbeiten alle Resource Records in kanonischer Reihenfolge.

Bei der Übertragung über ein Internet-Protokoll -Netzwerk verwenden alle Datensätze (Antwort, Autorität und zusätzliche Abschnitte) das in RFC 1035 spezifizierte gemeinsame Format: ^{[ 38 ] : §3}

NAME ist der vollqualifizierte Domänenname des Knotens im Baum. Bei der Übertragung kann der Name mithilfe von Labelkomprimierung verkürzt werden, indem die Enden von Domänennamen, die zuvor im Paket erwähnt wurden, durch das Ende des aktuellen Domänennamens ersetzt werden.

Der Eintragstyp (TYPE ) gibt das Datenformat an und lässt auf den Verwendungszweck schließen. Beispielsweise dient der A -Eintrag der Übersetzung eines Domainnamens in eine IPv4-Adresse , der NS -Eintrag listet die Nameserver auf, die Anfragen in einer DNS-Zone beantworten können , und der MX- Eintrag legt den Mailserver fest, der für die Zustellung von E-Mails an eine in einer E-Mail-Adresse angegebene Domain zuständig ist.

RDATA sind Daten von typspezifischer Relevanz, wie beispielsweise die IP-Adresse für Adressdatensätze oder die Priorität und der Hostname für MX-Einträge. Bekannte Datensatztypen dürfen die Labelkomprimierung im RDATA-Feld verwenden, „unbekannte“ Datensatztypen jedoch nicht (RFC 3597).

Die Klasse eines Eintrags wird für gängige DNS-Einträge mit Internet-Hostnamen, Servern oder IP-Adressen auf IN (für Internet ) gesetzt. Zusätzlich existieren die Klassen Chaos (CH) und Hesiod (HS). ^{[ 38 ] : 11} Jede Klasse stellt einen unabhängigen Namensraum mit potenziell unterschiedlichen Delegierungen von DNS-Zonen dar.

Zusätzlich zu den in einer Zonendatei definierten Ressourceneinträgen definiert das Domain Name System auch verschiedene Anfragetypen, die nur bei der Kommunikation mit anderen DNS-Knoten ( über das Netzwerk ) verwendet werden, beispielsweise bei der Durchführung von Zonentransfers (AXFR/IXFR) oder für EDNS (OPT).

Das Domain Name System (DNS) unterstützt Wildcard-DNS-Einträge , die Namen definieren, die mit einem Sternchen (*) beginnen , *z. B. „ *.exampleexample.example “. ^{[ 23 ] [ 39 ]} DNS-Einträge von Wildcard-Domainnamen legen Regeln für die Generierung von Ressourceneinträgen innerhalb einer einzelnen DNS-Zone fest, indem sie ganze Bezeichnungen durch passende Komponenten des Abfragenamens ersetzen, einschließlich aller angegebenen Nachfolger. In der folgenden Konfiguration legt die DNS-Zone „x.example“ beispielsweise fest, dass alle Subdomains von „x.example“ , einschließlich der Subdomains von Subdomains, den Mailserver (MX-Eintrag) „ axexample“ verwenden . Der AAAA-Eintrag für „axexample“ ist erforderlich, um die IP-Adresse des Mailservers anzugeben. Da dies dazu führt, dass dieser Domainname und seine Subdomains von den Wildcard-Übereinstimmungen ausgeschlossen werden, muss in der DNS-Zone ein zusätzlicher MX-Eintrag für die Subdomain „ axexample“ sowie ein Wildcard-MX-Eintrag für alle ihre Subdomains definiert werden.

x.example. MX 10 a.x.example. *.x.example. MX 10 a.x.example. axexample. MX 10 a.x.example. *.axexample. MX 10 a.x.example. axexample. AAAA 2001:db8::1

Die Rolle von Wildcard-Einträgen wurde in RFC 4592 präzisiert , da die ursprüngliche Definition in RFC 1034 unvollständig war und zu Fehlinterpretationen durch die Implementierer führte. ^{[ 39 ]}  

Das ursprüngliche DNS-Protokoll bot nur begrenzte Möglichkeiten zur Erweiterung um neue Funktionen. 1999 veröffentlichte Paul Vixie in RFC 2671 (später ersetzt durch RFC 6891) einen Erweiterungsmechanismus namens Extension Mechanisms for DNS (EDNS). Dieser führte optionale Protokollelemente ein, ohne den Overhead zu erhöhen, wenn sie nicht verwendet wurden. Dies wurde durch den OPT-Pseudo-Ressourceneintrag erreicht, der nur bei drahtgebundenen Übertragungen des Protokolls, nicht aber in Zonendateien existiert. Es wurden auch erste Erweiterungen vorgeschlagen (EDNS0), wie beispielsweise die Erhöhung der DNS-Nachrichtengröße in UDP-Datagrammen.

Dynamische DNS-Aktualisierungen nutzen den DNS-Opcode UPDATE, um Ressourceneinträge dynamisch zu einer Zonendatenbank hinzuzufügen oder zu entfernen, die auf einem autoritativen DNS-Server verwaltet wird. ^{[ 40 ]} Diese Funktion ist nützlich, um Netzwerkclients beim Systemstart oder sobald sie anderweitig im Netzwerk verfügbar sind, im DNS zu registrieren. Da einem Client beim Systemstart jedes Mal eine andere IP-Adresse von einem DHCP -Server zugewiesen werden kann, ist es nicht möglich, statische DNS-Zuweisungen für solche Clients bereitzustellen.

Seit seiner Entstehung im Jahr 1983 nutzt das DNS das User Datagram Protocol (UDP) für den Transport über IP. Dessen Einschränkungen haben in den folgenden Jahrzehnten zahlreiche Protokollentwicklungen im Hinblick auf Zuverlässigkeit, Sicherheit, Datenschutz und andere Kriterien angestoßen.

UDP reserviert Port 53 für Server, die Anfragen entgegennehmen. ^{[ 5 ]} Eine solche Anfrage besteht aus einer Klartextanfrage, die vom Client in einem einzelnen UDP-Paket gesendet und vom Server mit einer Klartextantwort in einem einzelnen UDP-Paket beantwortet wird. Wenn die Antwortlänge 512 Byte überschreitet und sowohl Client als auch Server EDNS ( Extension Mechanisms for DNS ) unterstützen, können größere UDP-Pakete verwendet werden. ^{[ 41 ]} Die Nutzung von DNS über UDP ist unter anderem durch die fehlende Transportverschlüsselung, Authentifizierung, zuverlässige Zustellung und die begrenzte Nachrichtenlänge eingeschränkt. 1989 spezifizierte RFC 1123 das optionale Transmission Control Protocol (TCP) für DNS-Anfragen, -Antworten und insbesondere Zonentransfers . Durch die Fragmentierung langer Antworten ermöglicht TCP längere Antworten, zuverlässige Zustellung und die Wiederverwendung langlebiger Verbindungen zwischen Clients und Servern. Bei größeren Antworten verweist der Server den Client auf den TCP-Transport.

DNS over TLS (DoT) etablierte sich 2016 als IETF-Standard für verschlüsseltes DNS. Dabei wird Transport Layer Security (TLS) verwendet, um die gesamte Verbindung und nicht nur die DNS-Nutzdaten zu schützen. DoT-Server lauschen auf TCP-Port 853. RFC 7858 spezifiziert, dass opportunistische und authentifizierte Verschlüsselung unterstützt werden können, schreibt aber weder eine Server- noch eine Client-Authentifizierung vor.  

DNS over HTTPS wurde 2018 als konkurrierender Standard für den DNS-Abfragetransport entwickelt. Dabei werden DNS-Abfragedaten über HTTPS getunnelt, welches HTTP über TLS transportiert. DoH wurde als webfreundlichere Alternative zu DNS beworben, da es wie DNSCrypt den TCP-Port 443 verwendet und somit dem Webverkehr ähnelt, obwohl beide in der Praxis ohne entsprechendes Padding leicht zu unterscheiden sind. ^{[ 42 ]}

RFC 9250, veröffentlicht 2022 von der Internet Engineering Task Force , beschreibt DNS over QUIC . Es weist „ähnliche Datenschutzeigenschaften wie DNS over TLS (DoT) […] und ähnliche Latenzeigenschaften wie klassisches DNS over UDP“ auf. Diese Methode ist nicht mit DNS over HTTP/3 identisch . ^{[ 43 ]}

RFC 9953, veröffentlicht 2026 von der Internet Engineering Task Force , beschreibt DNS over CoAP . Der Anwendungsfall von DoC ist von DNS over HTTPS (DoH) (RFC 8484) inspiriert. DoC zielt jedoch auf den Einsatz im ressourcenbeschränkten Internet der Dinge (IoT) ab, was üblicherweise mit den Anforderungen von HTTPS kollidiert. ^{[ 44 ]} In ressourcenbeschränkten Szenarien ist DoC anderen DNS-Auflösungsmechanismen überlegen. ^{[ 45 ]}

Oblivious DNS (ODNS) wurde von Forschern der Princeton University und der University of Chicago als Erweiterung des unverschlüsselten DNS entwickelt und implementiert ^{[ 46 ]} , bevor DoH standardisiert und weit verbreitet wurde. Apple und Cloudflare setzten die Technologie später im Kontext von DoH als Oblivious DoH (ODoH) ein ^{[ 47 ]} . ODoH kombiniert die in ODNS eingeführte Trennung von eingehendem und ausgehendem Datenverkehr mit dem HTTPS-Tunneling und der TLS-Transportverschlüsselung von DoH in einem einzigen Protokoll ^{[ 48 ] .}

DNS kann über virtuelle private Netzwerke (VPNs) und Tunnelprotokolle betrieben werden . Die Datenschutzvorteile von Oblivious DNS lassen sich durch die Nutzung des bereits bestehenden Tor- Netzwerks von Eingangs- und Ausgangsknoten in Verbindung mit der durch TLS bereitgestellten Transportverschlüsselung erzielen. ^{[ 49 ]}

Das 2011 außerhalb des IETF -Standardisierungsrahmens entwickelte DNSCrypt- Protokoll führte die DNS-Verschlüsselung auf der Downstream-Seite rekursiver Resolver ein. Dabei verschlüsseln Clients die Nutzdaten ihrer Anfragen mithilfe der öffentlichen Schlüssel der Server, die im DNS veröffentlicht sind (anstatt sich auf Zertifizierungsstellen von Drittanbietern zu verlassen) und ihrerseits durch DNSSEC- Signaturen geschützt werden können. ^{[ 50 ]} DNSCrypt verwendet entweder TCP-Port 443, denselben Port wie der verschlüsselte HTTPS- Webverkehr, oder UDP-Port 443. Dies ermöglichte nicht nur die Vertraulichkeit des Anfrageinhalts, sondern auch eine deutlich verbesserte Firewall-Traversal-Fähigkeit. 2019 wurde DNSCrypt um einen „anonymisierten“ Modus erweitert, ähnlich dem vorgeschlagenen „Oblivious DNS“. In diesem Modus empfängt ein Eingangsknoten eine mit dem öffentlichen Schlüssel eines anderen Servers verschlüsselte Anfrage und leitet sie an diesen Server weiter, der als Ausgangsknoten die rekursive Auflösung durchführt. ^{[ 51 ]} Die Vertraulichkeit von Benutzer-/Anfragepaaren wird gewährleistet, da der Eingangsknoten den Inhalt der Anfrage nicht kennt und der Ausgangsknoten die Identität des Clients nicht kennt. DNSCrypt wurde erstmals im Dezember 2011 von OpenDNS produktiv eingesetzt . Es existieren mehrere freie und quelloffene Softwareimplementierungen, die ODoH zusätzlich integrieren. ^{[ 52 ]} Es ist für eine Vielzahl von Betriebssystemen verfügbar, darunter Unix, Apple iOS, Linux, Android und Windows.

Ursprünglich spielten Sicherheitsbedenken bei der Entwicklung von DNS-Software oder anderer Software für das frühe Internet keine große Rolle, da das Netzwerk nicht öffentlich zugänglich war. Die Ausweitung des Internets auf den kommerziellen Sektor in den 1990er-Jahren veränderte jedoch die Anforderungen an Sicherheitsmaßnahmen zum Schutz der Datenintegrität und der Benutzerauthentifizierung .

Mehrere Sicherheitslücken wurden entdeckt und von Angreifern ausgenutzt. Eine dieser Schwachstellen ist das DNS-Cache-Poisoning , bei dem Daten unter dem Vorwand, ein autoritativer Ursprungsserver zu sein, an Cache-Resolver verteilt werden. Dadurch wird der Datenspeicher mit potenziell falschen Informationen und langen Gültigkeitsdauern (Time-to-Live) verunreinigt. In der Folge können legitime Anwendungsanfragen an Netzwerk-Hosts umgeleitet werden, die mit böswilliger Absicht betrieben werden.

DNS-Antworten verfügen traditionell über keine kryptografische Signatur , was zahlreiche Angriffsmöglichkeiten eröffnet. Die Domain Name System Security Extensions (DNSSEC) erweitern DNS um die Unterstützung kryptografisch signierter Antworten. ^{[ 53 ]} DNSCurve wurde als Alternative zu DNSSEC vorgeschlagen. Weitere Erweiterungen, wie beispielsweise TSIG , ermöglichen die kryptografische Authentifizierung zwischen vertrauenswürdigen Peers und werden häufig zur Autorisierung von Zonentransfers oder dynamischen Aktualisierungen eingesetzt.

Techniken wie Forward-Confirmed Reverse DNS können ebenfalls zur Validierung von DNS-Ergebnissen eingesetzt werden.

DNS kann auch aus ansonsten sicheren oder privaten Verbindungen "durchsickern", wenn auf deren Konfiguration nicht geachtet wird. Da DNS oft als harmlos angesehen wird, wurde es mitunter von böswilligen Personen genutzt, um Firewalls zu umgehen und Daten zu exfiltrieren .

Manche Domainnamen können für Spoofing-Zwecke missbraucht werden. Beispielsweise sind paypal.com und paypa1.com unterschiedliche Namen, die jedoch je nach gewählter Schriftart in einer grafischen Benutzeroberfläche nicht unterschieden werden können . In vielen Schriftarten sehen der Buchstabe „l“ und die Ziffer „ 1“ sehr ähnlich oder sogar identisch aus. Dieses Problem, bekannt als IDN-Homograph-Angriff , tritt besonders häufig in Systemen auf, die internationalisierte Domainnamen unterstützen , da viele Zeichencodes in ISO 10646 auf typischen Computerbildschirmen identisch erscheinen können. Diese Schwachstelle wird gelegentlich für Phishing-Angriffe ausgenutzt . ^{[ 54 ]}

DNSMessenger ^{[ 55 ] [ 56 ] [ 57 ] [ 58 ]} ist eine Cyberangriffstechnik, die das DNS nutzt, um Malware fernzusteuern und mit ihr zu kommunizieren, ohne dabei auf herkömmliche Protokolle zurückzugreifen, die Verdacht erregen könnten. Der DNSMessenger-Angriff ist verdeckt, da DNS primär für die Namensauflösung von Domains verwendet wird und von Netzwerksicherheitstools oft nicht ausreichend überwacht wird. Dadurch bietet es Angreifern einen effektiven Angriffskanal.

Diese Technik nutzt DNS-TXT-Einträge, um Befehle an infizierte Systeme zu senden. Sobald Schadsoftware unbemerkt auf dem Rechner eines Opfers installiert wurde, kontaktiert sie eine kontrollierte Domain, um in DNS-Texteinträgen kodierte Befehle abzurufen. Diese Form der Schadsoftware-Kommunikation ist schwer zu erkennen, da DNS-Anfragen in der Regel von Firewalls zugelassen werden und der DNS-Verkehr oft als harmlos eingestuft wird. Dadurch können viele Netzwerksicherheitsvorkehrungen umgangen werden.

DNSMessenger-Angriffe ermöglichen eine Vielzahl schädlicher Aktivitäten, von der Datenexfiltration bis hin zur Einschleusung zusätzlicher Schadsoftware, und bleiben dabei von herkömmlichen Netzwerksicherheitsmaßnahmen unentdeckt. Das Verständnis und die Abwehr solcher Methoden sind entscheidend für eine robuste Cybersicherheit.

Ursprünglich als öffentliche, hierarchische, verteilte und stark zwischengespeicherte Datenbank konzipiert, verfügt das DNS-Protokoll über keine Vertraulichkeitskontrollen. Benutzeranfragen und Nameserver-Antworten werden unverschlüsselt übertragen, was Netzwerkpaket-Sniffing , DNS-Hijacking , DNS-Cache-Poisoning und Man-in-the-Middle-Angriffe ermöglicht . Diese Schwachstelle wird häufig von Cyberkriminellen und Netzwerkbetreibern für Marketingzwecke, Benutzerauthentifizierung auf Captive Portals und Zensur ausgenutzt . ^{[ 59 ]}

Die Privatsphäre der Nutzer wird zusätzlich durch Vorschläge zur Erhöhung des Umfangs der Client-IP-Informationen in DNS-Abfragen (RFC 7871) zum Vorteil von Content Delivery Networks gefährdet .

Zu den wichtigsten Ansätzen, die zur Bekämpfung von Datenschutzproblemen im Zusammenhang mit DNS eingesetzt werden, gehören:

• VPNs verlagern die DNS-Auflösung zum VPN-Betreiber und verbergen den Benutzerdatenverkehr vor dem lokalen Internetanbieter.
• Tor ersetzt die herkömmliche DNS-Auflösung durch anonyme .onion -Domains und verbirgt so sowohl die Namensauflösung als auch den Benutzerverkehr hinter der Gegenüberwachung durch Onion-Routing .
• Proxys und öffentliche DNS-Server, die die eigentliche DNS-Auflösung an einen vertrauenswürdigen Drittanbieter auslagern.
  • Manche öffentliche DNS-Server unterstützen Sicherheitserweiterungen wie DNS over HTTPS , DNS over TLS und DNSCrypt .

Lösungen, die die DNS-Prüfung durch den lokalen Netzwerkbetreiber verhindern, wurden kritisiert, da sie die Sicherheitsrichtlinien von Unternehmensnetzwerken und die Internetzensur untergraben. Öffentliche DNS-Server werden ebenfalls kritisiert, weil sie zur Zentralisierung des Internets beitragen, indem sie die Kontrolle über die DNS-Auflösung in die Hände weniger großer Unternehmen legen, die es sich leisten können, öffentliche Resolver zu betreiben. ^{[ 59 ]}

Google ist der dominierende Anbieter der Plattform in Android , des Browsers in Chrome und des DNS-Resolvers im 8.8.8.8-Dienst. Würde dieses Szenario bedeuten, dass ein einzelnes Unternehmen die Kontrolle über den gesamten Namensraum des Internets erlangt? Netflix nutzte bereits eine App mit einem eigenen DNS-Auflösungsmechanismus, unabhängig von der Plattform, auf der die App lief. Was wäre, wenn die Facebook- App DoH ( Device of Home) integrieren würde? Was, wenn Apples iOS einen DoH-Auflösungsmechanismus verwenden würde, um die lokale DNS-Auflösung zu umgehen und alle DNS-Anfragen von Apples Plattformen an Apple-eigene Namensresolver weiterzuleiten?

Das Recht zur Nutzung eines Domainnamens wird von Domainnamen-Registraren vergeben , die von der Internet Corporation for Assigned Names and Numbers (ICANN) oder anderen Organisationen wie OpenNIC akkreditiert sind . Diese Organisationen sind für die Überwachung der Namens- und Nummernsysteme des Internets zuständig. Zusätzlich zur ICANN wird jede Top-Level-Domain (TLD) technisch von einer Verwaltungsorganisation, einer sogenannten Registry, betreut und gewartet. Eine Registry ist für den Betrieb der Namensdatenbank ihrer autoritativen Zone verantwortlich, wobei der Begriff meist für TLDs verwendet wird. Ein Registrant ist eine Person oder Organisation, die die Registrierung einer Domain beantragt hat. ^{[ 24 ]} Die Registry erhält Registrierungsinformationen von jedem Domainnamen -Registrar , der zur Vergabe von Namen in der entsprechenden Zone berechtigt ist, und veröffentlicht diese Informationen über das WHOIS -Protokoll. Seit 2015 wird die Verwendung von RDAP erwogen. ^{[ 60 ]}

ICANN veröffentlicht die vollständige Liste der Top-Level-Domains (TLDs), TLD-Registrierungsstellen und Domain-Registrare. Die mit Domainnamen verknüpften Registranteninformationen werden in einer Online-Datenbank verwaltet, die über den WHOIS-Dienst zugänglich ist. Für die meisten der über 290 länderspezifischen Top-Level-Domains (ccTLDs) verwalten die Domain-Registrierungsstellen die WHOIS-Informationen (Registrant, Nameserver, Ablaufdatum usw.). Beispielsweise verwaltet DENIC (Germany National Identifier Center) die Daten der DE-Domain. Seit etwa 2001 haben die meisten Registrierungsstellen für generische Top-Level-Domains (gTLDs) diesen sogenannten Thick -Registry-Ansatz eingeführt, d. h. sie speichern die WHOIS-Daten in zentralen Registrierungsstellen anstatt in den Datenbanken der Registrare.

Für Top-Level-Domains auf COM und NET wird ein schlankes Registry-Modell verwendet. Die Domain-Registry ( GoDaddy , BigRock, PDR , VeriSign usw.) speichert die grundlegenden WHOIS-Daten (z. B. Registrar und Nameserver). Organisationen, d. h. Registranten mit der Kennung ORG, sind hingegen ausschließlich in der Public Interest Registry registriert .

Manche Domainnamen-Registrierungsstellen, oft auch Netzwerkinformationszentren (NICs) genannt, fungieren neben dem Zugriff auf die WHOIS-Datensätze auch als Registrare für Endnutzer. Die Top-Level-Domain-Registrierungsstellen, beispielsweise für die Domains COM, NET und ORG, nutzen ein Registry-Registrar-Modell mit vielen Domainnamen-Registraren. ^{[ 61 ]} Bei dieser Verwaltungsmethode verwaltet die Registry lediglich die Domainnamen-Datenbank und die Beziehungen zu den Registraren. Die Registranten (Nutzer eines Domainnamens) sind Kunden des Registrars, in manchen Fällen über zusätzliche Subunternehmer wie Reseller.

• Evans, Claire L. (2018). Broad Band: Die unerzählte Geschichte der Frauen, die das Internet schufen . New York: Portfolio/Penguin. ISBN 9780735211759Die

• RFC  1034 – " DOMAINNAMEN - KONZEPTE UND EINRICHTUNGEN, " Internetstandard 13.
• RFC  1035 – " DOMAINNAMEN - IMPLEMENTIERUNG UND SPEZIFIKATION, " Internetstandard 13.
• RFC  1123 – " Anforderungen an Internet-Hosts -- Anwendung und Unterstützung " , Internetstandard 3.
• RFC  1995 – " Inkrementeller Zonentransfer im DNS " , vorgeschlagener Standard.
• RFC  1996 – " Ein Mechanismus zur schnellen Benachrichtigung über Zonenänderungen (DNS NOTIFY), " Vorgeschlagener Standard.
• RFC  2136 – " Dynamische Aktualisierungen im Domain Name System (DNS UPDATE), " Vorgeschlagener Standard.
• RFC  2181 – „ Klarstellungen zur DNS-Spezifikation “ , vorgeschlagener Standard.
• RFC  2308 – " Negative Caching of DNS Queries (DNS NCACHE), " Proposed Standard.
• RFC  3225 – " Anzeige der Resolver-Unterstützung von DNSSEC " , vorgeschlagener Standard.
• RFC  3226 – " DNSSEC und IPv6 A6-fähige Server-/Resolver-Nachrichtengrößenanforderungen, " Vorgeschlagener Standard.
• RFC  3596 – " DNS-Erweiterungen zur Unterstützung von IP Version 6, " Internet Standard 88.
• RFC  3597 – „ Behandlung unbekannter DNS Resource Record (RR)-Typen “ , vorgeschlagener Standard.
• RFC  4343 – „ Klarstellung zur Groß-/Kleinschreibung im Domain Name System (DNS) “ , vorgeschlagener Standard.
• RFC  4592 – „ Die Rolle von Wildcards im Domain Name System “ , vorgeschlagener Standard.
• RFC  5001 – " DNS Name Server Identifier (NSID) Option, " Vorgeschlagener Standard.
• RFC  5011 – " Automatisierte Aktualisierungen von DNS-Sicherheitsankern (DNSSEC), " Internetstandard 74.
• RFC  5452 – „ Maßnahmen zur Erhöhung der Widerstandsfähigkeit von DNS gegenüber gefälschten Antworten “ , vorgeschlagener Standard.
• RFC  5890 – " Internationalisierte Domänennamen für Anwendungen (IDNA): Definitionen und Dokumentenrahmen " , vorgeschlagener Standard.
• RFC  5891 – " Internationalized Domain Names in Applications (IDNA): Protocol, " Proposed Standard.
• RFC  5892 – " Die Unicode-Codepunkte und internationalisierten Domänennamen für Anwendungen (IDNA), " Vorgeschlagener Standard.
• RFC  5893 – " Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA), " Proposed Standard.
• RFC  6672 – " DNAME-Umleitung im DNS, " Vorgeschlagener Standard.
• RFC  6891 – " Erweiterungsmechanismen für DNS (EDNS(0)), " Internetstandard 75.
• RFC  7766 – " DNS-Transport über TCP - Implementierungsanforderungen " , vorgeschlagener Standard.
• RFC  8490 – " DNS Stateful Operations, " Proposed Standard.
• RFC  8945 – " Secret Key Transaction Authentication for DNS (TSIG), " Internet Standard 93.
• RFC  9103 – " DNS Zone Transfer over TLS, " Proposed Standard.
• RFC  9156 – „ DNS Query Name Minimisation to Improve Privacy “ , vorgeschlagener Standard.

• RFC  4033 – „ Einführung und Anforderungen an die DNS-Sicherheit “ , vorgeschlagener Standard.
• RFC  4034 – " Resource Records for the DNS Security Extensions, " Proposed Standard.
• RFC  4035 – " Protokollmodifikationen für die DNS-Sicherheitserweiterungen " , vorgeschlagener Standard.
• RFC  4470 – " Minimale Abdeckung von NSEC-Einträgen und DNSSEC-Online-Signierung " , vorgeschlagener Standard.
• RFC  4509 – " Verwendung von SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs), " Vorgeschlagener Standard.
• RFC  5155 – " DNS Security (DNSSEC) Hashed Authenticated Denial of Existence, " Proposed Standard.
• RFC  5702 – " Verwendung von SHA-2-Algorithmen mit RSA in DNSKEY- und RRSIG-Ressourceneinträgen für DNSSEC " , vorgeschlagener Standard.
• RFC  5910 – " Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP), " Proposed Standard.
• RFC  5933 – „ Verwendung von GOST-Signaturalgorithmen in DNSKEY- und RRSIG-Ressourceneinträgen für DNSSEC “ , historisch. Statusänderung auf historisch im Jahr 2024 durch RFC  9558. Aktualisiert durch RFC  6944. (Siehe unter „Informationelle RFCs“)
• RFC  7830 – " Die EDNS(0) Padding Option, " Vorgeschlagener Standard.
• RFC  7858 – " Spezifikation für DNS über Transport Layer Security (TLS), " Vorgeschlagener Standard.
• RFC  8310 – " Nutzungsprofile für DNS über TLS und DNS über DTLS " , vorgeschlagener Standard.
• RFC  8484 – " DNS-Abfragen über HTTPS (DoH), " Vorgeschlagener Standard.

• RFC  1183 – " Neue DNS RR Definitionen, " Experimentell.

• RFC  2182 – " Auswahl und Betrieb sekundärer DNS-Server, " Best Current Practice 16.
• RFC  2317 – " Classless IN-ADDR.ARPA delegate, " Best Current Practice 20.
• RFC  5625 – " DNS Proxy Implementation Guidelines, " Best Current Practice 152.
• RFC  6895 – " Domain Name System (DNS) IANA Considerations, " Best Current Practice 42.
• RFC  7720 – " DNS Root Name Service Protocol and Deployment Requirements, " Best Current Practice 40.
• RFC  9499 – " DNS-Terminologie, " Best Current Practice 219.

Diese RFCs haben beratenden Charakter, können aber nützliche Informationen liefern, obwohl sie weder einen Standard noch einen BCP definieren. ^{[ 1 ]}

• RFC  1178 – " Wahl eines Namens für Ihren Computer " , Information, Zu Ihrer Information 5.
• RFC  1591 – " Domain Name System Structure and Delegation, " Informational.
• RFC  1912 – " Häufige DNS-Betriebs- und Konfigurationsfehler " , Information.
• RFC  2100 – " Die Benennung von Hosts " , Informationell.
• RFC  3696 – " Anwendungstechniken zur Überprüfung und Transformation von Namen " , Informational.
• RFC  3833 – " Bedrohungsanalyse des Domain Name Systems (DNS), " Informational.
• RFC  4892 – " RIPv2 Kryptografische Authentifizierung, " Informationell.
• RFC  5894 – " Internationalisierte Domainnamen für Anwendungen (IDNA): Hintergrund, Erklärung und Begründung " , Information.
• RFC  5895 – " Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008, " Informational.
• RFC  8806 – " Ausführen eines Root-Servers lokal zu einem Resolver " , Informationell.
• RFC  9076 – " DNS Privacy Considerations, " Informational.
• RFC  9558 – " Verwendung von GOST 2012 Signaturalgorithmen in DNSKEY- und RRSIG-Ressourceneinträgen für DNSSEC " , Informational.

Diese RFCs haben einen offiziellen Status von „Unbekannt“ , sind aber aufgrund ihres Alters nicht eindeutig als solche gekennzeichnet.

• RFC  920 – „ Domainanforderungen “ , Status unbekannt. – Ursprüngliche Top-Level-Domains angegeben.
• RFC  1032 – " DOMAIN ADMINISTRATORS GUIDE, " Status unbekannt.
• RFC  1033 – " DOMAIN ADMINISTRATORS OPERATIONS GUIDE, " Status Unbekannt.
• RFC  1101 – " DNS-Kodierung von Netzwerknamen und anderen Typen, " Status unbekannt.

• Vixie, Paul (4. Mai 2007). „DNS-Komplexität“ . ACM Queue . Archiviert vom Original am 29. März 2023.
• Ball, James (28. Februar 2014). „Lernen Sie die sieben Personen kennen, die die Schlüssel zur weltweiten Internetsicherheit in Händen halten“ . The Guardian . Guardian News & Media Limited . Abgerufen am 28. Februar 2014 .
• Kruger, Lennard G. (18. November 2016). „Internet Governance and the Domain Name System: Issues for Congress“ (PDF) . Congressional Research Service . Abgerufen am 27. Juli 2024 .
• Zytrax.com , Open Source Guide – DNS für Raketenwissenschaftler.
• Mit DNS experimentieren – eine Website, auf der Sie mit DNS experimentieren können.