]> Google, Inc.

ietf@hardakers.net

Google, Inc.

warren@kumari.net

RTFM llp

St Andrews House 382 Hillington Road, Glasgow Scotland G51 4BL UK jim@rfc1035.com

APNIC

6 Cordelia St South Brisbane QLD 4101 Australia gih@apnic.net

Operations and Management Domain Name System Operations DNS DNSSEC zone transfer axfr ixfr The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred. 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 The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred.

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.

Syntax of a DNS Transfer Protocol URI Current DNS transfer protocols exist in three fundamental forms: Authoratative Transfers (AXFR) , Incremental Zone Transfers (IXFR) and XFR over TLS (XoT) . This document defines URI schemes for all three of these DNS transfer protocols. This document uses the Augmented Backus-Naur Form (ABNF) of . host and port are specified in . The 'scheme' signifies which DNS zone transfer protocol should be used (AXFR , IXFR or XoT ). While these two ABNF productions are defined in as components of the generic hierarchical URI, this does not imply that the "axfr", "ixfr" and "xot" URI schemes are hierarchical URIs. Developers MUST NOT use a generic hierarchical URI parser to parse a "axfr", "ixfr" or "xot" URI.

URI Scheme Semantics The "axfr", "ixfr" or "xot" URI schemes are used to refer to a DNS server that offers zone transfer support. These three protocols each specify the details of how transfers are performed within their respective specifications and are beyond the scope of this document. The required 'host' part of the xfr URI denotes the DNS server host. As specified in each transfer protocols specifications, the 'port' part, if present, denotes the port on which the DNS server is awaiting requests. If absent for the axfr and ixfr transfer protocols, this SHOULD be TCP port 53. If absent for the xot transfer protocol, the default port SHOULD be TCP port 853. The 'zone' signifies the zone to be transferred and MUST be a fully qualified domain name. Note that 'zone' MAY be "." to refer to the DNS root zone. When not referring to the root zone, the 'zone' SHOULD have a trailing "." (for example "zone.example.").

Security Considerations The "axfr", "ixfr" or "xot" URI schemes do not introduce new security considerations beyond what is specified in their respective RFCs (AXFR , IXFR or XoT ). These schemes are intended for use in documentation and configuration files that refer to servers offering DNS zone transfers. Documentation and configuration files should carefully consider which protocol is most suitable for use, and if possible the "xot" protocol should be preferred if privacy or integrity of the zone contents are a concern.

IANA Considerations This section contains the registration information for the "axfr", "ixfr" or "xot" URI schemes (in accordance with ).

"axfr" URI Registration URI scheme name: axfr Status: permanent URI scheme syntax: See Section URI scheme semantics: See Section Encoding considerations: There are no encoding considerations beyond those in . Applications/protocols that use this URI scheme name: The "axfr" URI scheme is intended to be used by applications with a need to identify a DNS server supporting authoritative transfer over DNS using the AXFR protocol for a zone. Interoperability considerations: N/A Security considerations: See Section Contact: Wes Hardaker ietf@hardakers.net

"ixfr" URI Registration URI scheme name: ixfr Status: permanent URI scheme syntax: See Section URI scheme semantics: See Section Encoding considerations: There are no encoding considerations beyond those in . Applications/protocols that use this URI scheme name: The "ixfr" URI scheme is intended to be used by applications with a need to identify a DNS server supporting authoritative transfer over DNS using the IXFR protocol for a zone. Interoperability considerations: N/A Security considerations: See Section Contact: Wes Hardaker ietf@hardakers.net

"xot" URI Registration URI scheme name: xot Status: permanent URI scheme syntax: See Section URI scheme semantics: See Section Encoding considerations: There are no encoding considerations beyond those in . Applications/protocols that use this URI scheme name: The "xot" URI scheme is intended to be used by applications with a need to identify a DNS server supporting authoritative transfer over DNS using the XoT protocol for a zone. Interoperability considerations: N/A Security considerations: See Section Contact: Wes Hardaker ietf@hardakers.net

"xoh" URI Registration URI scheme name: xoh Status: permanent URI scheme syntax: See Section URI scheme semantics: See Section Encoding considerations: There are no encoding considerations beyond those in . Applications/protocols that use this URI scheme name: The "xoh" URI scheme is intended to be used by applications with a need to identify a DNS server supporting authoritative transfer over DNS over the HTTPS protocol for a zone. Interoperability considerations: N/A Security considerations: See Section Contact: Wes Hardaker ietf@hardakers.net

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

Acknowledgments

Examples The following are example XFR URIs specifying an 'axfr' URI for the DNS root zone, an 'ixfr' URI for example.com, and a 'xot' URI for zone.example on port 8853:

• axfr:b.root-servers.net/.
• ixfr:ns.example.com/example.com.
• xot:ns.zone.example:8853/zone.example.
• xoh:ns.zone.example/zone.example.