Zusammenfassung

  • GSS-TSIG handelt über TKEY einen GSS-Kontext aus und schützt DNS-Nachrichten mit TSIG; über Änderungsrechte an der Zone entscheidet es nicht.
  • Ein belastbarer Prüfpfad muss Identität, lokale Regel, erlaubte Aktion, tatsächliche Mutation, Verteilung und spätere Abfrage getrennt belegen.

Der erste Prüfbeleg lautet oft: „Signaturprüfung erfolgreich.“ Er ist wichtig, beantwortet aber nur eine begrenzte Frage. Er sagt nicht automatisch, ob der authentisierte Principal diesen Namen und Record-Typ ändern durfte, ob der Primary die Operation speicherte oder ob eine spätere Abfrage den neuen Zustand zeigte.

RFC 3645 beschreibt zwei Phasen. Zunächst transportieren TKEY-Records opake GSS-API-Token zwischen Client und Server; GSS_Init_sec_context und GSS_Accept_sec_context führen vom uninitialisierten über den verhandelnden zum etablierten Kontext. Danach erzeugen und prüfen GSS_GetMIC und GSS_VerifyMIC Signaturen, die in TSIG-Records stehen. Die Textfassung setzt die Grenze ausdrücklich: Authentisierung ja, Autorisierung nein.

Für die Kontrolle entstehen damit mehrere Übergaben. Authentisierung ordnet die Nachricht einem Principal und Kontext zu. Autorisierung vergleicht Principal, gewünschte Operation, Eigentümername und Typ mit der lokalen Richtlinie. Protokollannahme, Datenbankänderung, Replikation und spätere Beobachtung sind weitere Zustände. Wer sie unter einem einzigen Erfolgscode zusammenfasst, kann den entscheidenden Fehlerort nicht mehr benennen.

Auch die Bausteine haben eng begrenzte Aufgaben. RFC 2743 definiert die GSS-API-Abstraktion, RFC 2930 TKEY als Transport für Schlüsselaufbau, RFC 2845 das ursprüngliche TSIG-Verfahren und RFC 8945 dessen modernisierte Fassung. RFC 4121 beschreibt den Kerberos-v5-GSS-Mechanismus. Gemeinsam ermöglichen sie Interoperabilität; keine dieser Schichten vergibt Zonenrechte.

Ein Kontext ist zudem ein befristeter Zustand. RFC 3645 verlangt einen eigenen Kontext für die jeweilige Client-Server-Beziehung. Die Verhandlung kann je nach Mechanismus mehrere Token-Runden benötigen; die beschriebenen Schleifen begrenzen die Versuche auf zehn. Erst nach Prüfung der signierten Schlussantwort darf der Client den Kontext als etabliert markieren. Ablauf und Fehler erfordern einen neuen Nachweis, keine stillschweigende Verlängerung früheren Vertrauens.

Das Interoperabilitätsprofil empfiehlt SPNEGO und verlangt Kerberos-v5-Unterstützung, lässt aber weitere Mechanismen zu. Der Schutz ist nur so gut wie der tatsächlich gewählte GSS-Mechanismus. Ein Logeintrag gss-tsig allein unterschlägt deshalb Mechanismus, Zielname, Herkunft der Credentials, Schlüsselname, Kontextlaufzeit, Replay- und Sequenzstatus, Peer sowie Prüfergebnis.

Die Berechtigungslogik steht in RFC 3007: Der Zonenadministrator konfiguriert die Richtlinie, der Server setzt sie um, und die Prüfung richtet sich nach Principal und gewünschter Aktion. Ohne ausdrückliche Freigabe gilt keine Änderungserlaubnis. RFC 2136 definiert Voraussetzungen und Operationen für Dynamic Update. Der authentisierte Principal ist folglich ein Eingangswert der Entscheidung, nicht ihr Ergebnis.

Auch Datensicherheit und Transaktionssicherheit dürfen nicht verschmelzen. RFC 4033 beschreibt Herkunftsauthentisierung und Integrität von DNSSEC-Daten. Eine validierte DNSSEC-Antwort rekonstruiert nicht die frühere Update-Berechtigung. Umgekehrt beweist eine authentisierte Update-Anfrage noch keine dauerhafte oder überall sichtbare Änderung.

Das IANA-Register der TSIG-Algorithmen koordiniert gss-tsig; das DNS-Parameterregister koordiniert weitere Werte nach Verfahren, die unter anderem RFC 6895 behandelt. Registereinträge belegen gemeinsame Namen, nicht einen aktiven Kontext, eine lokale Freigabe oder eine ausgeführte Änderung.

Der historische Umfang lässt sich über die RFC-Editor-Metadaten, den Datatracker-Eintrag, die Dokumenthistorie und die Errata-Suche prüfen. Daraus folgen keine Aussagen über heutige Verbreitung oder das Verhalten eines bestimmten Produkts.

Heng Lus Texte über Realitätsebenen, minimale gemeinsame Spezifikation und Vorrang des laufenden Codes liefern die institutionelle Folgerung. Der Standard schafft einen gemeinsamen technischen Boden. Die lokale Organisation erteilt Rechte. Laufende Systeme und spätere Messungen zeigen den Zustand. Wer diese Ebenen verschmilzt, macht aus einem begrenzten Beleg eine unbegründete Autorität.