Internet DRAFT - draft-ietf-dnsop-compact-denial-of-existence
draft-ietf-dnsop-compact-denial-of-existence
Internet Engineering Task Force S. Huque
Internet-Draft Salesforce
Updates: 4034, 4035 (if approved) C. Elmerot
Intended status: Standards Track O. Gudmundsson
Expires: 5 September 2024 Cloudflare
4 March 2024
Compact Denial of Existence in DNSSEC
draft-ietf-dnsop-compact-denial-of-existence-03
Abstract
This document describes a technique to generate a signed DNS response
on demand for a non-existent name by claiming that the name exists
but doesn't have any data for the queried record type. Such answers
require only one minimal NSEC record, allow online signing servers to
minimize signing operations and response sizes, and prevent zone
content disclosure.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/shuque/id-dnssec-compact-lies.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Huque, et al. Expires 5 September 2024 [Page 1]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
2. Distinguishing NXDOMAIN from Empty Non-Terminal Names . . . . 3
3. Generating Responses . . . . . . . . . . . . . . . . . . . . 4
3.1. Responses for Non-Existent Names . . . . . . . . . . . . 4
3.2. Responses for Non-Existent Types . . . . . . . . . . . . 5
3.3. Responses for Wildcard Matches . . . . . . . . . . . . . 5
3.4. Responses to explicit queries for NXNAME . . . . . . . . 6
4. Response Code Restoration . . . . . . . . . . . . . . . . . . 6
4.1. Signaled Response Code Restoration . . . . . . . . . . . 6
5. Operational Implications . . . . . . . . . . . . . . . . . . 7
6. Updates to RFCs . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Updates to RFC 4034 . . . . . . . . . . . . . . . . . . . 8
6.2. Updates to RFC 4035 . . . . . . . . . . . . . . . . . . . 8
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and Motivation
One of the functions of the Domain Name System Security Extensions
(DNSSEC) [RFC9364] is "Authenticated Denial of Existence", i.e.
proving that a DNS name or record type does not exist. Normally,
this is done by means of signed NSEC or NSEC3 records. In the
precomputed signature model, these records chain together existing
names, or cryptographic hashes of them in the zone. In the online
signing model, described in NSEC and NSEC3 "White Lies" [RFC4470]
[RFC7129], they are used to dynamically compute an epsilon function
around the queried name. A 'type bitmap' in the data field of the
NSEC or NSEC3 record asserts which resource record types are present
at the name.
Huque, et al. Expires 5 September 2024 [Page 2]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
The response for a non-existent name requires up to 2 signed NSEC
records or up to 3 signed NSEC3 records (and for online signers, the
associated cryptographic computation), to prove that (1) the name did
not explicitly exist in the zone, and (2) that it could not have been
synthesized by a wildcard.
This document describes an alternative technique, "Compact Denial of
Existence" or "Compact Answers", to generate a signed DNS response on
demand for a non-existent name by claiming that the name exists but
has no resource records associated with the queried type, i.e. it
returns a NODATA response rather than an NXDOMAIN response. A NODATA
response, which has a response code (RCODE) of NOERROR and an empty
ANSWER section, requires only one NSEC record matching the queried
name. This has two advantages: the DNS response size is smaller, and
it reduces the online cryptographic work involved in generating the
response.
The use of minimally covering NSEC records also prevents adversaries
from enumerating the entire contents of DNS zones by walking NSEC
chains.
2. Distinguishing NXDOMAIN from Empty Non-Terminal Names
Since NODATA responses are generated for non-existent names, and
there are no defined record types for the name, the NSEC type bitmap
in the response will only contain "NSEC" and "RRSIG". Tools that
need to accurately identify non-existent names in responses cannot
rely on this specific type bitmap because Empty Non-Terminal (ENT)
names (which positively exist) also have no record types at the name
and will return exactly the same type bitmap.
Previously, some specific implementations of Compact Answers have
tried to avoid the NXDOMAIN identification problem by synthesizing
the NSEC type bitmap for ENTs to include all record types supported
except for the queried type. This has the undesirable effect of no
longer being able to reliably determine the existence of ENTs, and of
making the Type Bitmaps field larger than it needs to be. It also
has the potential to confuse validators and others tools that infer
type existence from the NSEC record.
This document defines the use of a synthetic Resource Record type to
signal the presence of a non-existent name. The mnemonic for this RR
type is "NXNAME", chosen to clearly distinguish it from the response
code mnemonic NXDOMAIN.
Type Value Meaning
NXNAME [TBD] NXDOMAIN indicator for Compact Denial of Existence
Huque, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
This RR type is added to the NSEC type bitmap for responses to non-
existent names (in addition to the required RRSIG and NSEC types).
It is a "Meta-Type", as defined in [RFC6895], stores no data in a DNS
zone, and cannot be usefully queried. Section 3.4 describes what a
DNS resolver or authoritative server should do if it receives an
explicit query for NXNAME.
No special handling of this RR type is required on the part of DNS
resolvers. However, resolvers may optionally implement the behavior
described in Section 4.1 (Response Code Restoration) to better
restore NXDOMAIN visibility to various applications.
An alternative way to distinguish NXDOMAIN from ENT is to define the
synthetic Resource Record type for ENTs instead, as specified in
[ENT-SENTINEL], and this was already successfully deployed in the
field for a period of time. This typically imposes less work on the
server since NXDOMAIN responses are a lot more common than ENTs. At
the time it was deployed, it also allowed a common bitmap pattern
("NSEC RRSIG") to identify NXDOMAIN across this and other
implementations that returned a broad bitmap pattern for Empty Non-
Terminals. However, the advantage of the NXNAME RR type is that it
explicitly identifies NXDOMAIN responses, and allows them to be
distinguished conclusively from potential ENT responses in other
online signing NSEC implementations.
3. Generating Responses
This section describes various types of answers generated by
authoritative servers implementing Compact Denial of Existence. At
the current time, the compact denial scheme is only defined for NSEC.
While it could support NSEC3 too, there is no benefit in introducing
the additional complexity associated with it.
3.1. Responses for Non-Existent Names
When the authoritative server receives a query for a non-existent
name in a zone that it serves, a NODATA response (response code
NOERROR, empty Answer section) is generated with a dynamically
constructed NSEC record with the owner name matching the queried name
(QNAME).
The Next Domain Name field SHOULD be set to the immediate
lexicographic successor of the QNAME. The Type Bit Maps field MUST
only have the bits set for the following RR Types: RRSIG, NSEC, and
NXNAME.
Huque, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
For example, a request for the non-existing name a.example.com would
cause the following NSEC record to be generated (in DNS presentation
format):
a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
The NSEC record MUST have corresponding RRSIGs generated.
3.2. Responses for Non-Existent Types
When the authoritative server receives a query for a name that
exists, but has no resource record sets associated with the queried
type, it generates a NODATA response, with a dynamically constructed
signed NSEC record in the Authority Section. The owner name of the
NSEC record matches the queried name. The Next Domain Name field is
set to the immediate lexicographic successor of the QNAME. The Type
Bitmaps field lists the available Resource Record types at the name.
An Empty Non-Terminal is a special subset of this category, where the
name has no resource record sets of any type (but has descendant
names that do). For a query for an Empty Non-Terminal, the NSEC type
bitmap will only contain RRSIG and NSEC. (Note that this is
substantially different than the ENT response in precomputed NSEC,
where the NSEC record has the same type bitmap, but "covers" rather
than matches the ENT, and has the Next Domain Name field set to the
next lexicographic descendent of the ENT in the zone.)
3.3. Responses for Wildcard Matches
For wildcard matches, the authoritative server will provide a
dynamically signed response that claims that the queried name exists
explicitly. Specifically, the answer RR set will have an RRSIG
record demonstrating an exact match (i.e. the label count in the
RRSIG RDATA will be equal to the number of labels in the query name
minus the root label). This obviates the need to include an NSEC
record in the Authority section of the response that shows that no
closer match than the wildcard was possible.
For a Wildcard NODATA match (where the queried name matches a
wildcard but no data for the queried type exists), a response akin to
a non-wildcard NODATA is returned. The Answer section is empty, and
the Authority section contains a single NSEC record that matches the
query name with a type bitmap representing the list of types
available at the wildcard.
Huque, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
3.4. Responses to explicit queries for NXNAME
NXNAME is a meta type which should not appear anywhere in a DNS
message apart from the NSEC type bitmap of a Compact Answer response
for a non-existent name. If however a DNS server implementing this
specification receives an explicit query for the NXNAME RR type, this
section describes what the response should be.
If an explicit query for the NXNAME RR type is received, the DNS
server MUST return a Format Error (response code FORMERR). A
resolver should not forward these queries upstream or attempt
iterative resolution. Many DNS server implementations already return
errors for all types in the meta and q-type range unless they are
defined to support queries. This general behavior however is not
clearly specified in any existing protocol specification document and
should be.
4. Response Code Restoration
For non-existent names, implementations should try wherever possible,
to preserve the response code value of 3 (NXDOMAIN). This is
generally possible for non-DNSSEC enabled queries, namely those which
do not set the DNSSEC_OK EDNS flag (DO bit). For such queries,
authoritative servers implementing Compact Denial of Existence could
return a normal NXDOMAIN response. There may be limited benefit to
doing this however, since most modern DNS resolvers are DNSSEC-aware,
and by [RFC3225] Section 3, DNSSEC-aware recursive servers are
required to set the DO bit on outbound queries, regardless of the
status of the DO bit on incoming requests.
A validating resolver that understands the NXNAME signal from an
authoritative server could modify the response code from NOERROR to
NXDOMAIN in responses they return to downstream queriers that have
not set the DO bit in their requests.
4.1. Signaled Response Code Restoration
This section describes an optional but recommended scheme to permit
signaled restoration of the NXDOMAIN RCODE for DNSSEC enabled
responses. A new EDNS0 [RFC6891] header flag is defined in the 2nd
most significant bit of the flags field in the EDNS0 OPT header.
This flag is referred to as the "Compact Answers OK (CO)" flag.
Huque, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO|CO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
When this flag is sent in a query by a resolver, it indicates that
the resolver will accept a signed NXNAME enhanced NODATA response for
a non-existent name together with the response code field set to
NXDOMAIN (3).
In responses to such queries, a Compact Denial authoritative
implementing this signaling scheme, will set the Compact Answers OK
EDNS header flag, and for non-existent names will additionally set
the response code field to NXDOMAIN.
EDNS is a hop by hop signal, so resolvers will need to record the
presence of this flag in associated cache data and respond to
downstream DNSSEC enabled queriers appropriately. If the querier
does not set the Compact Answers OK flag, the resolver will need to
reset the response code back to NOERROR (0) for an NXNAME response.
5. Operational Implications
For DNSSEC enabled queries, a signed zone at an authoritative server
implementing Compact Answers will never return a response with a
response code of NXDOMAIN, unless they have implemented the optional
response code restoration feature described in Section 4.1.
Similarly, resolvers not implementing this feature will also not be
able to return NXDOMAIN. In the absence of this, tools that rely on
accurately determining non-existent names will need to infer them
from the presence of the NXNAME RR type in the type bitmap of the
NSEC record in NODATA responses from these servers.
Address lookup functions typically invoked by applications may need
to do more work when dealing with implementations of Compact Answers.
For example, a NODATA response to the lookup of an AAAA record for a
non-existent name, can cause such functions to issue another query at
the same name for an A record. Whereas an NXDOMAIN response to the
first query would suppress additional queries for other types at that
name. Address lookup functions could be enhanced to issue DNSSEC
enabled queries and to examine the NSEC type bitmaps in responses to
accurately determine non-existent names.
Huque, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
6. Updates to RFCs
6.1. Updates to RFC 4034
[RFC4034] Section 4.1.2, The Type Bit Maps Field, states the
following:
* Bits representing pseudo-types MUST be clear, as they do not
appear in zone data. If encountered, they MUST be ignored upon
being read.
This paragraph is updated to the following:
* Bits representing pseudo-types MUST be clear, as they do not
appear in zone data. If encountered, they MUST be ignored upon
being read. There is one exception to this rule for Compact
Denial of Existence (RFC TBD), where the NXNAME pseudo-type is
allowed to appear in responses to non-existent names.
Note: as a practical matter, no known resolver insists that pseudo-
types must be clear in the NSEC type bitmap, so this restriction
(prior to its revision) has posed no problem for the deployment of
this mechanism.
6.2. Updates to RFC 4035
[RFC4035] Section 2.3, Including NSEC RRs in a Zone, states the
following:
* An NSEC record (and its associated RRSIG RRset) MUST NOT be the
only RRset at any particular owner name. That is, the signing
process MUST NOT create NSEC or RRSIG RRs for owner name nodes
that were not the owner name of any RRset before the zone was
signed. The main reasons for this are a desire for namespace
consistency between signed and unsigned versions of the same zone
and a desire to reduce the risk of response inconsistency in
security oblivious recursive name servers.
This paragraph is updated to the following::
* An NSEC record (and its associated RRSIG RRset) MUST NOT be the
only RRset at any particular owner name. That is, the signing
process MUST NOT create NSEC or RRSIG RRs for owner name nodes
that were not the owner name of any RRset before the zone was
signed. The main reasons for this are a desire for namespace
consistency between signed and unsigned versions of the same zone
and a desire to reduce the risk of response inconsistency in
security oblivious recursive name servers. This concern only
Huque, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
applies to implementations of DNSSEC that employ pre-computed
signatures. There is an exception to this rule for online signing
implementations of DNSSEC (e.g Minimally Covering NSEC, and
Compact Denial of Existence (RFC TBD), where dynamically generated
NSEC records can be produced for owner names that don't exist or
are empty non-terminals.
7. Implementation Status
Cloudflare, NS1, and Amazon Route53 currently implement the Compact
Denial of Existence method. From early 2021 until November 2023, NS1
had deployed the Empty Non-Terminal distinguisher using the private
RR type code 65281. At the present time Cloudflare (since July 2023)
and NS1 (since November 2023) both implement the NXNAME distinguisher
using the private RR type code 65283. Amazon Route53 is expected to
implement NXNAME after the specification is finalized and an official
code point is allocated. At the current time, there are only
prototype implementations of the signaled rcode restoration scheme.
8. Security Considerations
Online signing of DNS records requires authoritative servers for the
DNS zone to have access to the private signing keys. Exposing
signing keys on Internet reachable servers makes them more vulnerable
to attack.
Additionally, generating signatures on-demand is more computationally
intensive than returning pre-computed signatures. Although the
Compact Answers scheme reduces the number of online signing
operations compared to previous techniques like White Lies, it still
may make authoritative servers more vulnerable to computational
denial of service attacks than pre-computed signatures. The use of
signature algorithms (like those based on Elliptic Curves) that have
a comparatively low cost for signing is recommended.
Some security tools rely on detection of non-existent domain names by
examining the response code field of DNS response messages. A
NOERROR code in that field rather than NXDOMAIN will impact such
tools. Implementation of the optional response code restoration
scheme will help recover NXDOMAIN visibility for these tools. Note
that the DNS header is not cryptographically protected, so the
response code field cannot be authenticated. Thus inferring the
status of a response from signed data in the body of the DNS message
is actually more secure. These tools could be enhanced to recognize
the (signed) NXNAME signal.
Huque, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
If the motivating aspects of this specification (minimizing response
size and computational costs) are not a concern, DNSSEC deployments
can opt for a different method (e.g. traditional online signing or
pre-computed signatures), and avoid imposing the challenges of
NXDOMAIN visibility.
9. Acknowledgements
The Compact Answers technique (then called "Black Lies") was
originally proposed in [BLACK-LIES] by Filippo Valsorda and Olafur
Gudmundsson, and implemented by Cloudflare. The Empty Non-Terminal
distinguisher RR type was originally proposed in [ENT-SENTINEL] by
Shumon Huque, and deployed by NS1. The NXNAME type is based on the
FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson and Valsorda.
Especially detailed discussions on many technical aspects of this
document were conducted with Paul Vixie, Jan Vcelak, Viktor Dukhovni,
and Ed Lewis. The authors would also like to thank the many other
members of the IETF DNS Operations working group for helpful comments
and discussions.
10. IANA Considerations
IANA is requested to allocate a new DNS Resource Record type code for
NXNAME in the DNS parameters registry, from the meta type range.
Specifically, the lowest available number (currently 128) in the meta
range is requested to be allocated. A lower number lowers the size
of the type bitmap, which reduces the size of the DNS response
message.
Type Value Meaning
NXNAME [TBD] NXDOMAIN indicator for Compact Denial of Existence
IANA is additionally requested to allocate the "Compact Answers OK"
flag in the EDNS header, as described in Section 4.1
11. References
11.1. Normative References
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
RFC 3225, DOI 10.17487/RFC3225, December 2001,
<https://www.rfc-editor.org/info/rfc3225>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
Huque, et al. Expires 5 September 2024 [Page 10]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<https://www.rfc-editor.org/info/rfc4035>.
[RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
and DNSSEC On-line Signing", RFC 4470,
DOI 10.17487/RFC4470, April 2006,
<https://www.rfc-editor.org/info/rfc4470>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>.
11.2. Informative References
[BLACK-LIES]
Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
Existence or Black Lies", <https://tools.ietf.org/html/
draft-valsorda-dnsop-black-lies>.
[ENT-SENTINEL]
Huque, S., "Empty Non-Terminal Sentinel for Black Lies",
<https://www.ietf.org/archive/id/draft-huque-dnsop-
blacklies-ent-01.html>.
[NXDOMAIN-TYPE]
Gudmundsson, O. and F. Valsorda, "Signaling NSEC record
owner name nonexistence", <https://tools.ietf.org/html/
draft-ogud-fake-nxdomain-type/>.
Authors' Addresses
Huque, et al. Expires 5 September 2024 [Page 11]
Internet-Draft Compact Denial of Existence in DNSSEC March 2024
Shumon Huque
Salesforce
415 Mission Street, 3rd Floor
San Francisco, CA 94105
United States of America
Email: shuque@gmail.com
Christian Elmerot
Cloudflare
101 Townsend St.
San Francisco, CA 94107
United States of America
Email: elmerot@cloudflare.com
Olafur Gudmundsson
Cloudflare
101 Townsend St.
San Francisco, CA 94107
United States of America
Email: olafur@cloudflare.com
Huque, et al. Expires 5 September 2024 [Page 12]
