Zusammenfassung

  • ZONEVERSION liefert die Versionskennung in genau der autoritativen Antwort, die sie beschreibt, statt sie später aus einer zeitlich getrennten SOA-Abfrage zu erraten.
  • Der Wert belegt eine beobachtete Antwort, nicht den korrekten Inhalt der ganzen Zone, nicht die Konvergenz aller Instanzen und ohne Zusatzschutz auch nicht die Integrität der EDNS-Daten.

Der irreführende Teil ist der Erfolgscode. Zwei Messpunkte fragen denselben Namen an derselben Anycast-Adresse ab. Beide erhalten NOERROR. Eine Antwort enthält die neue Adresse, die andere noch die alte. Die ZONEVERSION-Option nennt SOA-SERIAL 4120 beziehungsweise 4119.

Eine nachträgliche SOA-Abfrage kann den Zusammenhang nicht retten. Die Route kann inzwischen auf einen aktualisierten Standort zeigen oder der verzögerte Knoten kann nachgeladen haben. Zwei spätere Werte 4120 beweisen dann nichts über die Version, aus der die alte Antwort tatsächlich entstand.

Das ist ein illustratives Szenario, kein gemeldeter Ausfall. RFC 9660 hält Antwort und Version im selben Austausch zusammen. 4119 erklärt jedoch nicht die Ursache, 4120 garantiert nicht die Richtigkeit der Daten, und eine Probe repräsentiert keine Flotte.

Die Anfrage enthält keinen Versionswunsch

Der Request trägt EDNS-Optionscode 19 im OPT-Pseudo-RR. OPTION-LENGTH ist null; Daten folgen nicht. Der Client verlangt weder Version 4120 noch einen Wechsel. Er fragt, welche Version der Server für die aktuelle Antwort verwendet hat.

Eine von null verschiedene Länge oder mehrere ZONEVERSION-Optionen machen den Request ungültig. Ein implementierender autoritativer Server antwortet FORMERR. Das ist zunächst ein Messfehler, kein Zonenbefund. Die Originalbytes der Anfrage gehören deshalb in die Beweiskette.

Auch eine gültige Frage erzwingt keine Option. Der Server muss sie verstehen, für eine einschlägige umschließende Zone autoritativ sein und die Anfrage bedienen wollen. Fehlt der Wert, ist nur die Korrelation in diesem Austausch nicht verfügbar.

Die Option ist hop-by-hop. Ein Forwarder darf den Upstream-Wert nicht blind in eine von ihm erzeugte Antwort übernehmen. Sonst löst er genau die Beziehung zwischen Produzent, Antwort und Version auf, die das Verfahren erhalten soll.

LABELCOUNT ordnet die Zahl einer Zone zu

Die Response-Daten beginnen mit einem Oktett LABELCOUNT, einem Oktett TYPE und dem typspezifischen VERSION-Wert. LABELCOUNT zählt vom rechten Rand des ursprünglichen QNAME und bezeichnet so die umschließende Zone; null steht für die Root-Zone.

Bei host.branch.example meint zwei branch.example, eins dagegen example. Der Wert darf die Labelzahl des QNAME nicht überschreiten. Wer nur „Serial 4120“ speichert, aber Frage und Labelcount verwirft, verliert den Geltungsbereich.

Auch ein Downward Referral kann die Version der übergeordneten Zone tragen. Autoritative NXDOMAIN- oder NODATA-Antworten und bestimmte SERVFAIL-Fälle können die relevante Zone benennen. Mehrere Zonen oder TYPEs sind möglich, jedoch höchstens ein Wert je TYPE-LABELCOUNT-Paar.

Die Telemetrie braucht daher QNAME, abgeleitete Zone, TYPE und VERSION gemeinsam mit Paket, Server, Messpunkt und Zeit.

SOA-SERIAL ist weder lineare Uhr noch Inhaltsdigest

TYPE 0 SOA-SERIAL ist der öffentlich definierte Typ in RFC 9660. VERSION kopiert die vier Oktette des SOA-SERIAL; zusammen mit den ersten Feldern beträgt die Optionslänge sechs.

Die Zahl gilt innerhalb ihrer Zone. RFC 1982 definiert eine zirkuläre 32-Bit-Arithmetik. Nach dem Umlauf kann ein numerisch kleinerer Wert neuer sein; für bestimmte Paare ist die Ordnung undefiniert. Ein gewöhnlicher Integervergleich erzeugt falsche Rollback-Alarme.

Der Serial ist auch kein Hash. Ein Betriebsfehler kann verschiedene Inhalte unter derselben Nummer verbreiten. Abfragekontext oder Policy können Antworten innerhalb einer Version verändern. RRsets, Abschnitte, Flags, TTL und DNSSEC-Ergebnis müssen neben dem Token verglichen werden.

Für die Prüfung des gesamten Zoneninhalts dient ZONEMD nach RFC 8976. ZONEVERSION ordnet einer Antwort eine Kennung zu; ZONEMD prüft einen zonenweiten Digest. Beide Aussagen bleiben getrennt.

Anycast macht aus „dem Server“ eine Stichprobe

Eine Anycast-Adresse kann je nach Quelle und Zeitpunkt zu verschiedenen Instanzen führen. Eine erfolgreiche Antwort belegt nur einen erreichten Pfad in einem Moment.

Vor der Diagnose steht das Inventar aus NS-Namen, Adressen, Anycast-Präfixen, Servicekohorten und Messstandorten. Jede direkte Anfrage deaktiviert Rekursion und bewahrt Quelle, Ziel, Transport, Zeit, QNAME, RCODE, AA, Paketbytes, TTL, Option und Validierungsresultat. Wiederholungen trennen einen flüchtigen Routenwechsel von einer beständigen Standortabweichung.

NSID kann eine Instanz zusätzlich kennzeichnen. Bedeutung und Eindeutigkeit legt jedoch der Betreiber fest. Die bloße Anwesenheit authentisiert nichts und ersetzt weder Endpunkt noch Messort.

Wenn drei Standorte dauerhaft 4120 und identische Daten sehen, ein vierter dagegen 4119 und die alte Adresse, ist eine begrenzte Divergenz belegt. Für die Ursache braucht es Transferjournal, Signergeneration, geladenen Stand und die Zuordnung von Route zu Standort.

DNSSEC signiert die ZONEVERSION-Bytes nicht

DNSSEC kann signierte RRsets validieren. Die EDNS-Bytes der Option liegen außerhalb der RRSIG-Abdeckung. Auf einem ungeschützten Pfad kann ein Vermittler den Token ändern oder entfernen, während die signierten Daten weiter validieren.

„RRset gültig“ und „Antwort-Version-Paar geschützt“ sind getrennte Befunde. Authentisierter und verschlüsselter Transport, TSIG oder SIG(0) können den Austausch unter ihren Schlüsselannahmen schützen. Endpunkt beziehungsweise Schlüssel und Ergebnis müssen dokumentiert werden. Korrekte Zoneninhalte oder Flottenkonvergenz beweisen sie nicht.

OPT ist kein Zonendatensatz. ZONEVERSION darf nicht wie ein RR gecacht, übertragen oder einer späteren Antwort angeheftet werden.

Quellen