DNS NTA feed zones

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 19 January 2027.¶

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

As DNSSEC deployment increases, there are more and more incidents where a secure trust chain to validate a domain is not available due to DNSSEC validation-related issues such as those described in Section 1 (Introduction and Motivation) of [RFC7646]. The concept of Negative Trust Anchors (NTA) [RFC7646] was introduced to temporarily workaround such DNSSEC validation issues.¶

Use of NTAs currently requires operators to follow a range of requirements which many DNS validating resolver operators are poorly equipped to follow. There are many DNS resolver operators who run commercial off-the-shelf resolver implementations, e.g., in the form of network appliances, but do not have the ability to generate, manage, and regularly re-evaluate application of NTAs on their own. Many DNS resolver operators typically depend on their software vendors to manage many aspects of DNS operation for them automatically.¶

As an analogous example, many DNS resolver operators also do not have expertise to generate and manage DNS firewalling and filtering information on their own, so they make use of Response Policy Zones [I-D.vixie-dnsop-dns-rpz] to provide this information for their resolvers. The responsibility of generating the information in RPZ is delegated to one or more trusted 3rd-parties.¶

This draft introduces NTA feed zones, which are specially formatted DNS zones that communicate lists of NTAs from their producers to their consumers.¶

NTA feed zone consumer software such as validating resolvers and other DNSSEC validators may configure NTAs from NTA feed zones automatically. This draft obsoletes the text "Use of an NTA MUST NOT be automatic." in Section 2.1 (Applicability of Negative Trust Anchors) of [RFC7646]. The production of NTA feed zones as described in Section 5 still requires human involvement and is not automatic, but the consumption of NTA feed zones at validating resolvers as described in Section 6 is expected to be fully automatic.¶

NTA feed zones provide managed NTAs for those operators who are incapable of applying and maintaining NTAs on their own, so that they may make use of negative trust anchors which they may be unable to use otherwise. The use of NTA feed zones is OPTIONAL. Operators who wish to make use of them may do so, and those who wish to manage NTAs on their own do not have to use NTA feed zones.¶

3. NTA RR type

An NTA RRset encodes a single negative trust anchor's configuration in its RDATA. It is a singleton, i.e., only a single RR of the type may exist in an NTA RRset. The wire format of NTA RDATA is as follows:¶

The DOMAIN field encodes the domain name of the negative trust anchor. It MUST be an uncompressed DNS name in [RFC1035] wire format.¶

The EXPIRY field encodes the expiry time of the negative trust anchor in seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). It is a 64-bit unsigned integer encoded in network byte order. The expiry time SHOULD NOT exceed 1 week from the current time per Section 4 (Removal of a Negative Trust Anchor) of [RFC7646].¶

The EXPIRY time is an advisory indication by the NTA feed zone producer of how long the NTA is expected to be valid for. After an NTA's EXPIRY time, unless its corresponding NTA feed zone was updated with new content, the NTA MUST be unconfigured and removed.¶

Additions and deletions to the list of NTAs in the NTA feed zone and the freshness of the zone data direct the additions and deletions of configured NTAs in the NTA feed zone consumer. An NTA may be deleted from an NTA feed zone well before its specified EXPIRY time. The EXPIRY time of an NTA may also be extended in future versions of the NTA feed zone. An NTA may be re-added soon after its deletion from an NTA feed zone.¶

The presentation format of the NTA RDATA consists of the DOMAIN field in [RFC1035] DNS name presentation format, followed by the EXPIRY field in decimal representation without any sign symbols (e.g., the string output returned by printing the field's value using the "%" PRIu64 format string in C). An example can be seen in Section 7.¶

4. NTA feed zone

NTA feed zones encode a list of negative trust anchors within a DNS zone using the NTA RR type. If the reader would like to view an example first, it may be found in Section 7.¶

The owner name of an NTA RRset also encodes the domain name of the NTA relative to the NTA feed zone's origin as a matter of convenience for implementations to make use of. This is so that negative trust anchors may be queried as part of a zone's existing domain name tree structure. As a result, the maximum length and number of labels of an NTA's domain name represented in the owner name of an RRset within an NTA feed zone as a sub-domain of the zone's origin may be lower than the maximum limits permitted for DNS names by [RFC1035]. This is considered negligible.¶

TBD.¶

5. Producer requirements

This section documents the requirements of a NTA feed zone's producer. It is limited to the content of NTA feed zones and does not specify how the zone is transferred to consumers.¶

TBD.¶

6. Consumer requirements

This section documents the requirements of a NTA feed zone's consumer.¶

TBD.¶

If the NTA feed zone contents become stale or expire due to any reason, all the configured NTAs derived from that feed zone MUST be unconfigured and removed as soon as the condition is detected.¶

If any NTAs that existed in a previous version of the NTA feed zone have been deleted in a new version of the zone, such NTAs must be unconfigured and removed immediately after the new zone's contents are received by the consumer.¶

RRsets other than that of RR type NTA in the NTA feed zone MUST be ignored by the consumer.¶

Zero or more NTA feed zones may be configured at a validating recursive name server or DNSSEC validator. If NTAs with identical domain occur among multiple NTA feed zones, it is RECOMMENDED that the first corresponding NTA in configured order of NTA feed zones be used and the remaining occurrences be discarded.¶

The requirements in Section 8 also form a part of these consumer requirements.¶

7. Example NTA feed zone

The following is a sample NTA feed zone. It is meant to configure a single NTA for the domain example.com. with expiry time at Mon 13 Jul 19:46:48 2026 UTC. Note that in within the zone, the NTA RR has the owner name example.com.nta1.example.net. as the name is specified relative to the zone's origin.¶

$ORIGIN nta1.example.net.
$TTL 1H
@                   SOA localhost. nta-maintainer.example.net. (
                                        1 1h 15m 30d 2h)
                    NS localhost.

example.com         NTA example.com. 1783972008

8. Security considerations

The security considerations in Section 8 (Security Considerations) of [RFC7646] apply.¶

It is strongly RECOMMENDED that NTA feed zone consumer operators regularly establish whether the party producing the NTA feed zones can be relied on for their NTA feed zones' content. This has at least three aspects of consideration: whether the producers of the the NTA feed zones are trusted, whether the NTA feed zones are regularly maintained by their producers to match current network conditions, and whether NTA feed zones are operationally available to consumers without disruption. An example relationship may be that the producer is the consumer operator's DNS resolver vendor and the consumer operator has a legal agreement with that vendor and trusts that vendor.¶

It is strongly RECOMMENDED that DNS zone transfer initiators (clients) of NTA feed zone consumers verify the authenticity and integrity of the NTA feed zone data using a mechanism such as TSIG [RFC8945].¶

Section 4 (Removal of a Negative Trust Anchor) of [RFC7646] recommends that the lifetime of any NTA SHOULD NOT exceed a week. When NTAs are received via NTA feed zones, the DNSSEC validator must ensure that any NTAs whose expiry time is more than 1 week from the current time are either clamped to 1 week from the current time or discarded.¶

NTAs whose EXPIRY time has already passed MUST NOT be used.¶

9. IANA considerations

IANA is requested to allocate the following RR types in the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DNS) Parameters" registry group.¶

10. Acknowledgements

The idea of transferring NTAs to validators by representing them as transferable DNS zones is based on Response Policy Zones [I-D.vixie-dnsop-dns-rpz].¶

Authors' Addresses