]> Google, Inc.

ietf@hardakers.net

Operations and Management Domain Name System Operations DNS DNSSEC zone transfer axfr ixfr This document describes guidelines for entities that wish to publish a list of URLs from where the contents of the IANA DNS root zone may be obtained. These guidelines are specifically provided as guidance to IANA, but these suggestions may be applicable to any entity wishing to build a list of IANA DNS root zone sources for their own purposes. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document describes guidelines for entities that wish to publish a list of URLs from where the contents of the IANA DNS root zone may be obtained. These guidelines are specifically provided as guidance to IANA, but these suggestions may be applicable to any entity wishing to build a list of IANA DNS root zone sources for their own purposes. When implementing a LocalRoot or similar service, as described in , the contents of the DNS root zone need to be obtained. Because the contents of the IANA DNS root zone are crytographically verifiable, it may be obtained from any source assuming integrity verification has been performed. Entities, such as IANA, will need to publish a list of acceptable sources that LocalRoot enabled resolvers can use to routinely fetch and serve or cache the contents of the IANA DNS root zone. The guidelines in this document are intended to provide advice to IANA or any other entity wishing to build such a list of sources. A separate document describes the format of the IANA published list, along with IANA considerations that request the list's publication.

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

Guidelines for building a IANA DNS root zone publication list The following describes the community established guidelines when developing a list of IANA DNS root zone publication points:

Guidelines related to the list of publication points

• the list of publication points must be machine readable
• the list of publication points must not be limited to a particular size.
• the list of publication points should include publication points hosted from multiple organizations.
• the list of publication points should include a service endpoint from IANA itself.
• the list of publication points must be verifiable as complete through the use of a cryptographic checksum.
• the list of publication points should be cryptographically verifiable as to its origin.
• the list of publication points should include multiple protocols that can be used for fetching the IANA root zone data. Specifically the list should include both https and AXFR based sources.
• each item in the list of publication points must be individually complete and usable in isolation.
• each item in the list of publication points must be a unique URL.
• each item in the list of publication points should be routinely verified as to its functioning status or else removed from the list.

Guidelines related to entries in the list of publication points

• each publication point should make use of widely geographically distributed service points.
• each publication point must be globally available without imposed source-based or other filtering.
• https based publication points should offer service equivalent to existing Content Delivery Networks (CDNs) today.
• AXFR, IXFR and XoT publication points should be as robust as the existing DNS root servers that offer similar services today.
• each publication point should have a service level agreement, ideally at zero cost, with IANA.

Security Considerations TBD

IANA Considerations IANA may wish to carefully consider the suggestions in this document when building a list of IANA DNS root zone publication points.

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. [STANDARDS-TRACK] The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document obsoletes RFC 7719 and updates RFC 2308. DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport. n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. n.d.

Acknowledgments TBD