]> Google, Inc.

ietf@hardakers.net

Operations and Management Domain Name System Operations DNS DNSSEC zone cut delegation referral 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. About This Document 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 DNS recursive resolvers implementing functionality such as LocalRoot 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.

IANA maintained list of root zone publication points 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 , 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.

Root zone publication points 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 , AXFR , XoT , 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: 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.

Operational Considerations 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

Security Considerations 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

IANA Considerations TBD: describe the request for IANA to support a list of root server publication points at TBD-URL.

References Normative References This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest. The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes. ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets (DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications. As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. Informative References 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] 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. n.d. n.d. n.d. n.d.

Acknowledgments TBD