DNS: Auflösung, Delegation und Betrieb

DNS beantwortet die Frage, welche Information für einen bestimmten Namen veröffentlicht ist und wer dafür zuständig ist. Das System ist gleichzeitig ein hierarchischer Namensraum, eine verteilte Datenbank und ein binäres Abfrageprotokoll. Es liefert nicht nur IP-Adressen, sondern auch Nameserver, Mailziele, Dienstendpunkte, Schlüssel und Richtlinien. Wer DNS lediglich als «Namensauflösung» betrachtet, übersieht deshalb genau jene Datensätze, von denen Messaging und Identität abhängen (RFC 9499).

Der folgende Weg beginnt beim Stub Resolver einer Anwendung, folgt Cache und Delegationen bis zum autoritativen Server und führt die Antwort anschliessend zurück. An diesem Ablauf lassen sich TTL, Glue, TCP-Fallback, DNSSEC, Zonenbetrieb und die typischen Fehlerbilder einordnen.

Für Messaging-Administratoren ist DNS ein vorgelagertes Steuerungssystem. Ein MTA ermittelt darüber das nächste Mailziel, Senderauthentifizierung liest Richtlinien und Schlüssel, Zertifikatsverfahren können DNSSEC-gesicherte Daten einbeziehen, und Verzeichnis- oder Kerberos-Clients suchen Dienste über SRV-Records. DNS prüft jedoch nicht, ob der gefundene Dienst gesund ist. Eine syntaktisch korrekte MX-Antwort kann auf einen nicht erreichbaren SMTP-Listener zeigen; ein erfolgreicher A-Lookup sagt nichts über TLS, Authentisierung oder Applikationszustand aus.

Architektur und Rollen

Die Zuständigkeit für Namen ist als Baum organisiert. An der namenlosen Wurzel . beginnen Top-Level-Domains wie ch., darunter folgen delegierte Domains und weitere Labels. Ein abschliessender Punkt macht einen Namen vollständig und verhindert lokale Suchsuffixe. Diese kleine Schreibweise ist betrieblich relevant: mail.example.ch kann auf einem Client um eine Search Domain ergänzt werden, mail.example.ch. nicht.

Eine Domain ist ein Teil des Namensraums. Eine Zone ist dagegen die administrativ zusammenhängende Datenmenge, für die ein autoritativer Server lokale Verantwortung besitzt. Eine Delegation trennt eine Child-Zone aus der Parent-Zone heraus. Der Parent veröffentlicht dafür ein NS-RRset und, wenn ein Nameservername innerhalb der delegierten Child-Zone liegt, die zum Erreichen nötigen A- oder AAAA-Daten als Glue. Die grundlegende Trennung von Namensraum, Zonen und Delegation stammt aus RFC 1034; aktuelle Begriffe fasst RFC 9499, Abschnitt 7 zusammen.

Vier logische Rollen erklären den Auflösungsweg:

Ein Produkt kann mehrere Rollen implementieren, betrieblich sollten sie dennoch getrennt betrachtet werden. Ein Fehler im autoritativen Dienst betrifft die Veröffentlichung eigener Zonen; ein Fehler im rekursiven Dienst betrifft die Namensauflösung der eigenen Clients. Gemeinsame Prozesse, Adressen oder Ausfallbereiche erschweren diese Unterscheidung.

Namensauflösung Schritt für Schritt

Eine Anwendung fragt normalerweise nicht selbst Root- und autoritative Server ab. Ihr Stub Resolver übergibt eine rekursive Anfrage an einen Resolver. Fehlt dort ein brauchbarer Cacheeintrag, folgt dieser den Delegationen von der Root über die Top-Level-Domain bis zur zuständigen Zone. Jede Referral nennt den nächsten NS-RRset und bei Bedarf Glue-Adressen. Der Resolver setzt daraus die Endantwort zusammen, validiert gegebenenfalls DNSSEC und cached das Ergebnis (RFC 1034, Abschnitt 4.3).

Der gezeichnete lineare Weg ist ein Kaltstartmodell. In einem warmen Resolvercache sind Root- und TLD-Delegationen meist bereits vorhanden, sodass nur ein Teil der Schritte nötig ist. Auch QNAME-Minimierung, Forwarding, lokale Zonen oder aggressive DNSSEC-Caches können den sichtbaren Paketpfad verändern. Entscheidend bleibt, jede Beobachtung einer Rolle zuzuordnen: Eine nichtautoritative Cache-Antwort ist kein Beleg dafür, was der zuständige autoritative Server in diesem Moment ausliefert.

