Zusammenfassung

  • Der Entwurf zu DNS Delegation Extensions macht SLIST zu einer Menge, die NS und mehrere neue Delegation Types aufnehmen kann; identische Werte erscheinen nur einmal, zyklische Abhängigkeiten und ungebremste Verarbeitung bleiben aber möglich.
  • Der Aufbau dieser Kandidatenmenge belegt weder Serverauswahl noch Verbindung oder verschlüsselten Transport; dafür braucht es getrennte Betriebsnachweise und harte Ressourcengrenzen.

Auf den ersten Blick war die Korrektur sauber. Derselbe Server tauchte in mehreren Delegationsdaten auf, wurde aber in der finalen SLIST nur einmal geführt. Die Zahl der Einträge blieb überschaubar. Trotzdem stieg die Rechenarbeit mit jeder Runde, weil ein Datensatz zum nächsten verwies, dieser weitere Informationen auslöste und die Abhängigkeit schließlich zum Ausgangspunkt zurückführte.

Duplikatfreiheit ist eine Eigenschaft der Menge. Endlichkeit der Suche ist eine Eigenschaft des Verfahrens. Die beiden dürfen nicht miteinander verwechselt werden.

Genau diese Grenze macht Revision 11 von DNS Protocol Modifications for Delegation Extensions sichtbar. Der Internet-Draft stammt vom 17. September 2026, läuft am 21. März 2027 aus und ist eine aktive Arbeit der DNSOP Working Group für den Standards Track. Er ist kein endgültiger RFC, kein Implementierungsnachweis und keine Adoptionsmessung. Seine Aussagen beschreiben vorgeschlagenes Verhalten; sie belegen nicht, dass ein genannter Resolver es bereits zeigt.

Der Entwurf schafft eine Klasse von Resource-Record-Typen, die am Delegationspunkt autoritativ sind und Resolvern Informationen zur Bearbeitung der Delegation liefern. Diese Delegation Types können traditionelle NS-Daten ersetzen, sie ergänzen oder nur auf ausdrückliche Anfrage erscheinen. Damit muss auch die alte Resolverstruktur SLIST mehr als eine Art von Kandidateninformation tragen.

Aus einer Liste wird eine heterogene Menge

RFC 1034 beschreibt SLIST als Struktur für Nameserver und die Zone, die ein Resolver gerade abfragt. Der Entwurf präzisiert SLIST als Menge: Jeder einzelne Wert darf im Endergebnis nur einmal vorkommen. Zugleich muss die Struktur Delegationen aus NS-RRsets und solche aus Delegation-Type-RRsets aufnehmen können.

Das beseitigt exakte Wiederholungen, aber keine semantischen Schleifen. Zwei unterschiedliche Einträge können auf denselben Dienst führen. Ein Delegationsmechanismus kann Daten benötigen, die wiederum eine andere Delegation anstoßen. Falsch konfigurierte Informationen können eine Kette verlängern, ohne je denselben Wert in identischer Form zu wiederholen.

Deshalb verlangt der Text angemessene Grenzen gegen ausufernde Verarbeitung. Dazu gehören nicht nur eine maximale Zahl sichtbarer SLIST-Einträge, sondern auch Arbeit pro Auflösung, Abhängigkeitstiefe, erneute Bearbeitung logisch gleicher Ziele und Zeit. Ein Grenzwert ist Teil des Sicherheitsmodells, nicht bloß eine Optimierung.

Wird eine Grenze erreicht, sollte der Resolver den Abbruch als eigenen Zustand erfassen. Eine gekürzte Liste, die wie eine vollständig konstruierte aussieht, würde die Beweislage verändern. Der Betreiber müsste erkennen können, ob keine weiteren Kandidaten existierten oder ob das Budget endete.

Bevölkerung ist nicht Benutzung

Der Entwurf formuliert eine selten ausgesprochene Einschränkung: Weder RFC 1034 noch dieses Dokument definieren, wie ein Resolver SLIST benutzt. Sie definieren, wie die Struktur befüllt wird.

