A Root Key Trust Anchor Sentinel for DNSSEC
Extracted elements (19)
The mechanism is scoped exclusively to root zone KSK trust anchors. This limitation simplifies the label namespace and the resolver logic, since only root-zone keys require cross-resolver rollover readiness measurements at Internet scale.
The sentinel returns SERVFAIL (rather than any other signal) because SERVFAIL is the existing DNSSEC validation-failure response code, allowing the mechanism to be layered onto existing resolver behavior without requiring clients to distinguish a new response type.
Underscore-prefixed label names were rejected because some browsers and operating systems refuse to fetch them (they are not valid hostnames per RFC 7719). The chosen 'root-key-sentinel-is-ta-' and 'root-key-sentinel-not-ta-' prefixes passed IETF evaluation for label collision, zone operator impact, and desired resolver behavior.
A validating forwarder that sets the EDNS(0) CD bit on all forwarded queries acts identically to a standalone resolver for sentinel purposes. However, if both the local validating resolver and the forwarder target support the sentinel mechanism but disagree on trusted key state and CD is not set, results are indeterminate (Vind or 'other').
SERVFAIL responses may be cached per RFC 2308 for up to 5 minutes, and positive answers for up to their TTL. This caching behavior can affect the repeatability and freshness of sentinel test results.
The sentinel mechanism described here differs from RFC 8145, which has resolvers report cached trust anchors to root servers. RFC 8145 measures resolver impact but not end-user impact; this sentinel mechanism addresses user-facing impact of a KSK roll.
All six preconditions must be satisfied to trigger sentinel special processing: the response is DNSSEC-validated with a Secure result, the EDNS(0) CD bit is not set, QTYPE is A or AAAA, OPCODE is QUERY, and the leftmost label matches a sentinel pattern. If any precondition fails, the resolver MUST NOT alter the DNS response.
DNSSEC-validating resolvers that implement this mechanism MUST perform validation of responses in accordance with RFC 4035. This is a baseline requirement before any sentinel processing may occur.
In the multi-resolver test procedure, the 'root-key-sentinel-not-ta-<key-tag-of-KSK-current>' and 'root-key-sentinel-is-ta-<key-tag-of-KSK-new>' query names MUST be validly signed names. Any validly signed DNS zone can be used as the parent zone.
This sentinel mechanism is OPTIONAL to implement and use. If implemented, it SHOULD be enabled by default to facilitate Internet-wide measurement, though configuration options MAY be provided to disable it for local policy reasons.
When the sentinel logic instructs 'return SERVFAIL', the resolver MUST set RCODE=2 and the Answer Section of the DNS response MUST be empty, overriding any other specification about answer content.
Third parties who can induce a user to make sentinel DNS queries (e.g., via web ads or JavaScript) can, with additional knowledge of which resolvers the user invokes, determine which root KSKs are trusted by those resolvers. Without that additional knowledge, only aggregate resolver capabilities—not individual resolver trust configuration—can be inferred.
For a single resolver, three queries classify resolver behavior: is-ta query, not-ta query, and a query with a bogus (unvalidatable) DNSSEC signature. Results identify five resolver types: Vnew (supports sentinel, has new key), Vold (supports sentinel, lacks new key), Vind (validates but no sentinel), nonV (non-validating), and other (indeterminate, e.g., resolver farms with inconsistent behavior).
For multi-resolver environments, the test uses three queries: a bogus-signed name, 'root-key-sentinel-not-ta-<KSK-current>', and 'root-key-sentinel-is-ta-<KSK-new>'. Response triplets (S=SERVFAIL, A=answer) yield four outcomes: (A * *) means non-validating resolver present; (S A *) means indeterminate; (S S A) means no negative impact from KSK roll; (S S S) means user will be negatively impacted.
The <key-tag> embedded in a sentinel label is expressed as an unsigned decimal integer zero-padded to exactly five digits (e.g., Key Tag 42 becomes '00042'). Labels that do not conform to this format MUST NOT be processed as sentinel queries.
Two special DNS labels trigger sentinel processing in validating resolvers: 'root-key-sentinel-is-ta-<key-tag>' asks whether the key tag identifies a currently trusted root KSK, and 'root-key-sentinel-not-ta-<key-tag>' asks whether it does not. These labels must appear as the leftmost label of the query name.
If a user executes third-party code (e.g., JavaScript in a web page), the trust-anchor state information revealed by sentinel queries is also available to that third party, potentially exposing resolver configuration to adversaries.
The mechanism does not mark unauthenticated responses as authenticated and does not alter DNSSEC's security properties. Sentinel queries do not impose additional processing load beyond normal DNSSEC validation and cannot be exploited to amplify attacks.
Given a valid sentinel query, the resolver checks whether <key-tag> matches an active (non-AddPend, non-Revoked per RFC 5011) root KSK in its trust store, then applies a 2×2 rule: is-ta + trusted → return original answer; is-ta + not-trusted → SERVFAIL; not-ta + trusted → SERVFAIL; not-ta + not-trusted → return original answer.