| Internet-Draft | DNS XFR URI Schemes | November 2025 |
| Hardaker | Expires 29 May 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://github.io/hardker/draft-hardaker-dnsop-dns-xfr-scheme/draft-hardaker-dnsop-dns-xfr-scheme.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-hardaker-dnsop-dns-xfr-scheme/.¶
Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (mailto:dnsop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at https://www.ietf.org/mailman/listinfo/dnsop/.¶
Source for this draft and an issue tracker can be found at https://github.com/https://github.com/hardaker/draft-hardaker-dnsop-dns-xfr-scheme.¶
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 29 May 2026.¶
Copyright (c) 2025 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.¶
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) [RFC3986] scheme for referencing DNS servers from which DNS zone contents can be transferred.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Current DNS transfer protocols exist in three fundamental forms: Authoratative Transfers (AXFR) [RFC5936], Incremental Zone Transfers (IXFR) [RFC5936] and XFR over TLS (XoT) [RFC9103]. This document defines URI schemes for all three of these DNS transfer protocols.¶
This document uses the Augmented Backus-Naur Form (ABNF) of [RFC5234].¶
xfr-URI = scheme ":" host [ ":" port ] "/" zone
scheme = "axfr" / "ixfr" / "xot"
zone = TBD
¶
host and port are specified in [RFC3986].¶
The 'scheme' signifies which DNS zone transfer protocol should be used (AXFR [RFC5936], IXFR [RFC5936] or XoT [RFC9103]). While these two ABNF productions are defined in [RFC3986] 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.¶
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.").¶
The "axfr", "ixfr" or "xot" URI schemes do not introduce new security considerations beyond what is specified in their respective RFCs (AXFR [RFC5936], IXFR [RFC5936] or XoT [RFC9103]). 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.¶
This section contains the registration information for the "axfr", "ixfr" or "xot" URI schemes (in accordance with [RFC4395]).¶
URI scheme name: axfr¶
Status: permanent¶
URI scheme syntax: See Section Section 3¶
URI scheme semantics: See Section Section 4¶
Encoding considerations: There are no encoding considerations beyond those in [RFC3986].¶
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 Section 5¶
Contact: Wes Hardaker ietf@hardakers.net¶
URI scheme name: ixfr¶
Status: permanent¶
URI scheme syntax: See Section Section 3¶
URI scheme semantics: See Section Section 4¶
Encoding considerations: There are no encoding considerations beyond those in [RFC3986].¶
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 Section 5¶
Contact: Wes Hardaker ietf@hardakers.net¶
URI scheme name: xot¶
Status: permanent¶
URI scheme syntax: See Section Section 3¶
URI scheme semantics: See Section Section 4¶
Encoding considerations: There are no encoding considerations beyond those in [RFC3986].¶
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 Section 5¶
Contact: Wes Hardaker ietf@hardakers.net¶