Anleitungen zu DNS setzen ihre Begriffe gern als bekannt voraus. Diese Seite tut das nicht. Jeder Eintrag hier ist an der einschlägigen Norm geprüft, und wo ein Begriff regelmäßig missverstanden wird, steht das Missverständnis gleich daneben.
Die Reihenfolge geht von den Grundlagen zu den Erweiterungen.
Ein Resolver, der die Namensauflösung nicht selbst vollständig durchführen kann und die eigentliche Auflösung an einen rekursiven Resolver abgibt. Er sitzt typischerweise im Betriebssystem oder in der Anwendung und stellt nur die Anfrage.
Häufiges Missverständnis: Häufig wird angenommen, der Stub-Resolver im Betriebssystem laufe selbst die Kette von den Root-Servern abwärts ab. Tatsächlich delegiert er die gesamte Auflösungsarbeit an einen rekursiven Resolver.
Ein Resolver im rekursiven Modus, der eine Anfrage entweder aus dem lokalen Cache beantwortet oder selbst weitere Server befragt, bis die endgültige Antwort vorliegt. In der Regel speichert er die erhaltenen Antworten im Cache zwischen.
Häufiges Missverständnis: Das Wort rekursiv beschreibt nur den Dienst gegenüber dem Client, nicht das Vorgehen nach außen. Gegenüber den autoritativen Servern arbeitet derselbe Resolver iterativ, er folgt also Verweisen Schritt für Schritt.
Ein Server, der den Inhalt einer DNS-Zone aus lokalem Wissen kennt und Anfragen zu dieser Zone ohne Rückfrage bei anderen Servern beantworten kann. Er setzt in solchen Antworten das AA-Bit im Header auf 1.
Häufiges Missverständnis: Nicht jede Antwort eines autoritativen Servers ist autoritativ: Verweise auf delegierte Kindzonen kommen mit AA-Bit 0. Außerdem kann ein Server autoritativ antworten, ohne dass die Elternzone ihm die Autorität delegiert hat.
Ein autoritativer Nameserver, der Anfragen zum Inhalt der Root-Zone beantwortet und damit den Einstiegspunkt in das Root-Server-System bildet. Die dreizehn Buchstabenidentitäten A bis M werden von zwölf unabhängigen Organisationen betrieben.
Häufiges Missverständnis: Dreizehn Buchstaben bedeuten nicht dreizehn Maschinen: Am 2026-09-07 bestand das System laut root-servers.org aus 2005 betriebsbereiten Instanzen. Der Begriff Mirror ist in diesem Zusammenhang veraltet, korrekt heißt es Instanz.
Eine Zone, die genau eine Ebene unterhalb der Root liegt, zum Beispiel com oder jp. Die meisten TLDs sind delegierungszentrierte Zonen, also Zonen, die überwiegend aus Delegierungen an Kindzonen bestehen.
Häufiges Missverständnis: Aus Sicht des DNS-Protokolls ist eine TLD nichts Besonderes, sie ist eine Zone wie jede andere. Die Unterscheidungen in ccTLD, gTLD und weitere sind reine Policy-Kategorien.
Die Praxis, eine bestimmte Dienstadresse an mehreren getrennten, autonomen Standorten verfügbar zu machen, sodass gesendete Datagramme zu einem dieser Standorte geroutet werden. Jeder dieser Standorte heißt Instanz.
Häufiges Missverständnis: Anycast ist kein Lastverteiler und garantiert nicht die geografisch nächste Instanz, denn das Routing entscheidet nach Topologie, nicht nach Entfernung. Unter Anycast-Instanzen gibt es keine Hierarchie, jede hat dieselbe Autorität.
Eine Adresse, die genau eine Schnittstelle bezeichnet; ein an eine Unicast-Adresse gesendetes Paket wird an genau diese Schnittstelle zugestellt. Im DNS-Kontext steht Unicast für den Fall, dass eine Serveradresse an nur einem Standort angekündigt wird.
Häufiges Missverständnis: Unicast identifiziert eine Schnittstelle, nicht einen Host; ein Host kann mehrere Unicast-Adressen tragen. Die in RFC 4291 zitierte Definition stammt aus der IPv6-Adressarchitektur, das Konzept ist aber nicht auf IPv6 beschränkt.
Eine Struktur, die die Ergebnisse früherer Antworten speichert, damit gleiche Anfragen nicht erneut entfernt aufgelöst werden müssen. Resolver sind dafür verantwortlich, alte Einträge nach Ablauf der TTL zu verwerfen.
Häufiges Missverständnis: Ein Cache hält Einträge nicht zwingend bis zum Ablauf der TTL; laut RFC 9499 kann ein RRset vorher aus dem Cache entfernt werden. Auch negative Antworten werden zwischengespeichert, das ist Negative Caching nach RFC 2308.
Die maximale Lebensdauer eines Resource Record, also das Zeitintervall in Sekunden, das der Record zwischengespeichert werden darf, bevor die Quelle erneut befragt werden sollte. Der Wert ist eine vorzeichenlose Zahl von 0 bis 2147483647.
Häufiges Missverständnis: Die TTL ist eine Obergrenze und keine Garantie: Ein Cache-Betreiber kann sie aus betrieblichen Gründen verkürzen, und ein RRset kann vorzeitig verworfen werden. Alle Records eines RRset müssen dieselbe TTL tragen (RFC 2181, Abschnitt 5.2).
Der DNS-Antwortcode 3 (Name Error), der besagt, dass der in der Anfrage genannte Domainname nicht existiert. Da Namen einen Baum bilden, bedeutet das Nichtexistieren eines Knotens auch das Nichtexistieren des gesamten darunter liegenden Teilbaums.
Häufiges Missverständnis: NXDOMAIN heißt, dass der Name selbst nicht existiert, nicht dass nur der abgefragte Record-Typ fehlt; letzteres ist eine NODATA-Antwort mit RCODE 0 und leerer Answer-Section. Ebenfalls falsch ist die Annahme, unterhalb eines NXDOMAIN-Namens könnten noch Namen existieren, denn RFC 8020 schließt das aus.
Der einzelne Dateneintrag des DNS, bestehend aus Owner-Name, Typ, Klasse, TTL und RDATA; die Menge der Informationen zu einem Namen setzt sich aus solchen Records zusammen. Records mit gleichem Owner-Name, gleicher Klasse und gleichem Typ bilden ein RRset.
Häufiges Missverständnis: Die Reihenfolge der Records in einer Menge ist ohne Bedeutung und muss von Servern und Resolvern nicht erhalten bleiben. Ein RRset wird zudem immer als Ganzes behandelt, und alle seine Records müssen dieselbe TTL haben.
DNSSEC ist eine Erweiterung des DNS, die per digitaler Signatur die Herkunft und die Unversehrtheit von DNS-Daten nachweisbar macht, spezifiziert in RFC 4033, RFC 4034 und RFC 4035. RFC 9364 (BCP 237) erklärt den Einsatz von DNSSEC zur Ursprungsauthentifizierung von DNS-Daten zur Best Current Practice.
Häufiges Missverständnis: DNSSEC verschlüsselt nichts. RFC 4033 Abschnitt 3 stellt ausdrücklich fest: „These extensions do not provide confidentiality.“, das heißt Anfragen und Antworten bleiben für jeden auf dem Weg mitlesbar, DNSSEC macht sie nur fälschungssicher.
DNSSEC-Validierung ist der Vorgang, bei dem ein Resolver die Signaturen einer Antwort kryptografisch prüft und dazu eine Authentifizierungskette aus DNSKEY- und DS-Datensätzen bis zu einem konfigurierten Trust Anchor aufbaut. Das Protokollverhalten validierender Resolver ist in RFC 4035 festgelegt.
Häufiges Missverständnis: Validierung schützt nur Zonen, die auch tatsächlich signiert sind. Für unsignierte Zonen kann ein Resolver nur beweisen, dass keine Signatur existiert, nicht dass die Antwort echt ist.
Das AD-Bit (Authentic Data) im DNS-Header wird von einem sicherheitsbewussten rekursiven Nameserver gesetzt, wenn er alle RRsets in Answer- und Authority-Abschnitt als authentisch validiert hat. RFC 4035 Abschnitt 3.2.3 verbietet das Setzen des Bits, solange nicht alle betroffenen RRsets als authentisch gelten.
Häufiges Missverständnis: Ein gesetztes AD-Bit ist kein Beweis. RFC 4033 Abschnitt 7 nennt es nur einen Hinweis und verlangt, dass der Stub-Resolver „must trust both the recursive name servers in question and the communication channels between itself and those name servers“, denn auf einem ungesicherten Kanal kann jeder Angreifer das Bit setzen.
Ein Trust Anchor ist laut RFC 4033 „A configured DNSKEY RR or DS RR hash of a DNSKEY RR“, den ein validierender Resolver als Startpunkt der Authentifizierungskette verwendet. RFC 5011 beschreibt, wie Trust Anchors automatisiert und authentifiziert ausgetauscht werden können.
Häufiges Missverständnis: Ein Trust Anchor ist kein X.509-Zertifikat und stammt nicht aus dem Browser- oder Betriebssystem-Zertifikatsspeicher. In der Praxis ist meist genau ein Anker konfiguriert, nämlich der der DNS-Root-Zone.
Der Root Zone Key Signing Key ist der von der IANA verwaltete DNSSEC-Schlüssel, mit dem der Schlüsselsatz der DNS-Root-Zone signiert wird und der als Vertrauensanker fast aller validierenden Resolver dient. Aktiv signierend ist KSK-2017 mit Key Tag 20326 („Signing since 2018-10-11“); der Nachfolger KSK-2024 mit Key Tag 38696 steht laut IANA in „Pre-Publication“ und soll ab dem 11. Oktober 2026 signieren.
Häufiges Missverständnis: Der KSK signiert nicht die einzelnen Root-Einträge, sondern nur den DNSKEY-Satz der Root-Zone; die eigentlichen Daten signiert der Zone Signing Key. Stand 2026-09-07 hat der Rollover auf KSK-2024 noch nicht stattgefunden.
DNS over TLS (DoT) transportiert DNS-Nachrichten in einer TLS-Sitzung über den fest zugewiesenen Port 853 und verhindert damit Mitlesen und Manipulation auf dem Weg. RFC 8310 ergänzt zwei Nutzungsprofile, Strict Privacy mit zwingender Serverauthentifizierung und Opportunistic Privacy ohne diese Garantie.
Häufiges Missverständnis: DoT im opportunistischen Profil authentifiziert den Server nicht und schützt daher nicht gegen einen aktiven Angreifer. Nur das Strict-Privacy-Profil nach RFC 8310 verweigert die Auflösung, wenn Verschlüsselung und Authentifizierung nicht zustande kommen.
DNS over HTTPS (DoH) bildet jedes DNS-Anfrage-Antwort-Paar auf einen HTTP-Austausch über HTTPS ab, sodass DNS-Verkehr verschlüsselt und von anderem HTTPS-Verkehr kaum unterscheidbar ist. Der Medientyp ist application/dns-message, üblich ist der Pfad-Template-Endpunkt eines konfigurierten DoH-Servers.
Häufiges Missverständnis: DoH verbirgt die besuchte Seite nicht vollständig. Erstens sieht der DoH-Betreiber weiterhin alle Anfragen im Klartext und kann sie laut RFC 8484 Abschnitt 8.2 zusätzlich über HTTP-Cookies, Header-Fingerprinting und IP-Adresse korrelieren; zweitens verrät die anschließende Verbindung selbst das Ziel, denn nach RFC 8744 wird „The SNI extension ... carried in cleartext in the TLS 'ClientHello' message“ und die Server-IP bleibt sichtbar.
DNS over QUIC (DoQ) überträgt DNS über dedizierte QUIC-Verbindungen auf UDP-Port 853 mit dem ALPN-Token „doq“ und bietet ähnliche Vertraulichkeit wie DoT ohne das Head-of-Line-Blocking von TCP. RFC 9250 beschreibt DoQ als Allzwecktransport für Stub-zu-Resolver, Resolver-zu-autoritativ und Zonentransfer.
Häufiges Missverständnis: DoQ auf UDP-Port 853 ist nicht dasselbe wie DoT, das TCP-Port 853 nutzt, und es ist auch nicht DNS over HTTP/3. Beide Seiten müssen DoQ ausdrücklich per ALPN aushandeln.
DNSCrypt ist ein herstelleroffenes, aber nicht von der IETF standardisiertes Protokoll, das laut dnscrypt.info „encrypts, authenticates and optionally anonymizes communications between your DNS client and resolver“. Version 2 der Spezifikation nutzt die Konstruktion X25519-XChaCha20Poly1305 sowie Ed25519 für die Signatur der Resolver-Zertifikate.
Häufiges Missverständnis: DNSCrypt ist kein RFC und kein IETF-Standard, sondern liegt nur als individueller Internet-Draft und als eigene Protokollspezifikation vor. Es ist außerdem nicht mit DNSSEC verwandt, denn es sichert den Transportweg, nicht die Zonendaten.
Oblivious DNS over HTTPS (ODoH) schiebt einen Proxy zwischen Client und DoH-Target, sodass der Proxy die IP-Adresse des Clients kennt, aber nicht den Inhalt, und das Target den Inhalt entschlüsselt, aber nur die Proxy-IP sieht. Das Verfahren ist in RFC 9230 als Experimental veröffentlicht.
Häufiges Missverständnis: Der Schutz hängt daran, dass Proxy und Target nicht zusammenarbeiten oder demselben Betreiber gehören. Kolludieren beide, ist die Trennung von Identität und Inhalt aufgehoben.
EDNS(0) erweitert das DNS-Drahtformat rückwärtskompatibel über ein OPT-Pseudo-RR (Typ 41) im Additional-Abschnitt, das größere UDP-Nachrichten als 512 Byte, zusätzliche Flag-Bits und einen erweiterten RCODE-Bereich ermöglicht. Das OPT-Record trägt keine Zonendaten, sondern ausschließlich Steuerinformation.
Häufiges Missverständnis: Die vom Client angegebene UDP-Payload-Größe ist nur eine Angabe der eigenen Empfangsfähigkeit, keine Garantie, dass Pfad-MTU und Firewalls Pakete dieser Größe durchlassen. EDNS(0) ist außerdem kein Sicherheitsmechanismus, sondern nur der Trägermechanismus für Optionen wie Padding, ECS oder DNS Cookies.
EDNS Client Subnet (ECS) ist eine EDNS(0)-Option, mit der ein Resolver einen gekürzten Teil des Client-Netzpräfixes an autoritative Server weiterreicht, damit diese geografisch passende Antworten liefern und der Cache-Gültigkeitsbereich bekannt wird. RFC 7871 ist Informational und beschreibt ein bereits im Einsatz befindliches Verfahren.
Häufiges Missverständnis: ECS untergräbt einen Teil des Datenschutzgewinns von verschlüsseltem DNS, weil Netzinformationen des Nutzers an jeden beteiligten autoritativen Server weitergereicht werden. RFC 7871 empfiehlt daher ausdrücklich, die Option in Nameserver-Software standardmäßig zu deaktivieren.
Bei der QNAME-Minimierung sendet ein Resolver einem autoritativen Server nicht mehr den vollständigen Namen und Typ, sondern nur den um ein Label längeren Teil des Namens, für den dieser Server zuständig ist. RFC 9156 ist Standards Track und ersetzt RFC 7816.
Häufiges Missverständnis: QNAME-Minimierung schützt nur gegenüber den vorgelagerten autoritativen Servern wie den Root- und TLD-Servern. Der eigene rekursive Resolver sieht weiterhin den vollständigen angefragten Namen.
Die EDNS(0)-Padding-Option (Optionscode 12) erlaubt es Client und Server, DNS-Nachrichten um eine variable Zahl von Oktetten aufzufüllen, um Rückschlüsse aus der Nachrichtenlänge zu erschweren. RFC 8467 empfiehlt experimentell Blocklängen-Padding auf ein Vielfaches von 128 Oktetten für Anfragen und 468 Oktetten für Antworten.
Häufiges Missverständnis: Padding ist nur sinnvoll innerhalb eines verschlüsselten Transports wie DoT, DoH oder DoQ. Auf unverschlüsseltem DNS bringt es keinen Datenschutzgewinn, weil der Inhalt ohnehin lesbar ist.
Encrypted Client Hello (ECH) ist eine TLS-Erweiterung, die das ClientHello unter einem öffentlichen Serverschlüssel verschlüsselt und damit sensible Felder wie SNI und die ALPN-Liste verbirgt. Die dafür nötige Konfiguration wird üblicherweise über den DNS-Ressourcendatensatz HTTPS/SVCB bezogen.
Häufiges Missverständnis: ECH allein verbirgt das Ziel nicht. RFC 9849 stellt fest: „ECH is not in itself sufficient to protect the identity of the server. The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses.“
Server Name Indication (SNI) ist die TLS-Erweiterung, mit der ein Client dem Server im Handshake mitteilt, welchen Hostnamen er kontaktieren will, damit ein Server mehrere virtuelle Hosts unter einer IP-Adresse bedienen kann. Sie ist in RFC 6066 Abschnitt 3 definiert.
Häufiges Missverständnis: Ohne ECH wird der Hostname im SNI im Klartext übertragen, obwohl die Verbindung als HTTPS gilt. RFC 8744 hält fest, dass Überwachung sich zunehmend genau auf „the cleartext SNI“ stützt, um zu erkennen, welche Dienste ein Nutzer aufruft.
Ein DNS-Sinkhole ist ein Resolver, der Anfragen für unerwünschte Namen bewusst nicht wahrheitsgemäß beantwortet, sondern etwa NXDOMAIN, NODATA oder eine umgeleitete Adresse liefert, um Verbindungen zu Schadinfrastruktur oder Werbe- und Trackingdomains zu unterbinden. In BIND 9 wird dies über Response Policy Zones umgesetzt, die die ISC-Dokumentation als „a form of DNS firewall“ beschreibt.
Häufiges Missverständnis: Ein Sinkhole blockiert nur die Namensauflösung, nicht die Verbindung selbst. Wer die IP-Adresse direkt kennt oder einen eigenen verschlüsselten Resolver im Gerät verwendet, umgeht das Sinkhole vollständig; außerdem kollidiert eine gefälschte Antwort mit DNSSEC-Validierung.
Ein Forwarder ist nach RFC 9499 „A nameserver used to resolve queries instead of directly using the authoritative nameserver chain“; Forwarding ist der Vorgang, bei dem ein Server eine Anfrage mit gesetztem RD-Bit an einen anderen Server zur Auflösung weitergibt. RFC 9499 ist BCP 219 und die aktuelle DNS-Terminologie.
Häufiges Missverständnis: Forwarding ist nicht dasselbe wie blindes Weiterreichen von Paketen, sondern eine Resolver-Funktion mit eigenem Cache. Wer einen Forwarder einsetzt, verlagert damit auch die Vertrauensfrage und die Sichtbarkeit aller Anfragen auf den Upstream-Betreiber.
DNS-Rebinding-Schutz filtert Antworten aus öffentlichen Zonen heraus, die auf private oder lokale IP-Adressbereiche zeigen, damit ein Angreifer den Browser eines Nutzers nicht als Proxy in dessen internes Netz missbrauchen kann. Unbound setzt dies mit der Option private-address um, die passende A-, AAAA-, SVCB- und HTTPS-Einträge aus Antworten entfernt.
Häufiges Missverständnis: Der Schutz greift nur für Namen aus öffentlichen Zonen und kann legitime Anwendungsfälle brechen, etwa Split-Horizon-Setups oder Dienste wie ACME-Validierung, die absichtlich private Adressen veröffentlichen. Dafür sieht Unbound ausdrücklich Ausnahmen über private-domain vor.
Jede oben genannte Norm im Volltext beim RFC Editor.