Technischer Aufbau einer DNS-Nachricht

Auf dem Wire besteht eine DNS-Nachricht aus Header, Question, Answer, Authority und Additional Section. Die Frage benennt QNAME, QTYPE und QCLASS. Antworten und Verweise erscheinen als Resource Records in den übrigen Abschnitten. Flags zeigen unter anderem Autorität, Rekursionswunsch und Trunkierung; der Response Code beschreibt das Ergebnis. Für die Analyse zählt deshalb nicht nur der Answer-Text, sondern auch, von welchem Server und mit welchen Flags er kam (RFC 1035, Abschnitt 4.1).

Für eine Diagnose sind besonders relevant:

EDNS(0) ergänzt über einen pseudoartigen OPT-Record zusätzliche Flags, Optionen und eine grössere angekündigte UDP-Nutzlast, ohne das Grundformat zu ersetzen (RFC 6891). Das DNSSEC-DO-Bit befindet sich in diesem erweiterten Flagfeld, nicht im ursprünglichen DNS-Header.

Resource Records und RRsets

Der fachliche Inhalt liegt in Resource Records. Owner Name, Typ und Klasse bestimmen, wozu die Daten gehören; TTL und RDATA liefern Cachezeit und typspezifischen Wert. Alle Records mit gleichem Owner, Typ und gleicher Klasse bilden ein RRset und teilen eine TTL. Mehrere MX-, A- oder AAAA-Werte sind daher eine gemeinsam gecachte Menge, keine unabhängig steuerbaren Einzelobjekte (RFC 2181, Abschnitt 5).

Der Text in einer Zonendatei ist nur die Presentation Form. Auf dem Netz werden Namen labelweise, Zahlen binär und bestimmte Namen optional komprimiert übertragen. Wer eine Zeichenkette aus einer UI kopiert, sollte daher unterscheiden, ob die UI bereits Anführungszeichen, Escape-Sequenzen oder mehrere TXT-Strings zu einer logischen Nutzlast zusammengesetzt hat.

Delegation, Glue und Autorität

Mit einer Delegation übergibt eine Zone die Verantwortung für einen Unterbaum. Der Parent veröffentlicht das NS-RRset der Child-Zone; die Child-Zone nennt ihre autoritativen Server nochmals selbst. Weichen beide Seiten voneinander ab, können Resolver unterschiedliche Pfade nehmen. Glue-Adressen im Parent lösen nur das Henne-Ei-Problem der Erreichbarkeit. Die autoritativen A-/AAAA-Werte am Nameservernamen bleiben eigenständige Daten mit eigener TTL und Pflege.

Besonders kritisch ist in-bailiwick Glue: Wird example.ch. an ns1.example.ch. delegiert, benötigt der Resolver die Adresse von ns1.example.ch., bevor er die Child-Zone befragen kann. Ohne Glue entstünde ein Auflösungszirkel. Zeigt die Delegation dagegen auf ns1.provider.net., kann dessen Adresse über eine andere Delegationskette ermittelt werden.

Bei einem Nameserverwechsel sind deshalb mindestens vier Zustände zu prüfen: neue Zone auf allen Servern geladen, Child-NS-RRset angepasst, Parent-Delegation angepasst und erforderliches Glue aktualisiert. Erst danach sollten alte Server aus Betrieb oder Erreichbarkeit genommen werden.

Cache, TTL und negative Antworten

Nach der Auflösung lebt eine Antwort in Caches weiter. Ihre TTL ist die maximale Nutzungsdauer ab dem Zeitpunkt, an dem der jeweilige Resolver sie gelernt hat. Es existiert daher kein weltweit gemeinsamer Countdown. Stub Resolver, Forwarder, rekursive Resolver und Anwendungen können denselben alten RRset zu unterschiedlichen Zeiten verwerfen. Eine vor einer Migration gesenkte TTL hilft nur für Antworten, die danach neu geladen werden; bereits gecachte Daten lassen sich nicht zurückrufen.

