Summary

  • GSS-TSIG uses TKEY to negotiate a GSS security context and TSIG to protect DNS messages, but RFC 3645 expressly leaves authorization outside its scope.
  • A defensible update record must separately prove the authenticated principal, applicable local policy, permitted action, accepted update, committed zone state and later DNS observation.

Imagine an incident review that begins with one line: “GSS-TSIG validation succeeded.” It is meaningful evidence. It can show that a message was checked under an established context and that its integrity survived the trip. It does not, by itself, show that the principal was entitled to replace an address record, that the primary server committed the change, or that a resolver later returned it.

RFC 3645 defines two distinct stages. First, client and server pass opaque GSS-API tokens in TKEY records while calling GSS_Init_sec_context and GSS_Accept_sec_context. The context moves from uninitialized to negotiating and finally established. Second, the established context feeds GSS_GetMIC and GSS_VerifyMIC; the resulting signatures travel in TSIG records on DNS messages. The plain-text edition makes the scope line impossible to miss: this is an authentication mechanism, not an authorization mechanism.

That distinction changes the audit question. Authentication asks which principal and context protected the request. Authorization asks whether that principal may perform this action on this owner name and record type, under the zone administrator's current policy. Execution asks what the server actually changed. Publication and observation ask where the new data propagated and what a later query saw. One successful check cannot serve as a receipt for all five.

The machinery is deliberately layered. RFC 2743 supplies the GSS-API abstraction. RFC 2930 supplies TKEY as the token and key-establishment vehicle. RFC 2845 supplied the original TSIG transaction-authentication framework; RFC 8945 later modernized and obsoleted it. RFC 4121 specifies the Kerberos v5 GSS mechanism used in contemporary interoperability. Each layer has a narrower job than the management claim “the DNS change was trusted.”

RFC 3645 also describes lifecycle, not a permanent badge. A unique context is maintained for the client-server relationship, identified through a key name, and has a finite lifetime. Negotiation may take several token exchanges; the specified loops limit attempts to ten. The client verifies the signed final response before advancing to the established state. When verification fails, the message is not authentic. When a context expires or fails, it must be replaced rather than treated as inherited authority.

The implementation profile matters, but it must not be overstated. The document encourages SPNEGO so peers can negotiate mechanisms and requires Kerberos v5 support for interoperability; it also permits other underlying mechanisms. Its security is only as effective as the chosen GSS mechanism. A dashboard that records merely “gss-tsig” suppresses evidence that an investigator may need: mechanism, target name, credential source, context handle, lifetime, replay and sequence state, key name, peer and verification result.

Authorization appears in a different document. RFC 3007 says secure dynamic-update policy is configured by the zone administrator and enforced by the server. Checks use the authenticated principal and desired action, and the safe default is no change unless policy grants it. RFC 2136 defines Dynamic Update prerequisites and operations. Together they show why a valid signature is an input to a policy decision, not the decision itself.

The result also needs its own proof. An update response may be accepted while a later operational problem affects persistence or propagation. Conversely, a DNS answer can be valid without proving which administrator initiated its history. RFC 4033 describes DNSSEC data-origin authentication and integrity for DNS data; it should not be confused with authenticating a live update transaction. Transaction, authorization, stored state and served answer occupy different reality layers.

Even registry evidence has a boundary. IANA's TSIG algorithm-name registry contains gss-tsig, while the wider DNS parameters registry coordinates protocol values under procedures discussed in RFC 6895. These records establish shared names. They do not attest that a particular context exists, a principal is authorized, or a requested mutation occurred.

The historical record is auditable through the RFC Editor metadata, IETF Datatracker entry, document history and errata search. That provenance bounds what the standard says; it should not be inflated into claims about current deployment or a named product.

Heng Lu's accounts of reality layers, minimum common specification and running-code primacy provide the institutional reading. GSS, TKEY, TSIG and registered names create a common technical floor. Local policy remains local. The running server and later observations determine whether the intended state exists. Coordination works because those layers connect; accountability fails when one layer claims the authority of all the others.