Summary

  • RFC 3445 restricted newly published DNS KEY records to DNSSEC protocol value 3 because queries could not select an internal subtype and signatures covered the entire RRset, coupling unrelated application keys to DNS infrastructure.
  • Its migration was deliberately asymmetric: authoritative writers stopped adding deprecated values, while readers retained them during validation so removing one record would not invalidate the signature or make caches disagree.

A universal drawer became one failure domain

The first ambition was easy to admire. RFC 2535 gave DNS a KEY resource record whose RDATA carried flags, a protocol octet, an algorithm and a public key. Protocol value 1 identified email, 2 IPsec, 3 DNSSEC and 4 TLS. Values 5 through 254 remained available, while 255 meant any protocol. One distributed naming system could become a convenient shelf for many public keys.

But DNS did not expose the shelf's internal labels to its query language. A client could ask for KEY; it could not ask the DNS server for only the email, IPsec or DNSSEC subtype. Every answer at that owner name therefore returned the whole KEY RRset. DNSSEC then signed the RRset as a set, not each purpose-defined subset. The container was plural in intended use but singular in retrieval and cryptographic scope.

RFC 3445, published in December 2002 by Donald Eastlake and Olafur Gudmundsson, described the consequences after limited experimental deployment. Its plain text, RFC Editor record, Datatracker file, history, references, later citations and errata search establish the documentary trail. They do not establish how many zones published mixed sets or which resolver behaved correctly.

The keys differed before any bit was examined

RFC 3445 listed six ways in which DNSSEC and application keys belonged to different operational worlds. They served different purposes. Different administrators could control them. Their authentication rules differed. Authoritative name servers had different reasons to include them in responses. Resolvers had to treat them differently. Their malfunction or compromise produced different consequences.

These were not metadata niceties. A DNSSEC key is essential to the integrity of DNS data. An application key has no inherent significance to DNS itself. Combining them made the RRset grow with every unrelated application, enlarged responses, synchronized otherwise independent rotation schedules and asked DNS administrators to carry material they might not control.

The dangerous error was semantic, not merely volumetric. Software that noticed a public key but failed to enforce the protocol field could mistake a compromised application key for a zone key. Cryptography cannot rescue a verifier that asks the wrong key to prove the wrong proposition. A well-formed record can still cross a trust boundary its consumer forgot to draw.

The repair closed the write path

RFC 3445 made protocol value 3 the only value for newly authoritative KEY data. It reserved every flag bit except the zone-key bit, bit 7. Values 1, 2, 4 and 255 became reserved, as did the once-open range for other applications. New protocol-octet assignments were closed except through Standards Action.

The narrowing preserved DNSSEC's zone and non-zone key distinction, including uses associated with transaction security in RFC 2930, RFC 2931 and secure dynamic update in RFC 3007. It did not preserve the older host-versus-user flag distinction, and it did not promise continued publication compatibility for application keys. Those applications needed a better-defined record or another mechanism.

This was architectural subtraction, not a claim that DNS must never publish application key material. RFC 3445 explicitly left other RR types open. Later records illustrate more specific containers: SSHFP for SSH host-key fingerprints, CERT for certificates, and TLSA for TLS associations. They are later context, not proof that one short RFC caused every subsequent design.

Readers could not simply throw history away

The most instructive rule faced the opposite direction. Writers were to stop creating non-3 KEY values, but readers were advised to accept those old records as members of an RRset. A resolver must not use them to authenticate DNS data. Yet it also should not remove them before checking the signature.

Why preserve something whose use has been deprecated? Because the signature covered the complete RRset. If a resolver silently discarded one application-key record and then verified a signature made over the original set, it would be verifying different bytes. The signature would fail. If some caches retained the record and others filtered it, the network could also maintain inconsistent versions of what was nominally the same signed set.

“Ignore for DNS authentication” and “erase before cryptographic validation” are therefore not synonyms. One is a decision about authority; the other mutates the evidence being checked. RFC 3445 separated semantic use from set preservation. That distinction remains a powerful migration pattern: stop producing an old form, continue parsing enough of it to validate and move safely, and refuse to grant it authority it no longer deserves.

DNSSEC later named the boundary more clearly

The 2005 DNSSEC specification family—RFC 4033, RFC 4034 and RFC 4035—obsoleted the RFC 2535 family and used the DNSKEY record. The name itself no longer advertised a universal key drawer. The current IANA DNS parameters show the resulting registry state.

That record can prove which symbolic values and policies are registered today. It cannot prove that legacy KEY data disappeared, that every parser applies protocol semantics, that caches converged, or that a particular key was trustworthy. A standards document proves a rule was written. A zone snapshot proves data was served at a moment. A packet capture proves a response crossed one observation point. A resolver test proves one implementation path. Security outcome requires still different evidence.

The smallest container that shares a trust model

Heng Lu's reality-layer discipline helps explain why the original design was seductive. Encoding, registry assignment, signature validity, administrative authority, deployment and safe outcome can all look like “the key is in DNS,” while remaining separate facts. Putting them in one record did not make their trust models converge.

Running-code primacy also matters. RFC 3445 did not reject experiment because the abstraction was untidy; it responded to problems found through limited deployment. Code revealed that query granularity, signing scope and operational ownership did not match the imagined universal container. The correct lesson is not that running code automatically governs, but that a clean model cannot overrule observed boundary costs.

The minimum-initial-specification principle suggests the positive design: standardize the narrow shared primitive whose participants actually share purpose and verification rules. Let voluntary application ecosystems choose purpose-specific records without conscripting DNSSEC's infrastructure key into their governance. This is an editorial interpretation, not evidence about the authors' personal intent.

RFC 3445's durable insight is smaller and sharper. A common wire shape is not a common trust domain. When a query, signature or cache forces unrelated objects to move as one set, the set boundary becomes a security and governance boundary whether the original format acknowledged it or not.

Sources