Auch Nichtexistenz wird gecacht. NXDOMAIN bedeutet, dass der angefragte Name nicht existiert; NODATA ist eine NOERROR-Antwort, bei der der Name existiert, aber kein RRset des abgefragten Typs. Der autoritative Server legt bei beiden Antworten sein SOA-RR in die Authority Section. Die negative Cachezeit ist das Minimum aus SOA-TTL und SOA.MINIMUM (RFC 2308, Abschnitte 3 bis 5). Das erklärt, weshalb ein neu angelegter DKIM-Selektor oder Hostname nach einem vorherigen Fehlversuch zunächst weiter als nicht vorhanden erscheinen kann.

SERVFAIL ist davon zu unterscheiden: Der Resolver konnte keine verwertbare Antwort herstellen. Ursachen sind unter anderem Timeouts zu autoritativen Servern, eine kaputte Delegation, ein DNSSEC-Validierungsfehler oder eine interne Ressourcenbegrenzung. REFUSED bedeutet dagegen, dass der angefragte Server die Operation aufgrund seiner Policy nicht ausführt. Ein Diagnosewerkzeug muss daher RCODE, AA-Bit, antwortenden Server und Sections anzeigen; eine Ausgabe, die nur «keine Adresse» meldet, verwischt entscheidende Unterschiede.

Transport: UDP, TCP und verschlüsselte Resolverpfade

Für diesen Austausch muss der Netzpfad UDP und TCP auf Port 53 zulassen. TCP ist nicht auf Zonentransfers beschränkt: Ein Resolver darf es direkt verwenden und muss nach einer gekürzten UDP-Antwort darauf ausweichen können. Blockiertes TCP fällt deshalb oft erst bei grossen, DNSSEC-reichen oder antwortreichen RRsets auf. Kleine A-Abfragen bleiben grün und vermitteln ein falsches Bild (RFC 7766).

Ohne EDNS ist die DNS-Nutzlast über UDP auf 512 Byte begrenzt. EDNS erlaubt dem Anfragenden, eine grössere empfangbare Nutzlast anzukündigen. Ein zu grosser Wert kann jedoch IP-Fragmentierung erzwingen; verliert oder blockiert ein Pfad Fragmente, entsteht das typische Bild kleiner Antworten funktionieren, grosse Antworten timeouten. Die EDNS-Spezifikation empfiehlt, die tatsächliche Empfangsfähigkeit und den Pfad zu berücksichtigen und bei Problemen auf kleinere Werte oder TCP auszuweichen (RFC 6891, Abschnitt 6.2).

DNS over TLS, DNS over HTTPS oder DNS over QUIC verschlüsselt einen DNS-Transportpfad. Diese Verfahren ändern weder Zoneninhalt noch Delegation und ersetzen DNSSEC nicht: Transportverschlüsselung schützt die Verbindung zu einem Resolver, DNSSEC authentisiert Daten entlang der Delegationskette. Klassisches DNS auf Port 53 ist unverschlüsselt; die gemeinsame Terminologie der Transportarten definiert RFC 9499, Abschnitt 6.

DNSSEC und Vertrauenskette

DNSSEC ergänzt die Namensauflösung um überprüfbare Herkunft und Integrität. Eine Zone signiert RRsets mit RRSIG und veröffentlicht die öffentlichen Schlüssel als DNSKEY. Der Parent verbindet die Child-Zone über DS mit der darüberliegenden Vertrauenskette; NSEC oder NSEC3 kann auch Nichtexistenz belegen. Ein validierender Resolver beginnt bei seinem Trust Anchor und prüft diese Kette bis zur Antwort. Der Inhalt bleibt dabei öffentlich: DNSSEC verschlüsselt keine Abfrage (RFC 4033, RFC 4034).

Für den Betrieb sind nicht nur Schlüsseldateien relevant, sondern mehrere zeitlich gekoppelte Zustände:

• RRSIGs besitzen Beginn und Ablauf; falsche Systemzeit oder ausgefallene Nachsignierung kann eine ganze Zone bogus machen.
• Ein DS im Parent muss zu einem verwendbaren DNSKEY der Child-Zone passen. Ein verwaister DS ist für validierende Resolver schlimmer als eine bewusst unsignierte Delegation.
• Bei Rollovers müssen Veröffentlichung, Signierung, Parentänderung, TTLs und Cachezeiten als Zustandsmaschine geplant werden.
• Ein validierender Resolver liefert für bogus Daten häufig SERVFAIL. Ein Test ohne Validierung kann gleichzeitig eine scheinbar normale Antwort anzeigen.