Damit ist ein Eintrag kein Verbindungsprotokoll. Er sagt, dass ein Kandidat die Konstruktionsregeln erfüllt hat. Er sagt nicht, dass der Resolver ihn ausgewählt, erreicht, über einen bestimmten Transport angesprochen oder von ihm eine gültige Antwort erhalten hat.

Diese Trennung ist für neue Delegation Types entscheidend. Ein NS-Omitting-Typ kann beispielsweise einen Server für verschlüsselten Transport beschreiben. Sein Auftauchen in SLIST beweist noch nicht, dass genau dieser Transport stattfand. Ein Bericht, der „Kandidat aus neuem Typ aufgenommen“ zu „verschlüsselte Auflösung genutzt“ verkürzt, macht aus Planungsdaten ein Ergebnis.

Ein brauchbarer Trace benötigt mindestens vier Phasen: Welche Delegationsdaten wurden authentisiert? Welche Kandidaten und Abhängigkeiten wurden daraus erzeugt? Welcher Kandidat wurde nach welcher Auswahlregel benutzt? Welcher Transport und welches Ergebnis wurden beobachtet? Jede Phase darf nur ihre eigene Aussage machen.

Der Nummernbereich steuert die Priorität

Der vorgeschlagene Bereich 0xF0000xF1FF wird in vier Segmente geteilt. 0xF0000xF07F enthält NS-Omitting-Typen, die ohne NS auskommen. 0xF0800xF0FF enthält NS-Preserving-Typen, die NS ergänzen. 0xF1000xF1EF ist für On-Demand-Daten bestimmt. 0xF1F00xF1FF ist Private Use mit NS-erhaltendem Verhalten.

Setzt ein Resolver in EDNS(0) das DE-Bit, nimmt der autoritative Server vorhandene NS-Omitting-, NS-Preserving- und Private-RRsets in die Referral auf. On-Demand-Typen fehlen ohne explizite Anfrage. Sobald ein NS-Omitting-Typ vorhanden ist, darf der Server kein NS-RRset mitsenden, unabhängig von anderen Typen und sogar bei QTYPE=NS.

Der Resolver verwendet bei NS-Omitting die neuen Daten und ignoriert mitgesendete NS-Daten vollständig. Ohne NS-Omitting bleibt NS maßgeblich, während die anderen Typen ergänzen. Der Codepunkt legt somit das generische Verhalten fest. Eine falsche Segmentzuweisung ist keine Registerkosmetik, sondern eine falsche Ausführungsanweisung für Implementierungen, die den konkreten Typ noch nicht kennen.

Für SLIST bedeutet das: Nicht jeder erreichbare Kandidat ist unter jeder Delegationspolitik zulässig. Der Algorithmus darf ein altes NS-Ziel nicht einfach hinzufügen, nur weil der neue Kandidat unbrauchbar ist. Auswahlmenge und Fallback-Regel sind gekoppelt.

Kein stiller Rückfall bei unbrauchbaren Daten

Ist bekannt, dass ein NS-Omitting-RRset existiert, sein Inhalt aber unbrauchbar, darf der Resolver nicht auf NS zurückfallen. Er behandelt die Situation so, als sei SLIST mit unerreichbaren Servern gefüllt. Das schützt vor einem stillen Wechsel zu klassischem, möglicherweise unverschlüsseltem Do53-Verkehr.

Für Ressourcensteuerung ist das kontraintuitiv. Ein Betreiber könnte nach aufwendiger Bearbeitung einer neuen Delegation einen leicht erreichbaren NS-Server sehen und ihn als kostengünstigen Ausweg wählen. Genau dieser Ausweg würde jedoch die zugesagte Sicherheitssemantik ändern. Kostenbegrenzung darf nicht zur versteckten Autorisierung eines schwächeren Pfades werden.

Andererseits darf Sicherheit auch keine unbegrenzte Suche rechtfertigen. Wenn zyklische oder tief verschachtelte Daten das Budget erschöpfen, ist ein sichtbarer, begründeter Fehler die korrekte Reaktion. Die Alternative wäre entweder Ressourcenverbrauch ohne Grenze oder ein unbemerkter Fallback.

DE handelt Fähigkeit aus, nicht Vollständigkeit

