RFC 3090: One Zone, Two Security Answers

Summary

RFC 3090 replaced algorithm-by-algorithm and “experimentally secure” labels with three zone attributes: globally secured, locally secured and unsecured.
Those labels did not promise universal protection. A resolver still reached a binary judgment through its own trust anchors, supported algorithms, chosen validation path and view of the parent-child boundary.

Four observers could ask one question and mean different things

By March 2001, DNSSEC had a vocabulary problem as much as a cryptographic one. RFC 2535 described signed data and a chain of trust, but deployment was incomplete. Zones could sign records before their parents could connect them to the DNS root. Resolvers could be configured to trust an isolated zone directly. Algorithms could be understood by one implementation and not another. Saying that a zone was simply “secure” compressed all of those conditions into a word that sounded more absolute than the evidence allowed.

RFC 3090 began by separating the observers. A zone administrator needed to decide what data to publish. A secure dynamic-update server needed to know how to maintain the zone. A parent needed to state the status of its child. A resolver needed to decide whether an answer could be validated. Each was looking at a different control surface. Signing the contents was an action by the child; providing a delegation path was partly an action by the parent; accepting a trust root and an algorithm was an action by the resolver operator.

The memo therefore removed the older idea that one zone might have a different status for each algorithm. The zone would receive one administrative classification. It also deprecated “experimentally secure.” An experiment was not a fourth metaphysical state: to the resolvers configured with its key, the zone formed a locally secured island; to ordinary resolvers, it was unsecured.

An island existed only for resolvers that knew where to land

The Internet did not have to wait for an unbroken signed tree before testing DNSSEC. A run of signed zones below an unsecured parent could form an island of security. Its root key could be installed in selected resolvers as a trust anchor. Those resolvers could validate downward inside the island even though no trusted chain reached it from the DNS root.

That arrangement produced RFC 3090's most useful historical result: the same zone could be locally secured for one population and unsecured for another. Nothing in the authoritative zone files needed to change between the two queries. What differed was resolver state. One machine possessed a recognized starting key and an acceptable path; the other did not.

Even a resolver with several configured roots had to start at the right one. RFC 3090 defined the closest security root as the configured root with the greatest ordered match of rightmost labels to the queried name. A resolver that began at a more distant anchor could encounter a signed NULL key on the path and conclude that the descendant was insecure, overlooking a nearer configured island. Overlapping islands were therefore not merely a drawing on an architecture slide. They created a concrete configuration and implementation hazard.

This is why a captured signature is not the whole proof. The investigator also needs the resolver's anchor set, the name-selection logic that chose the starting point, algorithm support, the records actually retrieved, and the time at which policy was applied. A validation result is a statement about that assembled path, not an eternal property printed on the zone.

The parent could speak by publishing silence

The delegation boundary exposed another uncomfortable convention in the RFC 2535 generation. A secured parent had to distinguish a secured child from an unsecured one. Under the clarified rules, absence of a child KEY at the parent could indicate that the child was secured, while an explicitly signed NULL key indicated an unsecured child.

RFC 3090 called this counterintuitive. Operators normally expect a positive security claim to leave positive evidence. Here, the secured case could be represented by silence, and the insecure case by a signed object. The document did not redesign the protocol; it warned implementers how to interpret the inherited mechanism and acknowledged the operational discomfort.

Absence therefore cannot be treated as generic proof. It has meaning only inside a particular protocol generation, at a particular authenticated point in a particular path. A packet capture that lacks a KEY record does not independently prove a secured child. One must first establish that the parent was itself secured, that the relevant records and negative evidence were obtained, and that the historical rules applied.

Later DNSSEC changed this bridge. RFC 3658 introduced DS, and RFCs 4033, 4034 and 4035 replaced the older KEY, SIG and NXT architecture with DNSKEY, RRSIG, NSEC and DS. Those later terms make the modern trust chain easier to recognize, but they must not be projected backward as if RFC 3090 had already specified them.

“Global” described a path, not a certificate of safety

RFC 3090 defined a globally secured zone under demanding conditions: mandatory algorithms, an on-tree parent-signature chain, appropriate apex zone-signing KEY material, NXT coverage and signatures over qualifying record sets. A locally secured zone could rely on other algorithms or an off-tree, preconfigured validation route while retaining the required signed-zone properties. Anything outside those classes was unsecured.

Yet the document explicitly said “global” and “local” were attributes, not declarations of standards compliance. A restrictive resolver might accept only globally secured zones. A more capable or specially configured resolver might validate locally secured ones. At the moment of use, each resolver still produced a binary answer: secured or unsecured.

Nor could the strongest label guarantee correct operation. Standards compliance could not be forced. A broken resolver might accept bad data. A compromised or nonconforming parent could interrupt an otherwise careful child. The status vocabulary organized responsibility and evidence; it did not abolish adversaries or implementation failure.

That restraint is the enduring lesson. DNSSEC security is assembled across administrative boundaries. The child controls signed content, the parent controls part of the delegation statement, the resolver operator controls anchors and acceptable algorithms, and the protocol defines how those facts compose. No single participant can convert its own correct act into universal trust.

The Same Zone Was Secure Here and Unsecured Elsewhere: RFC 3090

Why it matters

Summary

Four observers could ask one question and mean different things

An island existed only for resolvers that knew where to land

The parent could speak by publishing silence

“Global” described a path, not a certificate of safety

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing