Disclosure of Negative Trust Anchors in DNS Responses
draft-farrokhi-dnsop-ede-nta-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Babak Farrokhi , Joe Abley , Sebastiaan Neuteboom | ||
| Last updated | 2026-06-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-farrokhi-dnsop-ede-nta-00
Network Working Group B. Farrokhi
Internet-Draft Quad9
Intended status: Informational J. Abley
Expires: 17 December 2026 S. Neuteboom
Cloudflare
15 June 2026
Disclosure of Negative Trust Anchors in DNS Responses
draft-farrokhi-dnsop-ede-nta-00
Abstract
This document describes a mechanism for disclosing that a Negative
Trust Anchor (NTA) was in effect at the time that a DNS response was
generated, using an Extended DNS Error (EDE).
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 17 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Farrokhi, et al. Expires 17 December 2026 [Page 1]
Internet-Draft EDE NTA June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extended DNS Error Code TBD - Negative Trust Anchor in
Effect . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Considerations . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC8914] defines the Extended DNS Error (EDE) mechanism, which
allows DNS servers to encode additional information in a DNS
response.
[RFC7646] defines the concept of a DNSSEC Negative Trust Anchor
(NTA), an operational mechanism by which a validating resolver can be
configured to temporarily disable DNSSEC validation for a specific
domain to mitigate misconfiguration.
A resolver with an NTA in effect might send a response that
ordinarily would have been suppressed because of validation failures.
This document defines a new EDE that can be sent with a response to
indicate that the response was subject to an active NTA.
A further goal of this signal is transparency toward end users and
applications. Section 3.1 of [RFC7646] recommends that operators
disclose the NTAs they have in place, for example on a website, and
notes that no in-band DNS signal exists to indicate that an NTA is in
effect. This document defines that in-band signal, complementing
such out-of-band disclosure.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document assumes a familiarity with common DNS terminology as
described in [RFC9499].
Farrokhi, et al. Expires 17 December 2026 [Page 2]
Internet-Draft EDE NTA June 2026
2. Extended DNS Error Code TBD - Negative Trust Anchor in Effect
A response that includes one or more instances of EDE TBD was
generated with a covering NTA [RFC7646] in effect.
As with all EDEs, the EDE defined in this document is diagnostic; per
Section 6 of [RFC8914] a client MUST NOT use its presence to alter
protocol processing. The inclusion of this EDE in a response does
not change AD bit processing in DNS messages in any way. The only
purpose of this EDE is to provide additional information about the
response in which it appears.
This EDE is intended for use in DNS responses sent by a DNS resolver
with a configured NTA and SHOULD NOT be included in other responses.
For example, a DNS response sent by an authoritative-only DNS server,
which does not perform validation and hence has no obvious use for an
NTA, SHOULD NOT include this EDE.
3. Operational Considerations
An operator that applies an NTA SHOULD return this EDE in affected
responses, so that end users and applications can tell that the
response may not have been DNSSEC-validated. This complements, and
does not replace, the disclosure recommended in Section 3.1 of
[RFC7646].
A response might be affected by an NTA for various reasons, not just
in the case where the QNAME is subordinate to the domain for which an
NTA has been configured. In any case, a resolver MAY include this
EDE on any responses while an NTA is in effect, regardless of whether
the presence of the NTA had a material effect on the contents of the
response.
A resolver with multiple NTAs in place simultaneously MAY include
multiple instances of this EDE in a single response, each
representing a different NTA.
The operator MAY use the EXTRA-TEXT field to add context about the
NTA, such as the name at which it was configured, the reason it was
put in place, a reference where more information can be found, or its
expected duration. As noted in Section 2 of [RFC8914], EXTRA-TEXT is
intended for human consumption; operators SHOULD keep it readable and
SHOULD NOT include private or sensitive information. Structured data
MAY be included in the EXTRA-TEXT field, as described in
[I-D.ietf-dnsop-structured-dns-error].
When multiple instances of this EDE are included, the EXTRA-TEXT
field in each instance SHOULD be populated.
Farrokhi, et al. Expires 17 December 2026 [Page 3]
Internet-Draft EDE NTA June 2026
4. IANA Considerations
IANA has made the following allocation in the "Extended DNS Error
Codes" registry under the "Domain Name System (DNS) Parameters"
registry group:
+===========+=======================+===============+
| INFO-CODE | Purpose | Reference |
+===========+=======================+===============+
| TBD | Negative Trust Anchor | This document |
+-----------+-----------------------+---------------+
Table 1
5. Security Considerations
An NTA represents an intentional, operator-driven suspension of
DNSSEC validation for a specific domain. See [RFC7646] for further
discussion of the operational and security implications of NTAs.
The presence of the EDE defined in this document does not modify AD
bit processing in DNS messages, and its only purpose is to provide
additional information.
EDEs encoded in DNS messages carry no cryptographic signatures and
hence enjoy no inherent integrity protection. An on-path attacker
could add, remove, or modify an EDE. Clients that require integrity
protection of these signals should use an authenticated and encrypted
transport between client and resolver, such as DNS over TLS [RFC7858]
or DNS over HTTPS [RFC8484]. See Section 6 of [RFC8914] for more
discussion.
6. References
6.1. Normative References
[RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
and R. Weber, "Definition and Use of DNSSEC Negative Trust
Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
<https://www.rfc-editor.org/info/rfc7646>.
Farrokhi, et al. Expires 17 December 2026 [Page 4]
Internet-Draft EDE NTA June 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[I-D.ietf-dnsop-structured-dns-error]
Wing, D., Reddy.K, T., Cook, N., and M. Boucadair,
"Structured Error Data for Filtered DNS", Work in
Progress, Internet-Draft, draft-ietf-dnsop-structured-dns-
error-22, 9 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
structured-dns-error-22>.
6.2. Informative References
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Acknowledgements
The authors thank the contributors to this document.
Authors' Addresses
Babak Farrokhi
Quad9
Email: babak@farrokhi.net
Joe Abley
Cloudflare
Email: jabley@cloudflare.com
Farrokhi, et al. Expires 17 December 2026 [Page 5]
Internet-Draft EDE NTA June 2026
Sebastiaan Neuteboom
Cloudflare
Email: sebastiaan@cloudflare.com
Farrokhi, et al. Expires 17 December 2026 [Page 6]