Zusammenfassung

  • draft-hardaker-dnsop-nothing-new-00 schlägt vor, TC mit einem NN-Signal und einem LARGE RR samt 16-Bit-Kennung zu verbinden, damit ein Resolver einen scheinbar unveränderten großen RRset nicht erneut übertragen muss.
  • Der Text ist ein individueller, ausdrücklich unvollständiger und nicht implementierbarer Internet-Draft. Datatracker nennt weder Stream noch vorgesehenen RFC-Status; der Dokumentkopf sagt Standards Track.
  • Der Entwurf warnt davor, die SOA-Seriennummer pauschal als LARGE-Kennung zu verwenden. Zonengeneration und Generation eines einzelnen RRsets sind unterschiedliche Kontrollflächen.
  • Belastbarer Betrieb bindet die kurze Kennung an Objekt-Hash, Erzeugungsprofil, Authority, View, Signaturfenster und Cache-Linie und trennt diese Belege von Transport- und Anwendungsergebnis.

Ein gemeinsamer Zähler beantwortet die falsche Frage

Große DNS-Antworten können den verfügbaren UDP-Rahmen überschreiten. TC führt dann typischerweise zu einem vollständigen Abruf über zuverlässigen Transport. Künftige Post-Quanten-Schlüssel und -Signaturen könnten den Größendruck erhöhen; Revision 00 liefert jedoch keine Messung oder Deployment-Aussage.

Der Vorschlag will wiederholte Übertragung desselben großen Objekts vermeiden. Ein autoritativer Server würde neben TC das NN-Signal setzen und melden, dass sich der angefragte Datensatz kürzlich nicht geändert habe. LARGE liefert eine kompakte Kennung. Passt sie zum Cache, kann der Resolver auf den Vollabruf verzichten.

Die Kennung muss aber das Objekt zählen, über das entschieden wird. Eine SOA-Seriennummer beschreibt eine Zonengeneration. In einer dynamischen Zone kann sie häufig steigen, während ein großer DNSKEY-RRset unverändert bleibt. Umgekehrt darf ein stabil wirkendes Zonensignal eine relevante Objektänderung nicht verdecken.

Wer einen einzigen Zähler für mehrere Oberflächen verwendet, gibt dem Zählerproduzenten die Macht zu definieren, was als Änderung gilt. Technische Bequemlichkeit wird so zu einer stillen Governance-Entscheidung.

16 Bit brauchen ein Erzeugungsprofil

LARGE sieht eine 16-Bit-Kennung vor. Ihre Einmaligkeit ist nur innerhalb der Signaturlaufzeit der dargestellten Daten gefordert. Sie ist keine globale, dauerhafte Versionsnummer.

Der Entwurf nennt Hashes, inkrementelle Zähler, sorgfältig konstruierte Zeitwerte oder aus dem Inhalt abgeleitete Werte. Jede Variante besitzt andere Voraussetzungen. Ein gekürzter Hash kann kollidieren. Ein Zähler braucht persistente Zustände und Koordination. Ein Zeitwert braucht Auflösung und Neustartregeln. Eine Inhaltsableitung braucht kanonische Darstellung.

Gleiche Zahlen stützen Objektgleichheit nur bei gleichem Namen, Typ, Klasse, View, Verfahren und Nichtwiederverwendungsfenster. Ein Backup-Restore, Zählerneustart oder vermischte Views können denselben Kurzbezeichner zwei Objekten zuordnen.

Die Mindestaufzeichnung verknüpft daher Kennung, vollständigen RRset-Hash, ausstellende Authority, Profil, RRSIG-Beginn und -Ende sowie die konkrete Cache-Linie. Die kurze Zahl spart Bytes; der vollständige Verbund trägt die Beweislast.

Eine Authority ist kein Konvergenznachweis

Primärserver, Secondaries und Anycast-Instanzen können während Transfer, Laden oder Teilausfall verschiedene Generationen liefern. NN ist die Aussage des erreichten Servers, nicht die Abstimmung des Sets.

Hat der Cache Generation A, Server A ebenfalls A und Server B schon B, kann A ehrlich NN liefern und trotzdem nicht den aktuellen Betreiberwillen oder Konvergenz belegen.

Sensible Übergänge brauchen einen Nenner. Welche Authorities gehören zur Beobachtung, von welchen Standorten und mit welcher Abschlussregel? Eine Anycast-Adresse listet ihre Instanzen nicht auf. Wiederholungen über denselben Pfad sind keine weltweite Stichprobe.

Im Routinebetrieb kann eine Policy eine Beobachtung akzeptieren. Bei DNSKEY-Rollover, Delegationswechsel oder Recovery kann sie mehrere Authorities, Vollabruf oder manuellen Hold fordern. Das Risiko muss sichtbar bleiben.

Gültige Signatur bedeutet nicht gegenwärtige Absicht

DNSSEC bindet einen bestimmten RRset an eine Kette und ein Zeitfenster. Eine noch gültige RRSIG belegt kryptografische Prüfbarkeit. Sie belegt nicht, dass der Betreiber keinen Ersatz beabsichtigt, alle Authorities den Ersatz geladen haben oder der Resolver die richtige Cache-Linie gewählt hat.

