Summary

  • RFC 3008 made cryptographic validity only one part of DNSSEC acceptance: a data signature also needed the right fields and a matching zone key before a resolver treated it as material evidence.
  • Host and user keys retained a role in authenticating SIG(0) transactions, but the zone key signed the public data, separating permission to propose a change from authority to attest what the zone contained.

The signature could be perfectly calculated, within time and attached to the right bytes, yet still fail to count. That is the starting point of RFC 3008, published in November 2000 as Domain Name System Security (DNSSEC) Signing Authority. It did not invent a new signature algorithm. It revised the rule by which a resolver decided which verified signatures belonged to DNSSEC's public chain of evidence.

The distinction was expressed in the language of “material” and “immaterial” signatures. A data SIG normally covered an RRset and could demonstrate its origin and integrity. But a SIG might instead have an application-defined role, lack a relationship to an RRset, or protect a DNS message as SIG(0). Those signatures could be genuine without being material to DNSSEC validation. The binary cryptographic answer and the institutional answer—who may speak for zone data—were separate.

That separation corrected an ambiguity in RFC 2535. The earlier DNS security model allowed zone, host and user keys to sign data in some circumstances. One motivation was dynamic update: a host could sign the data it introduced while the zone's most sensitive private key stayed offline. The arrangement appeared to distribute signing authority and reduce exposure.

RFC 3008 argued that the promised offline boundary did not survive the whole system. Secure dynamic update still needed online zone signing for SOA and NXT sets, as the update path in RFC 3007 made clear. If an online zone key already had to exist and could sign incoming data, letting every host or user signature become material public evidence no longer bought the intended absence of an online zone key. It did, however, leave every resolver with a more complicated authority decision.

The revision therefore required data in a secure zone to be signed by a zone key under the standard policy. A resolver was to ignore non-zone keys for material data signatures unless explicit local policy said otherwise. The change was restrictive by design. It replaced a flexible signer graph with a baseline whose verification chain was bounded by the DNS name's label depth and whose authority could be read from the zone structure.

“Zone key” was not a ceremonial label that bypassed the rest of validation. RFC 3008 described a series of gates before a signature deserved further processing. For a data SIG, the type-covered field had to match the associated RRset. The algorithm had to be recognized and have a defined SIG data format. The labels count could not exceed the labels in the signature owner name. Original TTL could not be below the current SIG TTL because an intermediary was not allowed to increase it. The validation time had to sit between inception and expiration.

The signer name, key tag and algorithm then had to identify a candidate KEY. Without one, the signature was immaterial. If several keys matched those selectors, each remained a candidate until cryptographic verification identified the signer. The resolver could not infer authority from a successful calculation alone; it first constrained the set of keys whose success would matter.

The KEY record carried more gates. Its flags had to allow authentication. Its name type had to be zone for a material data SIG. Its protocol octet had to indicate DNSSEC or ALL, rather than a use unrelated to DNSSEC. Its algorithm had to match the SIG algorithm. A key could therefore possess the right public material and produce the right mathematics while being declared for the wrong protocol purpose or actor type.

This order matters. Verification answers whether the signature corresponds to the candidate key and covered input. Authorization answers whether that class of key may make this kind of DNSSEC statement. Chain validation answers whether the resolver has a trusted route to the relevant zone key. Even after those checks, the signed data may describe a service that is unavailable or a policy that is unwise. Cryptographic integrity does not make DNS content semantically true outside the signed statement.

RFC 3008 preserved a different lane for transaction security. A SIG with type covered zero protected a DNS message and was called SIG(0), as specified more fully in RFC 2931. Its signer did not need to be a zone key. A transaction is initiated by a user or a host; even a nameserver signs such a transaction as a host rather than as a zone. The expected key name types were therefore user or host/entity, and zone keys were discouraged from generating SIG(0).

That was not a contradiction. A host key could prove which principal sent an update request without gaining the right to publish host-signed RRsets as universally authoritative zone data. The primary server applied its local authorization policy to the authenticated principal under RFC 3007. If it accepted the change, the zone key signed the resulting public state. Proposal, admission and public attestation remained separate powers.

The distinction also prevented a resolver from importing a primary server's private access policy into the public wire format. RFC 3007 intentionally kept update permissions in local configuration: a principal could be limited by name and RR type, and the default was no change. RFC 3008 gave resolvers a standard public-data baseline without asking them to reconstruct every update decision that had preceded the RRset.

One conspicuous mechanism did not carry the new authority model. RFC 3008 assigned no values to the old KEY signatory field and required none. Fixed signatory bits had appeared to encode who could sign what, but they could not comfortably express changing policy. For update admission, policy lived at the primary. For public data validation, the standard zone-key rule narrowed the accepted class. The system used two explicit decision surfaces rather than pretending a few bits could represent both.

The document was still part of an early DNSSEC generation. RFC 3090 clarified how a zone's secure or unsecured status was determined in that model. RFC 3658 later introduced the DS record and updated the delegation side of the authority chain. The modern architecture in RFC 4033, RFC 4034 and RFC 4035 eventually obsoleted RFC 3008 along with RFC 2535's KEY and SIG framework.

That lifecycle limits the claim. RFC 3008 should not be presented as a current configuration manual, nor should its KEY flags be silently translated into modern DNSKEY and RRSIG fields. RFC 3130, a 2001 status-meeting report, is useful evidence that DNSSEC was then understood as a toolbox whose components were developing at different rates. It is not evidence that the RFC 3008 model was universally deployed or that its simplification produced a measured security improvement.

Its historical value is the authority test itself. The standard saw that a valid token can become dangerous when the verifier treats possession of the signing operation as a mandate to define public truth. It responded by narrowing the accepted role, bounding the chain and keeping transaction identity in a different lane from zone attestation.

Read through Lu Heng's Running-Code Primacy lens, authority appeared only when resolver code executed the complete classification and chain, not when a signature object merely existed. The minimum common layer was the zone-key baseline. Local policy could augment it, but that exception belonged to the resolver making the decision and did not rewrite the general rule for everyone else. Stability came from keeping the receipts distinct: covered data, field eligibility, candidate key, signer role, cryptographic result, chain and time window.

RFC 3008 therefore made a signature less magical and more accountable. A signer could prove possession of a key. A key record could declare a purpose. A zone position could confer a role. A resolver could validate a chain. None of these receipts substituted for all the others. The signature mattered only when the evidence and authority paths met at the same decision.

Sources