Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (25)
QNAME-based Key Tag queries are recommended only for trust anchors (not all DNSKEY queries) because each Key Tag query is a separate DNS transaction, whereas the EDNS option is piggybacked on an existing DNSKEY query at no extra query cost.
The QNAME-based Key Tag query approach was chosen over a pure EDNS(0) option approach because EDNS(0) is hop-by-hop and unknown option codes are not forwarded by default, middleboxes may block queries with unknown EDNS(0) options, and recursive resolvers would need to maintain state for stub client Key Tags across queries.
Aggressive NSEC/NSEC3 negative caching can suppress Key Tag queries when responses are NXDOMAIN. Zone operators should consider adding explicit NULL records for expected Key Tag QNAMEs (e.g., '_ta-1111', '_ta-2222', '_ta-1111-2222') to prevent aggressive negative caching from reducing signaling fidelity during rollovers.
A DNS client MUST NOT include Key Tag values for keys that were not learned via a trust anchor or DS records.
A DNS client MUST NOT include the edns-key-tag option in non-DNSKEY queries.
A DNS client SHOULD include the edns-key-tag option when issuing a DNSKEY query for a zone corresponding to a trust anchor, and SHOULD also set the DNSSEC OK (DO) bit in the OPT RR.
A non-validating DNS resolver MUST NOT originate Key Tag queries, and a validating resolver SHOULD NOT originate Key Tag queries when issuing DNSKEY queries for non-trust anchor zones.
A responder (authoritative name server) MUST NOT include the edns-key-tag option in any DNS response.
A validating DNS resolver SHOULD originate a Key Tag query whenever it also originates a DNSKEY query for a trust anchor zone; the trigger for a DNSKEY query is simultaneously the trigger for the Key Tag query.
An authoritative name server MUST generate an appropriate response to a Key Tag query; the response code is determined by whether the data is in the zone file or covered by wildcards, with no special built-in logic required.
Hexadecimal Key Tag values in the Key Tag query QNAME MUST be zero-padded to four hexadecimal digits, and when multiple Key Tags are present they MUST be sorted from smallest to largest.
If a client receives edns-key-tag option values in a DNS response, it MUST ignore those values; the option is only meaningful in queries.
Non-validating recursive resolvers SHOULD copy the edns-key-tag option seen in received queries when forwarding, as it represents the wishes of the validating downstream resolver that issued the original query.
Non-validating stub resolvers MUST NOT include the edns-key-tag option in any query.
Validating recursive resolvers MUST NOT set the edns-key-tag option in the final response returned to the stub client.
When a validating recursive resolver receives a query with an edns-key-tag option whose Key Tag list differs from its own, it SHOULD forward both lists using separate instances of the edns-key-tag option code in the OPT RR.
Zone operators relying on the edns-key-tag mechanism SHOULD take care to ensure new keys have unique Key Tag values, since DNSSEC does not require unique Key Tags and collisions can occur during rollovers.
Implementations MAY be administratively configured to transmit Key Tags only for certain zones. Since the primary motivation is root zone key rollover measurement, implementations SHOULD at least include edns-key-tag for root zone DNSKEY queries.
Key Tag values can serve as a fingerprint to identify particular validating DNS clients, especially if the resolver is configured with trust anchors for zones beyond the root. Resolvers MAY transmit Key Tags only for a subset of queries (e.g., every 25th) or with a certain probability (e.g., 5%) to mitigate this.
A Key Tag query is a standard DNS query of type NULL and class IN. The QNAME begins with '_ta-' followed by a sorted, hyphen-separated list of zero-padded four-digit hexadecimal Key Tag values, appended with the trust anchor zone name (e.g., '_ta-4444.' for root zone Key Tag 17476 decimal).
The two signaling mechanisms defined are both OPTIONAL: (1) an edns-key-tag EDNS(0) option sent with DNSKEY queries, and (2) periodic Key Tag queries (type NULL, class IN) sent to the authoritative server for the trust anchor zone. Each independently conveys the Key Tags of trust anchors used by the resolver.
IANA assigned EDNS0 option code 14 to 'edns-key-tag' (Status: Optional) in the 'DNS EDNS0 Option Codes (OPT)' registry.
An eavesdropper or malicious server could infer the DNSSEC validator in use by observing the Key Tag list, potentially identifying resolvers using old or broken keys or those with known vulnerabilities that could be exploited.
Key Tag values in signaling queries might be fabricated by DNS clients with malicious intent; an attacker with sufficient resources could flood queries containing only old Key Tag values to delay completion of a key rollover.
The edns-key-tag EDNS(0) option encodes a 16-bit OPTION-CODE (value 14), a 16-bit OPTION-LENGTH equal to 2 times the number of Key Tag values, and one or more 16-bit KEY-TAG fields listing the Key Tags of trust anchors or KSKs used for validation.