Eine alte Generation kann noch verifizieren, während die neue bereits teilweise veröffentlicht wird. signature_valid darf deshalb nicht automatisch zu current werden.

Revision 00 verschärft die Grenze: Passt die Signatur von LARGE in die Antwort, muss sie enthalten sein; passt sie nicht, soll LARGE dennoch unsigniert gesendet werden. Eine nicht authentisierte kleine Information kann somit entscheiden, ob die signierte große Information beschafft wird.

Die Security Considerations vergleichen Angreiferfähigkeiten: Wer NN fälschen kann, könnte Pakete verwerfen und später stale Nutzung auslösen. NN kann denselben Zustand schneller erreichen. Das ist keine Authentisierung und kein Beweis, dass Beschleunigung folgenlos bleibt.

TC ist kein Urteil über TCP

TC sagt, dass die vorliegende Antwort abgeschnitten wurde. Es sagt nicht, TCP sei nicht verfügbar, ein vollständiger Abruf sei wertlos oder die ausgelassenen Daten seien identisch. RFC 7766 hält TCP im Vertrag vollständiger DNS-Implementierungen.

Der Resolver trifft eine Policy-Entscheidung. Die Aufzeichnung sollte Fähigkeit, TC/NN, Kennung, Authentisierung, Cache-Hash, Risikoklasse, stale-Regel und Transportalternative enthalten. Das Ergebnis heißt „Abruf unter P unterdrückt“, nicht „Frische bewiesen“.

Tests sollten TCP funktionsfähig lassen und dennoch Kennungen wiederverwenden, Authorities aufteilen, Signaturen ablaufen lassen oder NN fälschen. Die Implementierung soll ihre erklärte Policy befolgen und Unknown erhalten, statt jeden Fall grün zu färben.

Bei irreversiblen Aktionen ist der Schwellenwert höher. Einen alten Schlüssel, Nameserver oder Pfad nach einem kleinen Hinweis zu entfernen kann den letzten kohärenten Zustand beseitigen. Die Einsparung darf nicht die erforderliche Abschlussquittung ersetzen.

Stale und current sind verschiedene Verträge

RFC 8767 erlaubt begrenztes Serving Stale, wenn Aktualisierung scheitert. Das ist eine Kontinuitätsregel und keine Umbenennung alter Daten in aktuelle.

Timeout und NN können zu denselben Cache-Bytes führen, dokumentieren aber verschiedene Ereignisse. Timeout belegt den fehlgeschlagenen Refresh; NN belegt die Behauptung eines Servers, Refresh sei unnötig. Alarmierung, Eskalation und Vertrauen unterscheiden sich.

Nützliche Zustände sind TTL-valid, signaturvalid, nach authentisiertem NN behalten, nach unauthentisiertem NN behalten, nach Fehler stale bedient und zuverlässig neu abgerufen. Eine Cache-Hit-Quote verwischt die Ursache.

Auch Anwendungserfolg ist keine Freshness-Bestätigung. Ein Dienst kann mit alten Daten funktionieren oder trotz korrektem DNS scheitern. Ergebnis und DNS-Beleg dürfen einander nicht überschreiben.

Der Dokumentstatus begrenzt die Aussage

Beim Freeze war Revision 00 ein aktiver individueller Internet-Draft. Datatracker weist auf fehlende formale IETF-Billigung hin. Stream, verantwortlicher AD, Telechat und vorgesehener RFC-Status fehlten; der Header sagte Standards Track.

Der Text nennt sich sehr unfertig, unvollständig und nicht implementierbar. IANA steht auf TBD. Der DNSSEC-Teil verweist auf ungeschriebene Ideen; Format, Platzierung und Resolver-zum-Parent-Signal sind Diskussion.

Daraus folgen keine finale Zuweisung, Implementierung, Interoperabilität, PQC-Einführung, gemessene Einsparung oder Störung. Analysierbar ist die Beweisgrenze einer möglichen künftigen Optimierung.

Ein Quittungsgraph hält Objekt und Zone auseinander

Der Graph beginnt mit Query und Cache-Generation. Er ergänzt Authority, View, TC/NN, LARGE, Authentisierung und Erzeugungsprofil. Der Vergleich verbindet Kurzkennung, Vollhash, Signaturfenster und Epoche. Die Policy begründet Abruf oder Unterdrückung.

Transport, Cache-Zulassung, Client-Antwort und Anwendung folgen als eigene Knoten. Kein späteres Ergebnis schreibt die frühere Aussage um.

Eine belastbare Aussage lautet: „Authority X meldete NN zu T; Kennung Y entsprach RRset-Hash Z mit Signatur bis E; Policy P unterdrückte einen Abruf.“ Sie ist enger als „DNS war aktuell“ und operativ stärker.

Leadership muss entscheiden, wann ein günstiger Hinweis teurere Evidenz ersetzen darf. Effizienz ist legitim. Bei Vertrauenswechseln ist stärkere Beobachtung ebenso legitim. Eine Zonennummer darf nicht stillschweigend zur Wahrheit jedes Objekts werden.

Quellen