Der AD-Flag allein ist nur so vertrauenswürdig wie der Resolver und der Pfad zu ihm. Für eine unabhängige Prüfung muss ein Admin die Kette mit einem validierenden Werkzeug untersuchen und den fehlerhaften Übergang zwischen DS, DNSKEY und RRSIG lokalisieren.

Autoritativer Betrieb und Datenfluss

Hinter der autoritativen Antwort steht ein eigener Verteilungsweg. In einem klassischen Modell führt eine primäre Quelle die Zone, DNS NOTIFY informiert Secondaries über eine neue SOA-Serial und AXFR oder IXFR übertragen vollständige beziehungsweise inkrementelle Daten. Ein gesunder Listener belegt daher noch nicht, dass der Server die neue Zone geladen hat. Serial, Transferstatus und Antwort jedes autoritativen Knotens müssen zusammen betrachtet werden (RFC 1996, RFC 5936, RFC 1995).

Die Zone kann aus Textdateien, einer Datenbank, einer API, Active Directory oder einer Git-/CI-Pipeline erzeugt werden. Diese Implementierungswahl ändert das DNS-Wire-Protokoll nicht, bestimmt aber Transaktionsgrenzen, Auditierbarkeit und Recovery. RFC 2136 definiert atomare dynamische Updates mit Prerequisites; ein Anbieter-API-Aufruf ist dagegen ein separates Steuerprotokoll und muss seine eigenen Konsistenz- und Fehlerregeln dokumentieren (RFC 2136).

Ein DNS-Backup ist erst brauchbar, wenn daraus die tatsächlich ausgelieferte Zone wiederhergestellt werden kann. Dazu gehören je nach Plattform:

• Zone oder Quell-Datenbank einschliesslich SOA-Serial und dynamischem Journal;
• Serverkonfiguration, Views, ACLs, Forwarder und Katalogzuordnung;
• TSIG-Secrets, DNSSEC-Private-Keys und Zustände automatischer Rollovers;
• Parentdaten ausserhalb der eigenen Zone, insbesondere Delegation, Glue und DS;
• ein getesteter Weg, Secondaries neu zu versorgen und Zonendaten semantisch zu prüfen.

Secondaries sind Verfügbarkeitskopien, aber nicht automatisch ein historisches Backup. Eine fehlerhafte oder böswillige Änderung kann über NOTIFY und Zonentransfer schnell auf alle autoritativen Server repliziert werden.

Implementierungs- und Technologiestack

DNS bezeichnet keinen einzelnen Daemon. Der gemeinsame Technologiestack besteht aus Namen und RRsets, binärem Query-/Response-Format, UDP und TCP, Cachelogik und optional DNSSEC. Autoritative Server, rekursive Resolver, Forwarder und Managed DNS setzen diese Bausteine unterschiedlich um. Für den Betrieb zählt deshalb zuerst die Rolle eines Produkts, danach seine Sprache oder sein Packaging:

Die Trennung der Rollen ist wichtiger als der Produktname. Für eine öffentliche autoritative Plattform zählen Zonenbereitstellung, Secondaries, DNSSEC-Signing und DDoS-Resilienz; für einen Unternehmensresolver zählen Cache, Forwarding, interne Namensräume, Policy, Datenschutz und Validierung.

DNS im Mail- und Identitätsbetrieb

Im Messaging wird aus einer DNS-Antwort unmittelbar ein Zustellpfad. Ein sendender MTA fragt die MX-RRsets der Empfängerdomain ab, bevorzugt den kleinsten Wert und behandelt gleiche Präferenzen als gleichwertig. Nur wenn kein MX existiert, gilt die Domain selbst als implizites Ziel. Sobald MX-Records vorhanden sind, ist ein A-/AAAA-Wert am Domain-Apex kein Ersatz. Jedes MX-Ziel braucht eigene Adressen und darf kein Alias sein; eine Domain ohne Mailannahme veröffentlicht Null MX 0 . (RFC 5321, Abschnitt 5, RFC 2181, Abschnitt 10.3, RFC 7505).

PTR-Records werden über den umgekehrten Adressbaum aufgelöst. Vorwärts- und Rückwärtszone haben häufig unterschiedliche Eigentümer; Änderungen müssen daher zwischen Domain- und IP-Adressbetreiber koordiniert werden. Ein PTR ist ein Name, kein kryptografischer Identitätsnachweis. Empfangende Mailplattformen können konsistente Vorwärts-/Rückwärtsabbildung als Signal verwenden, ihre konkrete Reputation- oder Annahmepolicy ist aber keine DNS-Eigenschaft.

