Summary

  • RFC 2065 attached authentication evidence to DNS resource records, so a resolver could judge signed data without treating every server on the delivery path as a trusted security authority.
  • Compatibility was useful but bounded: an ordinary server could store and return KEY, SIG and NXT records, while automatic signature delivery, CNAME handling, authenticated status and cryptographic validation required additional capability.
  • The protocol deliberately protected public data integrity and origin, not query confidentiality, differentiated access or the security of the host reached after resolution.

Imagine a resolver asking for an address and receiving the reply from a caching server that cannot validate a signature. In an older trust model, the server’s position in the delivery chain can look like the reason to believe the answer. RFC 2065 offered a different arrangement. The server could carry the answer and its cryptographic evidence; a security-aware resolver could decide whether the signed records were genuine and sufficiently current.

That separation was the document’s most durable idea. The zone authentication key belonged to the zone, RFC 2065 said, not to the servers holding copies. Compromising one server—or even every server for a zone—therefore did not necessarily eliminate a resolver’s ability to detect counterfeit data. A compromised carrier could still omit, replay or disrupt. It did not automatically acquire the private key needed to produce a fresh valid signature.

Three services, not one security halo

RFC 2065 divided its work into public-key distribution, data-origin authentication and optional transaction or request authentication. The distinctions matter because a successful DNS exchange did not prove all three.

The KEY resource record associated public keys with DNS names. A resolver needed at least one starting key obtained through a trustworthy configuration path. From that anchor it could authenticate signed keys across secure zones. The mechanism did not abolish trust; it made the starting point and the chain inspectable.

The SIG record was the core evidence for DNS data. It identified the covered RR type, signer, algorithm, original TTL, signature inception and expiration, and carried the signature itself. A valid SIG could support a claim about the origin and integrity of an RRset during a bounded interval. It could not turn unrelated records in the same packet into authenticated data.

The NXT record addressed a different problem: proving that a name, or a type at an existing name, did not exist. That design later changed, but in 1997 it showed the same discipline. Positive data and authenticated absence needed different evidence. Silence was not a signed denial.

Optional transaction signatures covered still another surface. RFC 2065 warned that a transaction-authentication SIG did not authenticate the resource records merely because they travelled in that message. Zone signatures, anchored through configured or previously authenticated keys, remained the evidence for RRsets.

An ordinary server could be a useful carrier

RFC 2065 did not require a new transport protocol for data-origin authentication. It added resource-record types to the existing DNS format. An implementation that could store and retrieve the new types could provide a compatibility path even if it did not understand how to validate them.

The cost appeared in retrieval. A security-aware server could include the relevant signatures automatically. A non-aware server might return only what was explicitly requested, forcing the resolver to fetch all SIG records at the name and select those covering the desired RRset. More round trips bought migration without assigning false authority to old software.

This was not universal transparency. CNAME processing was a named exception because old server behaviour could follow the alias before returning the security records at the original name. RFC 2065 also defined minimal and full server conformance. Minimal compliance meant storing and retrieving KEY, SIG and NXT, including through zone transfer. Full compliance added correct construction, automatic inclusion, alias handling, delegation logic and the AD and CD bits.

The two header bits made responsibility visible. AD indicated that the answering server had verified the included data. CD told a security-aware server that the querying resolver would accept data before upstream checking because it intended to perform the cryptography itself. Old implementations left both bits zero. Zero was compatible transport state, not an authenticated verdict.

Time prevented a signature from becoming a permanent licence

DNS caches reduce TTL as time passes, but changing a signed value would invalidate the signature. RFC 2065 solved the tension by signing an original TTL and carrying signature inception and expiration times. A resolver could reduce its working TTL, but it could not extend it above the signed original. Nor could it treat an expired signature as proof merely because the cached record still existed.

The arrangement created a control surface with several owners. The signer controlled key custody and the signed validity interval. Authoritative and caching servers controlled availability and transport. The resolver controlled trust anchors, validation, local time and cache acceptance. No single successful response collapsed those duties into one green status.

Clock security was consequently part of validation. Turning a resolver’s clock backwards could make old signatures appear current. RFC 2065 pointed to secure time as an operational dependency, not as something a DNS signature itself could guarantee.

Public authenticity was a deliberate boundary

The document stated its non-goals unusually plainly. DNS data was treated as public and DNS was expected to give the same answers to all inquirers. RFC 2065 added no access-control list and no mechanism for giving different requesters different rights. It also made no attempt to conceal queries or responses; confidentiality belonged to a separate channel mechanism such as the IPsec architecture then being developed.

Even perfect validation stopped at the DNS record. A trustworthy address answer did not prove that the machine currently using that address was authorized, and it did not prevent interception or forged traffic beyond DNS. The signature narrowed one uncertainty. It did not wrap the whole application path in trust.

A first specification, not the final DNSSEC

RFC 2065 was a Proposed Standard, not evidence of universal deployment. The IETF Datatracker preserves draft revisions from 1994 to 1996 and the January 1997 publication, but it does not establish how many operators used the design. RFC 2535 replaced it in March 1999 and explicitly said the revision incorporated early implementation experience and requests from potential users. RFCs 4033, 4034 and 4035 later replaced that generation in 2005.

The succession is evidence of engineering, not failure by embarrassment. Names, formats and delegation mechanics evolved. The responsibility split remained recognisable: signed data carries origin and integrity evidence; validators apply trust anchors and local policy; transport intermediaries do not become security authorities merely by relaying packets; confidentiality remains separate.

Read through the later lens of Heng Lu’s Minimum Initial Specification, RFC 2065 is useful because it concentrated shared security in locally testable objects while permitting uneven adoption at the edges. That comparison is an editorial interpretation, not proof of Eastlake and Kaufman’s institutional intent. Its value is practical: a common layer can specify exactly what makes a signature valid without authorising every carrier to decide what everyone must believe.

Sources