Disclosure of Negative Trust Anchors in DNS Responses

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.¶

Table of Contents

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.¶

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.¶

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:¶

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

Appendix A. Acknowledgements

The authors thank the contributors to this document.¶

Authors' Addresses