Internet Engineering Task Force M. Sivaraman Internet-Draft Banu Systems Private Limited Intended status: Experimental C. Strotmann Expires: 19 January 2027 Tidelock 18 July 2026 DNS NTA feed zones draft-muks-dns-nta-feed-zones-00 Abstract This memo documents a method for expressing a list of DNS negative trust anchors [RFC7646] inside a specially constructed DNS zone, that validating recursive name servers and other DNSSEC validators may configure negative trust anchors from. 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. Sivaraman & Strotmann Expires 19 January 2027 [Page 1] Internet-Draft DNS NTA feed zones July 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. NTA RR type . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. NTA feed zone . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Producer requirements . . . . . . . . . . . . . . . . . . . . 4 6. Consumer requirements . . . . . . . . . . . . . . . . . . . . 5 7. Example NTA feed zone . . . . . . . . . . . . . . . . . . . . 5 8. Security considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative references . . . . . . . . . . . . . . . . . . 7 11.2. Informative references . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. Sivaraman & Strotmann Expires 19 January 2027 [Page 2] Internet-Draft DNS NTA feed zones July 2026 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. 2. Requirements notation 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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: +-------------+-------------------------+--------------------+ | RDATA field | Type | Field size | +-------------+-------------------------+--------------------+ | DOMAIN | DNS name (uncompressed) | Variable | +-------------+-------------------------+--------------------+ | EXPIRY | Unsigned integer | 64 bits (8 octets) | +-------------+-------------------------+--------------------+ Table 1 The DOMAIN field encodes the domain name of the negative trust anchor. It MUST be an uncompressed DNS name in [RFC1035] wire format. Sivaraman & Strotmann Expires 19 January 2027 [Page 3] Internet-Draft DNS NTA feed zones July 2026 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. Sivaraman & Strotmann Expires 19 January 2027 [Page 4] Internet-Draft DNS NTA feed zones July 2026 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 Sivaraman & Strotmann Expires 19 January 2027 [Page 5] Internet-Draft DNS NTA feed zones July 2026 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. +======+=======+=========================+================+ | Type | Value | Meaning | Reference | +======+=======+=========================+================+ | NTA | TBD | a negative trust anchor | See Section 3. | +------+-------+-------------------------+----------------+ Table 2 Sivaraman & Strotmann Expires 19 January 2027 [Page 6] Internet-Draft DNS NTA feed zones July 2026 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]. 11. References 11.1. Normative references [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., Gudmundsson, O., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", STD 93, RFC 8945, DOI 10.17487/RFC8945, November 2020, . 11.2. Informative references [I-D.vixie-dnsop-dns-rpz] Vixie, P. A. and V. Schryver, "DNS Response Policy Zones (RPZ)", Work in Progress, Internet-Draft, draft-vixie- dnsop-dns-rpz-00, 23 June 2018, . Authors' Addresses Sivaraman & Strotmann Expires 19 January 2027 [Page 7] Internet-Draft DNS NTA feed zones July 2026 Mukund Sivaraman Banu Systems Private Limited 6001 Beach Road, #19-09, Golden Mile Tower SINGAPORE 199589 Singapore Email: muks@banu.com URI: https://banu.com/ Carsten Strotmann Tidelock In den Kaempen 28, Neuenkirchen 48485 Germany Email: ietf@strotmann.de URI: https://dnsworkshop.org/ Sivaraman & Strotmann Expires 19 January 2027 [Page 8]