Domain Name System (DNS) Familie: Internetprotokollfamilie Einsatzgebiet: Namensauflösung Ports: 53/UDP 53/TCP 853/TCP (nur mit TLS, RFC 7858) 853/UDP (nur mit DTLS, RFC 8094) Standards:RFC 1034 (1987) RFC 1035 (1987)
Das Domain Name System, deutsch Domain-Namen-System,Artikel 4 Nr. 14 der (DNS) ist ein hierarchisch unterteiltes Bezeichnungssystem in einem meist IP-basierten Netz zur Beantwortung von Anfragen zu Domain-Namen (Namensauflösung).
Das DNS funktioniert ähnlich wie eine Telefonvermittlung: Der Benutzer kennt die Domain (den für 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 zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) umgewandelt – zum Beispiel eine IPv4-Adresse der Form 192.0.2.42 und/oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347 – und führt so zum richtigen Rechner.
Überblick 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, für die jeweils unabhängige Administratoren zuständig sind. Für lokale Anforderungen – etwa innerhalb eines Firmennetzes – ist es auch möglich, ein vom Internet unabhängiges DNS zu betreiben.
Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen () benutzt. Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst. Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenketten. So kann man sich einen Domainnamen wie example.org in der Regel leichter merken als die dazugehörende IP-Adresse 192.0.32.10. Dieser Punkt gewinnt im Zuge der Einführung von IPv6 noch mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet. So löst 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 geändert werden können. Da Internetteilnehmer nur den (unveränderten) DNS-Namen ansprechen, bleiben ihnen Änderungen der untergeordneten IP-Ebene weitestgehend verborgen. Da einem Namen auch mehrere IP-Adressen zugeordnet werden können, kann sogar eine einfache Lastverteilung per DNS () realisiert werden.
Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen () möglich. In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen Inverssuche bekannt ist.
Das DNS wurde 1983 von Paul Mockapetris entworfen und in RFC 882 und RFC 883 beschrieben. Beide wurden inzwischen von RFC 1034 und RFC 1035 abgelöst und durch zahlreiche weitere Standards ergänzt. Ursprüngliche Aufgabe war es, die lokalen hosts-Dateien abzulösen, die bis dahin für die Namensauflösung zuständig waren und der enorm zunehmenden Zahl von Neueinträgen nicht mehr gewachsen waren. Aufgrund der erwiesenermaßen hohen Zuverlässigkeit und Flexibilität wurden nach und nach weitere Datenbestände in das DNS integriert und so den Internetnutzern zur Verfügung gestellt (siehe unten: Erweiterung des DNS).
DNS zeichnet sich aus durch: dezentrale Verwaltung, hierarchische Strukturierung des Namensraums in Baumform, Eindeutigkeit der Namen, Erweiterbarkeit.
Domain-Namensraum mini|Schematische Darstellung der DNS-Hierarchie
Der Domain-Namensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels ( für 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. Einzelne Labels werden durch Punkte voneinander getrennt. Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird meist weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu). Somit lautet ein korrekter, vollständiger Domainname (auch 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 aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum. Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (englisch ). Die erste Ebene (beispielsweise com.) wird als Top-Level-Domain (TLD) bezeichnet, die zweite (beispielsweise example.com.) als Second-Level-Domains usw.
Zone
Die Daten des Domain Name Systems sind über eine Vielzahl von Nameservern weltweit verteilt, die durch Verweise untereinander lose gekoppelt sind. Die Verweise werden Delegierungen () genannt und folgen der hierarchischen Struktur des Domain-Baums. Durch die Delegierungen wird der Domain-Namensraum in überschneidungsfreie Bereiche unterteilt, die Zonen genannt werden. Ein oder mehrere autoritative Nameserver sind für die Auslieferung der Daten einer Zone zuständig. So sind beispielsweise die Root-Nameserver für die Beantwortung von Anfragen an die Wurzel-Zone zuständig und die Nameserver von Verisign für 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.
Resource Record
Ein Resource Record ist ein Datensatz im Domain Name System. Er besteht aus fünf 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, für die dieser Record in einem DNS-Cache zwischengespeichert werden kann (beispielsweise 86400 Sekunden = 1 Tag). Klasse Fast ausschließlich „IN“ für 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 ausschließlich „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.iana.org Im Laufe der Zeit wurden neue Typen definiert, mit denen Erweiterungen des DNS realisiert wurden. Zu den am häufigsten verwendeten gehören die folgenden Record-Typen:
+ Ausgewählte Resource-Record-Typen Typ Zweck/Beschreibung Typische Verwendung / Beispiel SOA Enthält grundlegende Zonenparameter (Primary-Nameserver, verantwortliche Person, Seriennummer, Refresh-/Retry-/Expire-Werte, Minimum-TTL). Beginn einer Zonendatei, z. B. für example.com. NS Gibt an, welche Nameserver für eine Zone zuständig 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 für den E-Mail-Empfang zuständigen Mailserver einer Domain an (mit Priorität). example.com → 10 mail.example.com SRV Beschreibt den Standort (Host, Port, Priorität, 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. für Policies, Metadaten und Schlüsselmaterial verwendet. SPF-Informationen, DKIM-Schlüssel oder DMARC-Policy für example.com SPF Historischer RR-Typ für SPF-Informationen (E-Mail-Sender-Policy); in aktuellen Implementierungen wird SPF üblicherweise ausschließlich über TXT-Records veröffentlicht. Vorhandene SPF-Records werden von vielen Systemen ignoriert, stattdessen wird der TXT-Record ausgewertet. CAA Legt fest, welche Zertifizierungsstellen (CAs) für eine Domain Zertifikate ausstellen dürfen. example.com erlaubt nur Zertifikate von letsencrypt.org DS Delegation Signer: stellt in der Elternzone einen kryptographischen Verweis auf den öffentlichen Schlüssel der Kindzone bereit (DNSSEC-Chain-of-Trust). DS-Record für example.com in der Zone .com DNSKEY Enthält die öffentlichen Schlüssel einer Zone für DNSSEC-Signaturen. Validierung signierter Antworten für example.com NSEC / NSEC3 Ermöglichen kryptographisch gesicherte negative Antworten (»Name/Typ existiert nicht«), indem sie zusammenhängende Bereiche vorhandener Namen und Typen angeben. Signierte NXDOMAIN- und »no data«-Antworten für example.com TLSA Hinterlegt Zertifikatsinformationen für DANE (z. B. zur Absicherung von TLS-Verbindungen zusätzlich oder alternativ zu klassischen CAs). _25._tcp.mail.example.com: DANE-Eintrag für SMTP mit TLS SVCB Allgemeiner Service-Beschreibungsrecord, mit dem flexible Angaben zu Diensten und Endpunkten gemacht werden können (z. B. alternative Ziele, Protokollparameter). Angabe mehrerer Ziele/Endpunkte für einen Dienst unter example.com HTTPS Spezialisierter SVCB-Typ für HTTPS-Dienste; ermöglicht z. B. die Beschreibung von HTTPS-Endpunkten, Protokollparametern und Alternativzielen. https://example.com mit Angabe eines bevorzugten Endpunkts und ALPN-Parametern
Komponenten Nameserver Ein Nameserver ist ein Server, der Namensauflösung anbietet. Namensauflösung ist das Verfahren, das es ermöglicht, Namen von Rechnern bzw. Diensten in eine vom Computer bearbeitbare Adresse aufzulösen (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 für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als Server-Cluster realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen. Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per Zonentransfer.
Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als nicht gesichert angesehen. Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen RAM ab, damit diese bei einer erneuten Anfrage schneller vorliegen. Diese Technik wird als Caching bezeichnet. Jeder dieser Einträge besitzt ein eigenes Verfallsdatum (TTL time to live), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird. Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL). Das kann unter Umständen bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, wenn sich die Daten zwischenzeitlich geändert haben.