| Internet-Draft | IANA root zone publication point list fo | January 2026 |
| Hardaker | Expires 23 July 2026 | [Page] |
This document describes a machine readable format to be used by IANA to publish a list of sources where the contents of the IANA DNS Root Zone may be fetched from.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-hardaker-dnsop-iana-root-zone-publication-points/.¶
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-iana-root-zone-publication-points.¶
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 23 July 2026.¶
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.¶
DNS recursive resolvers implementing functionality such as LocalRoot [draft-wkumari-dnsop-localroot-bcp] need to obtain the contents of the IANA DNS root zone on a regular basis. This document describes a machine readable format that can be used by IANA to publish a list of sources that can be used for obtaining the contents of the IANA DNS Root Zone.¶
The list of IANA root zone data publication points, available at TBD-URL, may be used to discover where the IANA root zone data can be fetched from.¶
It is expected that this will be used as described in [draft-wkumari-dnsop-localroot-bcp], and may be used by the resolver software directly, or by the operating system a resolver is deployed on, or by a network operator when configuring a resolver.¶
The contents of the IANA DNS root publication points file MUST be verifiable as to its integrity as having come from IANA and MUST be verifiable as being complete.¶
NOTE: this is but an example format that is expected to spur discussions within IETF working groups like DNSOP. Whether this is a list in a simple line-delimited format like below or signed JSON or signed PGP or ... is subject to debate.¶
The IANA root zone data publication points file is structured into two distinct segments, divided by a line consisting of four dashes followed by a newline ("----\n"). The first segment contains a list of URLs, one per line. The second segment provides a signature or cryptographic checksum.¶
While this specific format was originally designed for IANA's maintained list of root zone publication points, it may also be used by other publication point aggregation lists.¶
The list may include URLs using any protocol capable of transferring DNS zone data, including HTTPS [RFC9110], AXFR [draft-hardaker-dnsop-dns-xfr-scheme], XoT [draft-hardaker-dnsop-dns-xfr-scheme], etc.¶
Each URL MUST occur on its own line. Lines beginning with the "#" character are considered comments and MUST be ignored. Leading and trailing whitespace on each line SHOULD be ignored.¶
Any URLs that reference an unknown transfer protocol in the LocalRoot implementations SHOULD be discarded. If after filtering the list there are no acceptable list elements left, the resolver MUST revert to using regular DNS queries to the IANA root zone instead of operating as a LocalRoot.¶
The first line of the cryptographic checksum section will contain a checksum or signature type string specifying what the remaining lines in the checksum or signature section will contain. (Ed note: this section is underspecified. We expect to refine this as we get feedback from the working group.)¶
A minimal example publication point file, containing a single AXFR publication point with a target of b.root-servers.net:¶
axfr:b.root-servers.net/. ---- SHA256 67d687eb21e59321dbb8115c51d1b4ddbd6634362859d130ed77b47a4410656c¶
Future note: this should eventually be a signature from an identity, regardless of format, that can be traced back to IANA being the authoritative publisher and not just a simple checksum.¶
Implementations SHOULD optimize retrieval to minimize impacts on the server. Because the list is not expected to change frequently, implementations SHOULD refrain from querying IANA's source more than once a week.¶
TBD¶
It is critical that LocalRoot implementations (or other any code bases) making use of the publication point list format described in this document verify the contents using the encoded checksum to ensure it has not been tampered with.¶
TBD¶
TBD: describe the request for IANA to support a list of root server publication points at TBD-URL.¶
TBD¶