SPF, DKIM und DMARC verwenden DNS als Publikationskanal, definieren jedoch eigene Auswertungsregeln. SPF liest eine einzelne logische TXT-Nutzlast und begrenzt DNS-verursachende Terme; DKIM adressiert Schlüssel über Selektoren; DMARC liegt unter _dmarc. Diese Verfahren gehören fachlich in SPF, DKIM und DMARC. Der DNS-Admin muss für sie vor allem Owner Name, TXT-Stringaufteilung, Antwortgrösse, TTL, Delegation und negative Cachezeiten korrekt beherrschen.

Auch LDAP und Kerberos verwenden häufig SRV-Records zur Dienstsuche. Ein SRV-Record enthält neben Ziel und Port eine Priorität und ein Gewicht. Diese Werte sind keine universelle Load-Balancer-Konfiguration; nur Clients, die das jeweilige SRV-Verfahren implementieren, interpretieren sie.

Diagnose

Die Diagnose beginnt deshalb nie mit «DNS geht nicht», sondern mit Name, Typ, Klasse, abgefragtem Server, Transport und Zeitpunkt. Unternehmensresolver, öffentliche Resolver und autoritative Server dürfen vorübergehend oder durch Split DNS und Policy unterschiedliche Antworten liefern. Diese Abweichung ist nicht Messrauschen, sondern der wichtigste Hinweis darauf, an welcher Stelle der Auflösungsweg auseinanderläuft.

RRsets gezielt abfragen

$server = "192.0.2.53"
Resolve-DnsName example.ch. -Type SOA -Server $server -DnsOnly
Resolve-DnsName example.ch. -Type MX -Server $server -DnsOnly
Resolve-DnsName _dmarc.example.ch. -Type TXT -Server $server -DnsOnly
Resolve-DnsName 25.113.0.203.in-addr.arpa. -Type PTR -Server $server -DnsOnly

server=192.0.2.53
dig @"$server" example.ch. SOA +noall +answer +authority
dig @"$server" example.ch. MX +noall +answer +authority
dig @"$server" _dmarc.example.ch. TXT +noall +answer +authority
dig @"$server" -x 203.0.113.25 +noall +answer +authority

Resolve-DnsName kann einen bestimmten Server, Recordtyp, reines DNS und TCP erzwingen. dig zeigt zusätzlich Flags, Sections, RCODE, antwortenden Server und Queryzeit. Ohne explizites -Server beziehungsweise @server wird der konfigurierte Resolver getestet, nicht zwingend die autoritative Quelle.

TCP und DNSSEC getrennt prüfen

$server = "192.0.2.53"
Resolve-DnsName example.ch. -Type MX -Server $server -DnsOnly -TcpOnly
Resolve-DnsName example.ch. -Type DNSKEY -Server $server -DnsOnly -DnssecOk

server=192.0.2.53
dig @"$server" example.ch. MX +tcp
dig @"$server" example.ch. DNSKEY +dnssec
delv @"$server" example.ch. MX

delv verwendet die BIND-Resolver- und Validatorlogik, um eine DNSSEC-Kette zu prüfen. Eine erfolgreiche Abfrage mit +dnssec beweist dagegen nur, dass DNSSEC-Daten angefordert und geliefert wurden; sie validiert die Kette nicht automatisch. Der getrennte TCP-Test deckt Firewalls auf, die UDP/53 zulassen, aber TCP/53 blockieren.

Lokale Caches gezielt leeren

Clear-DnsClientCache

sudo resolvectl flush-caches
resolvectl statistics

Clear-DnsClientCache leert den Cache des Windows-DNS-Clients. resolvectl steuert den Cache von systemd-resolved; auf Systemen mit nscd, dnsmasq, einem lokalen Unbound oder einem Applikationscache ist ein anderer Cache zuständig. Ein Flush des Clients verändert niemals den Cache eines Upstream-Resolvers.

Fehlerbild dem Übergabepunkt zuordnen

Monitoring und Betriebskriterien

Monitoring muss denselben Weg abbilden. Ein einzelner A-Lookup gegen den lokalen Standardresolver erkennt weder eine kaputte Delegation noch blockiertes TCP, abgelaufene Signaturen oder einen Secondary mit alter Serial. Für Messaging und Identität sollten deshalb mindestens folgende Signale getrennt erfasst werden:

