]> Viagenie

Marc.Blanchet@viagenie.ca

Netnod Internet Exchangen

liman@netnod.se

USC/ISI

ietf@hardakers.net

Internet-Draft The DNS root name service is a critical part of the Internet architecture. The DNS root name service's DNS protocol and deployment requirements are defined in this document. Operational requirements for the root name service are out of scope.

Introduction This document co-exists with a corresponding operational requirements document published by the Root Server System Advisory Committee of ICANN in or any subsequent version. Although intricately tied together, both of these documents may be updated at any time to reflect required updates to the protocol, deployment and operational requirements. Further notes about the history of these documents is discussed in . The root servers are authoritative servers of the unique root zone (".") . They currently also serve the root- servers.net zone. Some also serve the zone for the .arpa top-level domain , although at the time of this writing there are plans to move the service for the .arpa top-level domain to different infrastructure . This document describes the external interface of the root name servers from a protocol viewpoint of the service. It specifies basic requirements for the Internet that DNS clients meet when interacting with a root name service over the public Internet. 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 when, and only when, they appear in all capitals, as shown here.

Relationship to RFC2870 and RFC7720 This document obsoletes both and .

Protocol Requirements This section describes the minimum high-level protocol requirements. The root name service: MUST implement core DNS and clarifications to the DNS . MUST support IPv4 and IPv6 transport of DNS queries and responses. MUST support UDP and TCP transport of DNS queries and responses. MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non-zero checksum. MUST implement DNSSEC as an authoritative name service. MUST implement extension mechanisms for DNS (EDNS(0)) . MUST support distributing Message Digests for DNS Zones . MAY support validating Message Digests for DNS Zones .

Deployment Requirements The root name service: MUST answer queries from any entity conforming to with a valid IP address. MUST serve the unique root zone .

Security Considerations This document does not specify a new protocol. However, the root name service is a key component of the Internet architecture and plays a key role into the overall security of the Internet . Specific security considerations on the DNS protocols are discussed in their respective specifications. The security considerations on the operational side of the root name servers are discussed in the corresponding document published by RSSAC ( or a subsequent version).

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. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Architecture Board This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community. This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. The DNS root name service is a critical part of the Internet architecture. The protocol and deployment requirements for the DNS root name service are defined in this document. Operational requirements are out of scope. 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. This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone. Root Server System Advisory Committee

History originally discussed both the protocol and operational requirements for root name servers for the Internet's domain name system (DNS) protocol . Since its initial publication, both protocol and operational requirements have evolved. The protocol requirements was later split into and the operational requirements was moved to and published by ICANN's Root Server System Advisory Committee (RSSAC). These two documents functionally replaced . Similarly, this document now functionally replaces . As both of these requirement sets are expected to evolve over time, the authors of both document sets hope to always keep them roughly in synchronization. However, the latest version of both of these two documents should be consider the most recent set of requirements regardless of whether they were published together or separately.

Acknowledgements This document was prepared by the ICANN RSSAC Caucus with participation of many Caucus members. Much of this text is a rearrangement and restatement of , which itself contains text was taken from . The editors of this document would like to sincerely thank the following individuals for valuable contributions to the text of : Andrew Sullivan, Simon Perreault, Jean-Philippe Dionne, Dave Thaler, Russ Housley, Alissa Cooper, Joe Abley, Joao Damas, Daniel Karrenberg, Jacques Latour, Eliot Lear, Bill Manning, David Conrad, Paul Hoffman, Terry Manderson, Jari Arkko, and Mark Andrews.