Der Entwurf beantragt EDNS(0)-Bit 2 für DE. Ein fähiger Resolver setzt es; ein fähiger rekursiver Resolver spiegelt es gegenüber einem fähigen Stub. Erhält der autoritative Server DE=0, verhält er sich kompatibel zum alten DNS und behandelt Delegation Types wie gewöhnliche Datentypen.

Ein Angreifer oder unfähiger Vermittler kann DE aus der Anfrage entfernen. Der Server liefert dann NS-only oder, wenn kein NS existiert, eine negative Antwort. Ebenso können neue RRsets aus einer Referral entfernt werden. Ein gespiegeltes DE-Bit an einer anderen Grenze beweist weder Vollständigkeit noch Authentizität der Delegationsdaten.

Das ist auch für Ressourcenauswertungen wichtig. Ein kleiner SLIST-Aufbau kann bedeuten, dass es tatsächlich wenige Kandidaten gab. Er kann aber ebenso bedeuten, dass die neue Information auf dem Weg entfernt wurde. Ohne Authentisierungsnachweis ist geringe Arbeit kein Beleg für eine einfache Delegation.

ADT macht fehlende Daten sichtbar

Als Gegenmaßnahme schlägt der Text DNSKEY-Bit 14 für ADT vor. Der validierende Resolver bestimmt ADT aus dem validierten DNSKEY-RRset der delegierenden Zone. Ist das Bit in mindestens einem Schlüssel gesetzt, muss die Referral NSEC- oder NSEC3-Nachweise über vorhandene oder fehlende Delegation Types am delegierten Namen enthalten.

Der Validator gleicht NS-Omitting-, NS-Preserving- und Private-RRsets mit den authentisierten Type Bit Maps ab. Fehlt ein nachgewiesener Typ in der Antwort, ist diese manipuliert und wird ignoriert. On-Demand-Typen dürfen im Bitmap stehen, ohne in einer gewöhnlichen Referral zu erscheinen.

Die Verpflichtung stammt aus dem zuvor validierten Schlüsselmaterial, nicht aus dem löschbaren DE-Bit der aktuellen Anfrage. Dadurch kann ein Validator sowohl das Entfernen neuer RRsets als auch DE-Stripping erkennen—aber nur bei signierter Zone, gesetztem ADT, aktiver DNSSEC-Validierung und durchgesetzter Prüfung.

Ist ADT nicht gesetzt, gilt die Konsistenzprüfung nicht. Eine positive DELEG-Antwort sollte nicht allein deswegen DNSSEC-bogus sein. „Nicht aus diesem Grund ungültig“ ist jedoch kein Nachweis gegen Downgrade.

Negative Antworten und Diagnose

Veröffentlicht ein Elternbereich nur Delegation Types und kein NS, erhält ein nicht fähiger Resolver bei DE=0 eine negative Antwort. Der Server sollte EDE 34, „New Delegation Only“, beifügen. Der Code erklärt die Inkompatibilität, erweitert aber die Fähigkeiten des Clients nicht.

Ein Angreifer kann DE entfernen, um diesen Fehler als Denial of Service auszulösen. Mit validiertem ADT muss die negative Antwort passende NSEC/NSEC3-Beweise enthalten. Bei Compact Denial of Existence reicht ein NXNAME-basiertes Ergebnis am angefragten Namen nicht, weil es die Typbits am Delegationspunkt verbirgt; erforderlich ist ein herkömmlicher Name-Error-Nachweis.

Auch hier sind Nachweis und Ergebnis getrennt. Die Manipulation zu erkennen und die Antwort abzulehnen ist korrekt, stellt aber keine Erreichbarkeit her. Ein sauber begrenzter SLIST-Abbruch kann aus demselben Grund sicher und zugleich servicewirksam sein.

Die kürzere Liste im Ausgangsfall war daher kein Entwarnungssignal. Sie zeigte nur, dass exakte Duplikate entfernt wurden. Solange Zyklen, Arbeitsbudget, Auswahl, Transport und Ergebnis nicht getrennt gemessen werden, bleibt offen, ob die Auflösung effizient, sicher oder überhaupt abgeschlossen war.

Quellen