DNS Security (DNSSEC) Experiments
Extracted elements (15)
The methodology precludes any zone from being simultaneously in an experiment and in a classic DNSSEC island of security — a zone is either exclusively experimental or it is not, preventing hybrid validation states.
The methodology uses unknown algorithm identifiers in DS records to hide experimental DNSSEC changes from standard security-aware resolvers. Because RFC 4035 requires validators to treat zones with only unknown DS algorithms as unsigned (rather than bogus), experiments can run on real public zones without breaking standard DNSSEC resolution.
If an unaware validator does not correctly follow RFC 4035 rules (e.g., it interprets a DNSSEC record before validating it), or if the experiment modifies more than just DNSSEC semantics, the experiment may not be sufficiently masked and may cause unintended resolution failures.
Security-aware resolvers that are unaware of the experiment will not be able to build a chain of trust through an experimental zone; they will treat it as unsigned.
A DNSSEC experiment MUST define the particular set of (previously unknown) algorithm identifiers that identify the experiment and define what each unknown algorithm identifier means.
For non-backwards-compatible changes becoming standards, resolvers MAY recognize the protocol change in zones not signed (or not solely signed) using the new algorithm identifiers.
For non-backwards-compatible DNSSEC protocol changes that become standards, the protocol change SHOULD use public IANA-allocated algorithm identifiers instead of private algorithm identifiers.
It is RECOMMENDED that for a particular DNSSEC experiment, a particular domain name base is chosen for all new algorithms, then the algorithm number or name is prepended to it (e.g., '3.dnssec-experiment-a.example.com').
It is RECOMMENDED that private algorithm numbers be used for experiments (per RFC 4034 Appendix A.1.1), rather than inventing entirely new signing algorithms; instead, alternate algorithm identifiers should alias existing known algorithms.
Resolvers MUST only recognize the experiment's semantics when present in a zone signed by one or more of the experiment's algorithm identifiers, in order to isolate semantics of one experiment from others.
The DNS name chosen as the algorithm identifier base for an experiment SHOULD be under the control of the authors of the experiment.
An experiment may use a DNS name as the algorithm identifier base, the OID private algorithm space (algorithm number 254), or non-private algorithm numbers requiring IANA allocation.
The experiment methodology creates two classes of security-aware servers and resolvers: those aware of the experiment (recognizing its algorithm identifiers and semantics), and those unaware of it. An unaware validator treats the experimental zone as unsigned.
Environments configured to trust both experimental and non-experimental zones risk cross-contamination: a more vulnerable experimental zone could be exploited to promote trust in zones outside the experiment, potentially under attacker control.
Zones using this methodology will be considered insecure by all resolvers except those aware of the experiment, and it is not generally possible to create a secure delegation from an experimental zone followed by unaware resolvers.