Indicating Resolver Support of DNSSEC
updated by
Extracted elements (14)
A single bit is sufficient to signal DNSSEC support because client-side support is considered binary — the client either accepts all DNSSEC security RRs or none. The EDNS0 header is used because classic DNS header bits are scarce and may be inappropriately copied by non-compliant caching or forwarding servers.
An explicit DO bit is used rather than treating the presence of an EDNS0 header as an implicit indication of DNSSEC support, because there may be applications that use EDNS0 but for which DNSSEC is inappropriate.
The explicit DO notification mechanism was motivated by operational problems: DNSSEC RRs frequently push responses beyond the 512-byte UDP limit (RFC 1035), causing TCP fallback with significantly higher overhead (five packets vs. two), increased latency, timeout failures, and nameserver load. Additionally, some non-DNSSEC-aware resolvers crashed or silently discarded responses containing DNSSEC RRs.
Security records that match an explicit SIG, KEY, NXT, or ANY query, or are part of zone data for an AXFR or IXFR query, are included in responses regardless of whether the DO bit was set. The DO bit governs only automatic inclusion of DNSSEC RRs for authentication.
A recursive DNSSEC-aware server MUST set the DO bit on its recursive requests regardless of the DO bit status of the initiating resolver request, ensuring upstream servers return DNSSEC RRs for the recursive server's cache.
DNSSEC-aware nameservers MUST NOT insert SIG, KEY, or NXT RRs to authenticate a response as specified in RFC 2535 unless the DO bit was set on the request.
If a server returns NOTIMP, FORMERR, or SERVFAIL in response to a query with DO set, the resolver SHOULD NOT expect DNSSEC security RRs and SHOULD retry the query without EDNS0 per RFC 2671 section 5.3.
If the initiating resolver request does not have the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC security RRs before returning data to the client; however, cached data MUST NOT be modified.
The DO bit of the query MUST be copied into the response by the nameserver.
When the DO bit is cleared (zero), DNSSEC security RRs MUST NOT be returned in the response unless those RRs are explicitly queried for (e.g., an explicit SIG, KEY, NXT, or ANY query, or via AXFR/IXFR).
The DNSSEC OK (DO) bit is the most significant bit of the Z field in the EDNS0 OPT header's extended RCODE and flags portion (third and fourth bytes). Setting DO=1 signals the resolver can accept DNSSEC security RRs (SIG, KEY, NXT); DO=0 signals it cannot.
This document allocates one of the 16 EDNS0 extended flag bits defined in RFC 2671 as the DO (DNSSEC OK) bit, assigned to the leftmost (most significant) bit of the extended flags field in the OPT record TTL.
The absence of DNSSEC data in a response to a query with DO set MUST NOT be interpreted as meaning no security information is available for the zone, because the response may be forged or may be a non-forged response to an altered (DO-cleared) query.
The EDNS0 OPT extended RCODE and flags field is 16 bits: bytes 0-1 carry EXTENDED-RCODE and VERSION; bytes 2-3 carry DO as the MSB (bit 0) followed by 15 Z (reserved) bits. DO is the leftmost bit of the TTL field of the OPT record.