DNS NTA feed zones

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 Introduction and Motivation of . The concept of Negative Trust Anchors (NTA) 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 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 Applicability of Negative Trust Anchors of . The production of NTA feed zones as described in still requires human involvement and is not automatic, but the consumption of NTA feed zones at validating resolvers as described in 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.

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 when, and only when, they appear in all capitals, as shown here.

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)

The DOMAIN field encodes the domain name of the negative trust anchor. It MUST be an uncompressed DNS name in 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 Removal of a Negative Trust Anchor of . 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 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 .

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 . 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 . This is considered negligible. TBD.

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.

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 also form a part of these consumer requirements.

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

Security considerations The security considerations in Section Security Considerations of 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 . Section Removal of a Negative Trust Anchor of 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.

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 .

Acknowledgements The idea of transferring NTAs to validators by representing them as transferable DNS zones is based on Response Policy Zones .