--- id: "dns" kind: "glossary-term" title: "DNS" language: "de" category: "DNS und technische Grundlagen" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/de/glossar/dns/" translations: en: "https://tldlog.com/glossary/dns/" es: "https://tldlog.com/es/glosario/dns/" fr: "https://tldlog.com/fr/glossaire/dns/" it: "https://tldlog.com/it/glossario/dns/" pt-BR: "https://tldlog.com/pt/glossario/dns/" ru: "https://tldlog.com/ru/glossariy/dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns/" --- # DNS Domain Name System Das weltweite Verzeichnis, das für Menschen lesbare Namen wie example.com in die numerischen Adressen übersetzt, die Computer verwenden. Es ist wie ein Baum aufgebaut. Ganz oben steht die Root-Zone, darunter die Top-Level-Domains und darunter die Namen unter ihnen. Ohne das DNS würden Domainnamen nicht funktionieren. Das DNS (Domain Name System) ist das Verzeichnis des Internets. Geräte werden über numerische IP-Adressen (IPv4 oder IPv6) erreicht, die getrennt von Domainnamen vergeben werden, doch Menschen verwenden Namen wie example.com. Das DNS verknüpft beides, damit ein im Browser eingegebener oder in einer E-Mail-Adresse verwendeter Name den richtigen Computer erreicht. Keine einzelne Organisation hält das ganze Verzeichnis: Es ist auf viele Server vieler Betreiber verteilt, die Antworten eine Zeit lang lokal aufbewahren, um schneller zu sein. ## Was das DNS ist und warum das Internet es braucht Das DNS ist wie ein Baum aufgebaut. An der Spitze steht die Root-Zone. Darunter liegen die Top-Level-Domains (TLDs) wie .com oder .es, und darunter die Namen, die Menschen registrieren. Ein Name kann mehrere Arten von Records enthalten: Adressen (A-Records für IPv4, AAAA-Records für IPv6), aber auch die Namen der für ihn zuständigen Server (NS-Records) und Sicherheitsdaten für DNSSEC. ## Was passiert, wenn man einen Domainnamen eingibt: eine Abfrage Schritt für Schritt Angenommen, eine App braucht die Adresse von `www.example.com`. 1. Die App fragt den Stub-Resolver, ein kleines DNS-Programm auf dem Gerät. Er gibt die Frage an einen rekursiven Resolver weiter, meist betrieben vom Internetanbieter oder von einem öffentlichen DNS-Dienst. 2. Der rekursive Resolver prüft zuerst seinen Cache. Hat er die Antwort schon und ist ihre TTL (Time to Live) noch nicht abgelaufen, antwortet er sofort. 3. Andernfalls beginnt er an der Spitze. Die Adressen der Root-Server kennt er aus einer eingebauten Liste, den Root Hints. 4. Ein Root-Server kennt die Adresse von `www.example.com` nicht. Er antwortet mit einem Verweis (Referral): wo die Server für .com zu finden sind. 5. Auch ein .com-Server kennt die endgültige Antwort nicht. Er antwortet mit einem Verweis auf die Nameserver, die der Inhaber von example.com gewählt hat. 6. Einer dieser Nameserver ist autoritativ für example.com. Er liefert die Adresse in einem A- oder AAAA-Record. Der Resolver bewahrt die Antwort so lange auf, wie ihre TTL erlaubt, und gibt sie an das Gerät weiter. ## Resolver und autoritative Server: wer fragt und wer antwortet Resolver stellen Fragen im Auftrag von Nutzern. Autoritative Server beantworten sie aus den Daten der Zonen, die sie halten, ohne einen anderen Server zu fragen. Sie sind die Nameserver einer Domain, aufgeführt in ihren NS-Records. Manche rekursiven Resolver sind öffentliche DNS-Resolver: Dienste, die jeder im Internet anstelle des Resolvers seines Internetanbieters nutzen kann. Der Fachbegriff „Open Resolver“ meint meist etwas anderes: einen Resolver, der wegen falscher Konfiguration versehentlich jedem antwortet. Weil jede Abfrage über einen Resolver läuft, ist er auch ein Ort, an dem Namen gefiltert werden können. Die DNS-Standards enthalten Fehlercodes für einen Namen, der nach der eigenen Richtlinie des Betreibers gesperrt ist, der auf Verlangen eines Dritten gesperrt ist oder der auf Wunsch des Nutzers gefiltert wird. ## Delegation: wie die Arbeit von der Root bis zur eigenen Domain verteilt ist Der DNS-Baum ist in Zonen aufgeteilt. Ein Schnitt wird dort gesetzt, wo eine Organisation einen Teil des Baums kontrollieren, seine Daten selbst ändern und Teile davon weiter nach unten delegieren will. Eine übergeordnete Zone delegiert eine untergeordnete, indem sie NS-Records veröffentlicht, die auf deren Nameserver zeigen. Für eine Domain wie example.com sieht die Kette so aus: - Die IANA verwaltet die Root-Zone und hält fest, welche Server für jede TLD zuständig sind. PTI, eine mit der ICANN verbundene Organisation, nimmt die IANA-Funktionen wahr, und die IANA berechnet für diese Dienste nichts. - Verisign stellt als Root Zone Maintainer aufgrund einer Vereinbarung mit der ICANN die Root-Zonendatei nach den Vorgaben der IANA zusammen, signiert sie mit DNSSEC und schickt sie an die Betreiber der Root-Server. - Die Root-Server antworten mit Verweisen auf die Nameserver jeder TLD. - Die Registry der TLD veröffentlicht in ihrer eigenen Zone die NS-Records jedes registrierten Namens, dazu bei Bedarf Glue-Records und DS-Records. - Die vom Inhaber der Domain gewählten Nameserver antworten für die Domain selbst. Diese Delegation innerhalb des DNS ist etwas anderes als die Delegation einer TLD, also die Aufnahme einer neuen Top-Level-Domain in die Root-Zone. ## Häufige Fehler wie NXDOMAIN und SERVFAIL und was sie bedeuten Jede DNS-Antwort enthält einen Antwortcode. Zwei Fehlercodes kommen häufig vor. ### NXDOMAIN NXDOMAIN (Code 3, „name error“) bedeutet, dass der Name nicht existiert und auch kein Name darunter. Typische Gründe sind ein Tippfehler, eine nicht registrierte Domain oder eine Domain, deren Delegation aus der TLD-Zone entfernt wurde. ### SERVFAIL SERVFAIL (Code 2, „server failure“) bedeutet, dass die Abfrage nicht abgeschlossen werden konnte. Der Code sagt nicht, dass der Name fehlt, sondern nur, dass keine vertrauenswürdige Antwort zu bekommen war. Häufige Ursachen sind: - Nameserver, die für eine Zone eingetragen, aber nicht für sie eingerichtet sind; - Nameserver, die nicht antworten, oder Netzwerkstörungen auf dem Weg; - DNSSEC-Signaturen, deren Prüfung fehlschlägt; in diesem Fall muss ein validierender Resolver SERVFAIL liefern. Ein Resolver darf eine SERVFAIL-Antwort höchstens fünf Minuten lang aufbewahren. Mit Extended DNS Errors kann ein Server den Grund angeben, etwa „DNSSEC Bogus“. ### Ein Beispiel Angenommen, der Inhaber von example.com zieht die Domain auf neue Nameserver um, hat diese aber noch nicht für die Zone eingerichtet. Resolver, die der neuen Delegation folgen, können SERVFAIL liefern, bis die neuen Server konfiguriert sind. ## Wer das DNS betreibt und wer dafür bezahlt Keine einzelne Organisation betreibt das DNS. Jede Ebene hat ihre eigenen Betreiber und ihre eigene Finanzierung. - **Root-Server.** Stand Oktober 2026 werden 13 benannte Root-Server-Identitäten von 12 unabhängigen Organisationen betrieben, darunter Universitäten, Unternehmen und die ICANN selbst, mit mehr als 2.000 Instanzen weltweit. Die Betreiber werden für diesen Dienst nicht bezahlt und finanzieren ihn selbst. - **TLDs.** Jede gTLD-Registry muss das DNS ihrer TLD nach den Service Levels betreiben, die ihr Vertrag mit der ICANN festlegt. Stand Oktober 2026 muss der DNS-Dienst nach dem am 12. März 2026 gebilligten Base Registry Agreement zu 100 % der Zeit verfügbar sein; dafür müssen mindestens zwei der delegierten Nameserver der TLD korrekt antworten. Insgesamt 4 Stunden DNS-Ausfall in einer Woche sind die Schwelle für einen Notfallübergang der Registry. - **Domains.** Der Inhaber wählt die autoritativen Nameserver der Domain: Er bezahlt einen Anbieter dafür oder nutzt Server, die kostenlos in einem anderen Dienst enthalten sind. Seit 1987 verlangen die Regeln mehr als einen: RFC 1034 erwartet von jedem, der eine Zone übernimmt, den Nachweis redundanter Nameserver. - **Resolver.** Internetanbieter und öffentliche DNS-Dienste betreiben die Resolver, auf die sich Nutzer verlassen. ## Quellen - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 1034: Domain Names - Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034.txt) - [RFC 8914: Extended DNS Errors](https://www.rfc-editor.org/rfc/rfc8914.txt) - [Root Name Servers (IANA)](https://www.iana.org/domains/root/servers) - [Root Zone Management (IANA)](https://www.iana.org/domains/root) - [Base Registry Agreement (ICANN), approved 12 March 2026](https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-12-03-2026-en.pdf) ## verwandte begriffe - [Root-Zone](https://tldlog.com/de/glossar/root-zone/) - [Resolver](https://tldlog.com/de/glossar/resolver/) - [Nameserver](https://tldlog.com/de/glossar/nameserver/) - [TLD](https://tldlog.com/de/glossar/tld/) - [Domainname](https://tldlog.com/de/glossar/domainname/)