• autoritative Antworten jedes veröffentlichten NS über UDP und TCP, einschliesslich AA-Bit und SOA-Serial;
• Parentdelegation, Child-NS-RRset, Glue und bei signierten Zonen der DS/DNSKEY-Übergang;
• rekursive Latenz, Cache-Hit-Verhältnis, Timeout-, SERVFAIL-, REFUSED- und NXDOMAIN-Raten;
• Antwortgrösse, Trunkierung, EDNS-Fehler und TCP-Fallback;
• Ablaufzeitpunkte von RRSIGs, Key-Rollover-Zustand und Signierungswarteschlangen;
• NOTIFY-, AXFR- und IXFR-Erfolg sowie Alter der Zone auf jedem Secondary;
• fachliche RRsets wie MX, zugehörige A/AAAA-Adressen, PTR und die für Mail-Authentisierung benötigten TXT-Namen.

Ein synthetischer Test sollte sowohl den normalen Clientpfad als auch die autoritative Quelle prüfen. Nur so lässt sich unterscheiden, ob eine Störung im veröffentlichten Datenbestand, in der Delegation, in einem Resolvercache oder in der Anwendung liegt.

Sicherheit und Ausfallbereiche

Die beiden Serverrollen verlangen unterschiedliche Schutzmassnahmen. Rekursion gehört nur zu vertrauenswürdigen Clients; ein offener Resolver lässt sich für Reflexions- und Verstärkungsangriffe missbrauchen. Autoritative Server müssen dagegen weltweit erreichbar bleiben, dürfen aber keine beliebigen fremden Namen rekursiv auflösen. Rollen zu mischen vergrössert Angriffsfläche und macht Lastursachen schwerer erkennbar (RFC 5358).

DNSSEC schützt veröffentlichte RRsets vor unbemerkter Veränderung, nicht den Serverprozess und nicht die Verfügbarkeit. TSIG authentisiert einzelne DNS-Nachrichten mit einem gemeinsamen Schlüssel und wird unter anderem für Updates und Zonentransfers verwendet; es ist keine öffentliche Signatur der Zonendaten (RFC 8945). Transfer-ACLs, TSIG-Secrets und DNSSEC-Private-Keys sind getrennte Schutzobjekte.

Split DNS und Policy-Antworten können notwendig sein, erzeugen aber mehrere Wahrheiten für denselben QNAME/QTYPE. Dokumentiert werden müssen mindestens Zuordnungskriterium, Quellzone, Forwardingpfad, DNSSEC-Verhalten und Monitoring je View. Sonst wird eine gewollte Abweichung bei der nächsten Störung als Cachefehler oder Replikationsproblem interpretiert.

Technische Geschichte

Vor DNS verteilte das Internet zentral gepflegte Hosttabellen. Mit mehr Netzen, Hosts und unabhängigen Betreibern wurde dieses Verfahren zum Flaschenhals. Paul Mockapetris beschrieb 1983 in RFC 882 und RFC 883 einen hierarchisch delegierbaren Namensdienst. RFC 1034 und RFC 1035 ersetzten diese Fassung 1987 und bilden als STD 13 weiterhin den Kern des Systems.

Die erste arbeitsfähige Serverimplementierung Jeeves lief 1983/84 auf DEC-TOPS-20-Systemen. Kurz darauf entstand an der University of California, Berkeley, unter DARPA-Förderung das Berkeley Internet Name Domain Package BIND für Unix. BIND 8 erschien 1997, BIND 9 im September 2000 als weitgehende Neuentwicklung. Diese Entwicklungsgeschichte dokumentiert ISC in A Brief History of the DNS and BIND.

Das Protokoll wuchs schrittweise, ohne den hierarchischen Kern zu ersetzen: NOTIFY und IXFR beschleunigten in den 1990er-Jahren den Zonenabgleich, EDNS erweiterte 1999 das Nachrichtenmodell und wurde später in RFC 6891 konsolidiert, DNSSEC erhielt 2005 die heute grundlegenden DNSKEY-/DS-/RRSIG-Mechanismen, und verschlüsselte Resolvertransporte kamen mit DoT, DoH und DoQ hinzu. DNS ist deshalb kein eingefrorenes Protokoll von 1987, sondern ein erweiterbares System, dessen Abwärtskompatibilität und lange Cachezustände jede Änderung betrieblich prägen.