DNSSEC DO bit: Indicating Resolver Support of DNSSEC
A single flag bit in the EDNS0 header lets a resolver tell a DNS server it can accept DNSSEC records.
Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, <https://www.rfc-editor.org/info/rfc3225>.
@misc{rfc3225,
series = {Request for Comments},
number = 3225,
howpublished = {RFC 3225},
publisher = {RFC Editor},
doi = {10.17487/RFC3225},
url = {https://www.rfc-editor.org/info/rfc3225},
author = {D. Conrad},
title = {{Indicating Resolver Support of DNSSEC}},
pagetotal = 6,
year = 2001,
month = dec,
} RFC text
Contents
Network Working Group D. Conrad
Request for Comments: 3225 Nominum, Inc.
Category: Standards Track December 2001
Indicating Resolver Support of DNSSEC
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
In order to deploy DNSSEC (Domain Name System Security Extensions)
operationally, DNSSEC aware servers should only perform automatic
inclusion of DNSSEC RRs when there is an explicit indication that the
resolver can understand those RRs. This document proposes the use of
a bit in the EDNS0 header to provide that explicit indication and
describes the necessary protocol changes to implement that
notification.
1. Introduction
DNSSEC [RFC2535] has been specified to provide data integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures. However, as DNSSEC is
deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
servers. In such situations, the DNSSEC-aware server (responding to
a request for data in a signed zone) will respond with SIG, KEY,
and/or NXT records. For reasons described in the subsequent section,
such responses can have significant negative operational impacts for
the DNS infrastructure.
This document discusses a method to avoid these negative impacts,
namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
NXT RRs when there is an explicit indication from the resolver that
it can understand those RRs.
For the purposes of this document, "DNSSEC security RRs" are
considered RRs of type SIG, KEY, or NXT.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Rationale
Initially, as DNSSEC is deployed, the vast majority of queries will
be from resolvers that are not DNSSEC aware and thus do not
understand or support the DNSSEC security RRs. When a query from
such a resolver is received for a DNSSEC signed zone, the DNSSEC
specification indicates the nameserver must respond with the
appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
512 bytes [RFC1035], responses including DNSSEC security RRs have a
high probability of resulting in a truncated response being returned
and the resolver retrying the query using TCP.
TCP DNS queries result in significant overhead due to connection
setup and teardown. Operationally, the impact of these TCP queries
will likely be quite detrimental in terms of increased network
traffic (typically five packets for a single query/response instead
of two), increased latency resulting from the additional round trip
times, increased incidences of queries failing due to timeouts, and
significantly increased load on nameservers.
In addition, in preliminary and experimental deployment of DNSSEC,
there have been reports of non-DNSSEC aware resolvers being unable to
handle responses which contain DNSSEC security RRs, resulting in the
resolver failing (in the worst case) or entire responses being
ignored (in the better case).
Given these operational implications, explicitly notifying the
nameserver that the client is prepared to receive (if not understand)
DNSSEC security RRs would be prudent.
Client-side support of DNSSEC is assumed to be binary -- either the
client is willing to receive all DNSSEC security RRs or it is not
willing to accept any. As such, a single bit is sufficient to
indicate client-side DNSSEC support. As effective use of DNSSEC
implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
enhanced DNS header) are scarce, and there may be situations in which
non-compliant caching or forwarding servers inappropriately copy data
from classic headers as queries are passed on to authoritative
servers, the use of a bit from the EDNS0 header is proposed.
An alternative approach would be to use the existence of an EDNS0
header as an implicit indication of client-side support of DNSSEC.
This approach was not chosen as there may be applications in which
EDNS0 is supported but in which the use of DNSSEC is inappropriate.
3. Protocol Changes
The mechanism chosen for the explicit notification of the ability of
the client to accept (if not understand) DNSSEC security RRs is using
the most significant bit of the Z field on the EDNS0 OPT header in
the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In
the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
the third and fourth bytes of the "extended RCODE and flags" portion
of the EDNS0 OPT meta-RR, structured as follows:
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Setting the DO bit to one in a query indicates to the server that the
resolver is able to accept DNSSEC security RRs. The DO bit cleared
(set to zero) indicates the resolver is unprepared to handle DNSSEC
security RRs and those RRs MUST NOT be returned in the response
(unless DNSSEC security RRs are explicitly queried for). The DO bit
of the query MUST be copied in the response.
More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
or NXT RRs to authenticate a response as specified in [RFC2535]
unless the DO bit was set on the request. Security records that
match an explicit SIG, KEY, NXT, or ANY query, or are part of the
zone data for an AXFR or IXFR query, are included whether or not the
DO bit was set.
A recursive DNSSEC-aware server MUST set the DO bit on recursive
requests, regardless of the status of the DO bit on the initiating
resolver request. If the initiating resolver request does not have
the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
security RRs before returning the data to the client, however cached
data MUST NOT be modified.
In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
to a query that has the DO bit set, the resolver SHOULD NOT expect
DNSSEC security RRs and SHOULD retry the query without EDNS0 in
accordance with section 5.3 of [RFC2671].
Security Considerations
The absence of DNSSEC data in response to a query with the DO bit set
MUST NOT be taken to mean no security information is available for
that zone as the response may be forged or a non-forged response of
an altered (DO bit cleared) query.
IANA Considerations
EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
these bits are encoded into the TTL field of the OPT record (RFC2671
section 4.6).
This document reserves one of these bits as the OK bit. It is
requested that the left most bit be allocated. Thus the USE of the
OPT record TTL field would look like
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Acknowledgements
This document is based on a rough draft by Bob Halley with input from
Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
Rob Austein, Steve Bellovin, and Erik Nordmark.
References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specifications", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
Author's Address
David Conrad
Nominum Inc.
950 Charter Street
Redwood City, CA 94063
USA
Phone: +1 650 381 6003
EMail: david.conrad@nominum.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Why Servers Need to Be Told
DNSSEC adds cryptographic signatures to DNS data. A DNSSEC-aware server answering for a signed zone responds with SIG, KEY and/or NXT records. This RFC calls these the DNSSEC security RRs.
Early on, most queries will come from resolvers that know nothing about DNSSEC. Sending them the extra records can have significant negative operational impacts for the DNS infrastructure, so the RFC says a server should send them only when the resolver explicitly indicates it can understand them.
Imagine a librarian who staples a thick stack of extra forms to every answer. Most visitors only wanted the answer, so the librarian should ask first.
§2The Cost of Unwanted Security Records
DNS UDP datagrams are limited to 512 bytes. Responses carrying DNSSEC security RRs therefore have a high probability of being truncated, which makes the resolver retry over TCP.
The RFC expects the TCP retries to be quite detrimental: typically five packets for a single query and response instead of two, extra latency from additional round trips, more queries failing from timeouts, and significantly increased load on nameservers.
It also notes reports from preliminary and experimental DNSSEC deployment of non-DNSSEC-aware resolvers that could not handle such responses. In the worst case the resolver failed, and in the better case the whole response was ignored.
Extra forms make the answer too big for a postcard, so the asker has to go and fetch it in a big box instead. That takes longer and wears everyone out.
§3Choosing a Bit in the EDNS0 Header
The RFC assumes client support for DNSSEC is binary: the client will either accept all DNSSEC security RRs or none. A single bit is enough to say which.
The bit lives in the EDNS0 header rather than the classic DNS header. Bits in the classic header are scarce, and non-compliant caching or forwarding servers might inappropriately copy data from classic headers when passing queries on to authoritative servers.
The RFC also considers and rejects an alternative: treating the mere presence of an EDNS0 header as an implicit sign of DNSSEC support. That was not chosen because some applications support EDNS0 but should not use DNSSEC.
Instead of squeezing a tick box onto a crowded form, the designers put it on the roomy extra page. Just having the extra page does not count as saying yes.
§4The DO Bit and Server Behavior
The DNSSEC OK (DO) bit is the most significant bit of the Z field in the EDNS0 OPT record of the query. It is the first bit of the third and fourth bytes of the extended RCODE and flags portion.
When DO is one, the resolver can accept DNSSEC security RRs. When it is zero, those RRs MUST NOT be returned unless they are explicitly queried for. The DO bit of the query MUST be copied in the response. Security records that match an explicit SIG, KEY, NXT or ANY query, or that are part of the zone data for an AXFR or IXFR query, are included whether or not DO was set.
A recursive DNSSEC-aware server MUST set DO on its own recursive requests, whatever the initiating resolver sent. If the initiating request did not have DO set, the server MUST remove the security RRs before replying, but cached data MUST NOT be modified.
If a server answers a DO query with NOTIMP, FORMERR or SERVFAIL, the resolver SHOULD NOT expect DNSSEC security RRs and SHOULD retry without EDNS0, as described in section 5.3 of RFC 2671.
If the question has the box ticked, the answer comes with the extra forms. If it is not ticked, the forms stay behind, unless you asked for them by name. A middleman who talks to the boss always ticks the box, then removes the forms before handing you the answer.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
EXT-RCODE | EXTENDED-RCODE | 1 byte | Extended response code portion. | |
VERSION | VERSION | 1 byte | EDNS version portion. | |
DO | DO | 1 bits | 1 | DNSSEC OK: resolver can accept DNSSEC security RRs. |
Z | Z | 15 bits | Remaining flag bits. |
§5Security and IANA Notes
The absence of DNSSEC data in a response to a query with DO set MUST NOT be taken to mean that no security information is available for that zone. The response may be forged, or it may be a non-forged response to an altered query with the bit cleared.
For IANA, RFC 2671 defines 16 bits of extended flags in the OPT record, encoded in its TTL field. This RFC reserves one of them as the OK bit and requests that the left most bit be allocated.
If the extra forms are missing, you cannot assume nothing was signed. Someone along the way might have faked the answer or removed the tick from your question.