--- 1/draft-ietf-dnsop-rfc8499bis-00.txt 2020-11-20 11:13:11.399318193 -0800 +++ 2/draft-ietf-dnsop-rfc8499bis-01.txt 2020-11-20 11:13:11.459319019 -0800 @@ -1,20 +1,20 @@ Network Working Group P. Hoffman Internet-Draft ICANN Obsoletes: 8499 (if approved) K. Fujiwara Updates: 2308 (if approved) JPRS -Intended status: Best Current Practice 17 November 2020 -Expires: 21 May 2021 +Intended status: Best Current Practice 20 November 2020 +Expires: 24 May 2021 DNS Terminology - draft-ietf-dnsop-rfc8499bis-00 + draft-ietf-dnsop-rfc8499bis-01 Abstract 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. @@ -28,21 +28,21 @@ 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 21 May 2021. + This Internet-Draft will expire on 24 May 2021. Copyright Notice Copyright (c) 2020 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 @@ -53,39 +53,39 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 27 - 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 29 - 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 34 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 36 - 14.2. Informative References . . . . . . . . . . . . . . . . . 39 - Appendix A. Definitions Updated by This Document . . . . . . . . 43 - Appendix B. Definitions First Defined in This Document . . . . . 44 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 28 + 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 30 + 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 35 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 + 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 14.2. Informative References . . . . . . . . . . . . . . . . . 40 + Appendix A. Definitions Updated by This Document . . . . . . . . 45 + Appendix B. Definitions First Defined in This Document . . . . . 45 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction The Domain Name System (DNS) is a simple query-response protocol whose messages in both directions have the same format. (Section 2 - gives a definition of "public DNS", which is often what people mean + gives a definition of "global DNS", which is often what people mean when they say "the DNS".) The protocol and message format are defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, and later documents defined others. Some of the terms from [RFC1034] and [RFC1035] have somewhat different meanings now than they did in 1987. This document contains a collection of a wide variety of DNS-related terms, organized loosely by topic. Some of them have been precisely defined in earlier RFCs, some have been loosely defined in earlier RFCs, and some are not defined in an earlier RFC at all. @@ -702,24 +702,24 @@ assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in [RFC1035] and its successors. It is important to note that the terms "DNS server" and "name server" require context in order to understand the services being provided. Both authoritative servers and recursive resolvers are often called "DNS servers" and "name servers" even though they serve different roles (but may be part of the same software package). - For terminology specific to the public DNS root server system, see + For terminology specific to the global DNS root server system, see [RSSAC026]. That document defines terms such as "root server", "root server operator", and terms that are specific to the way that the - root zone of the public DNS is served. + root zone of the global DNS is served. Resolver: A program "that extract[s] information from name servers in response to client requests." (Quoted from [RFC1034], Section 2.4) A resolver performs queries for a name, type, and class, and receives responses. The logical function is called "resolution". In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. @@ -899,21 +899,21 @@ Stealth server: This is "like a slave server except not listed in an NS RR for the zone." (Quoted from [RFC1996], Section 2.1) Hidden master: A stealth server that is a primary server for zone transfers. "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset." (Quoted from [RFC6781], Section 3.4.3) An earlier RFC, [RFC4641], said that the hidden master's name "appears in the SOA RRs MNAME field", although, in some setups, the name does not appear at all in the - public DNS. A hidden master can also be a secondary server for + global DNS. A hidden master can also be a secondary server for the zone itself. Forwarding: The process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query. Forwarding is a function of a DNS resolver; it is different than simply blindly relaying queries. [RFC5625] does not give a specific definition for forwarding, but describes in detail what features a system that forwards needs to support. Systems that forward are sometimes called "DNS proxies", @@ -993,20 +993,47 @@ commonly referred to as an 'instance'." It goes on to say: "An instance of a server, such as a root server, is often referred to as an 'Anycast instance'." (Quoted from [RSSAC026]) Privacy-enabling DNS server: "A DNS server that implements DNS over TLS [RFC7858] and may optionally implement DNS over DTLS [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS servers might also be considered privacy-enabling, such as those running DNS over HTTPS [RFC8484]. + DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its + successors. + + DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its + successors. + + DNS-over-QUIC (DoQ): DNS over QUIC as defined in + [I-D.ietf-dprive-dnsoquic] + + Classic DNS: DNS over UDP or TCP as defined in [RFC1035] and its + successors. Classic DNS applies to DNS communication between stub + resolvers and recursive resolvers, and between recursive resolvers + and authoritative servers. This has sometimes been called "Do53". + Classic DNS is not encrypted. + + Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for + transport between a stub resolver and a recursive resolver, or + between a recursive resolver and another recursive resolver. This + term is necessary because it is expected that DNS-over-TLS will + later be defined as a transport between recursive resolvers and + authoritative servers, + + Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a + transport between recursive resolvers and authoritative servers, + ADoT specifically means DNS-over-TLS for transport between + recursive resolvers and authoritative servers. + 7. Zones This section defines terms that are used when discussing zones that are being served or retrieved. Zone: "Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone." (Quoted from [RFC1034], Section 2.4) @@ -1136,33 +1163,51 @@ to or (rarely) the same as the zone origin and not subordinate to or the same as the owner name of the NS resource records. Glue records for sibling domains are allowed, but not necessary. For example, a delegation for "child.example.com" in "example.com" zone may have "sibling" name server name "ns.another.example.com". "Out-of-bailiwick" is the antonym of "in-bailiwick". It is a modifier to describe a name server whose name is not subordinate to or the same as the zone origin. Glue records for out-of- - bailiwick name servers are useless. The following table shows - examples of delegation types. + bailiwick name servers are useless. - Delegation |Parent|Name Server Name | Type - -----------+------+------------------+----------------------------- - com | . |a.gtld-servers.net|in-bailiwick / sibling domain - net | . |a.gtld-servers.net|in-bailiwick / in-domain - example.org| org |ns.example.org |in-bailiwick / in-domain - example.org| org |ns.ietf.org |in-bailiwick / sibling domain - example.org| org |ns.example.com |out-of-bailiwick - example.jp | jp |ns.example.jp |in-bailiwick / in-domain - example.jp | jp |ns.example.ne.jp |in-bailiwick / sibling domain - example.jp | jp |ns.example.com |out-of-bailiwick + The following table shows examples of delegation types. + + +=============+========+====================+==================+ + | Delegation | Parent | Name Server Name | Type | + +=============+========+====================+==================+ + | com | . | a.gtld-servers.net | in-bailiwick / | + | | | | sibling domain | + +-------------+--------+--------------------+------------------+ + | net | . | a.gtld-servers.net | in-bailiwick / | + | | | | in-domain | + +-------------+--------+--------------------+------------------+ + | example.org | org | ns.example.org | in-bailiwick / | + | | | | in-domain | + +-------------+--------+--------------------+------------------+ + | example.org | org | ns.ietf.org | in-bailiwick / | + | | | | sibling domain | + +-------------+--------+--------------------+------------------+ + | example.org | org | ns.example.com | out-of-bailiwick | + +-------------+--------+--------------------+------------------+ + | example.jp | jp | ns.example.jp | in-bailiwick / | + | | | | in-domain | + +-------------+--------+--------------------+------------------+ + | example.jp | jp | ns.example.ne.jp | in-bailiwick / | + | | | | sibling domain | + +-------------+--------+--------------------+------------------+ + | example.jp | jp | ns.example.com | out-of-bailiwick | + +-------------+--------+--------------------+------------------+ + + Table 1 Root zone: The zone of a DNS-based tree whose apex is the zero- length label. Also sometimes called "the DNS root". Empty non-terminals (ENT): "Domain names that own no resource records but have subdomains that do." (Quoted from [RFC4592], Section 2.2.2) A typical example is in SRV records: in the name "_sip._tcp.example.com", it is likely that "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV RRset. @@ -1317,21 +1362,21 @@ term is a domain under which subdomains can be registered by third parties and on which HTTP cookies (which are described in detail in [RFC6265]) should not be set. There is no indication in a domain name whether it is a public suffix; that can only be determined by outside means. In fact, both a domain and a subdomain of that domain can be public suffixes. There is nothing inherent in a domain name to indicate whether it is a public suffix. One resource for identifying public suffixes is the Public Suffix List (PSL) maintained by Mozilla - (http://publicsuffix.org/). + (https://publicsuffix.org/). For example, at the time this document is published, the "com.au" domain is listed as a public suffix in the PSL. (Note that this example might change in the future.) Note that the term "public suffix" is controversial in the DNS community for many reasons, and it may be significantly changed in the future. One example of the difficulty of calling a domain a public suffix is that designation can change over time as the registration policy for the zone changes, such as was the case @@ -1778,20 +1823,27 @@ for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . 14.2. Informative References + [I-D.ietf-dprive-dnsoquic] + Huitema, C., Mankin, A., and S. Dickinson, "Specification + of DNS over Dedicated QUIC Connections", Work in Progress, + Internet-Draft, draft-ietf-dprive-dnsoquic-01, 20 October + 2020, . + [IANA_Resource_Registry] IANA, "Resource Record (RR) TYPEs", . [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, DOI 10.17487/RFC0819, August 1982, . [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet @@ -1987,24 +2039,28 @@ Appendix B. Definitions First Defined in This Document The following definitions are first defined in this document: * "Alias" in Section 2 * "Apex" in Section 7 * "arpa" in Section 7 + * "Authoritative DoT (ADot)" in Section 6 + * "Bailiwick" in Section 7 * "Class independent" in Section 5 + * "Classic DNS" in Section 6 + * "Delegation-centric zone" in Section 7 * "Delegation" in Section 7 * "DNS operator" in Section 9 * "DNSSEC-aware" in Section 10 * "DNSSEC-unaware" in Section 10 @@ -2042,20 +2098,22 @@ * "Passive DNS" in Section 6 * "Policy-implementing resolver" in Section 6 * "Presentation format" in Section 5 * "Priming" in Section 6 * "Private DNS" in Section 2 + * "Recrusive DoT (RDot)" in Section 6 + * "Recursive resolver" in Section 6 * "Referrals" in Section 4 * "Registrant" in Section 9 * "Registrar" in Section 9 * "Registry" in Section 9 @@ -2091,20 +2149,22 @@ Numerous people made significant contributions to RFC 8499 and RFC 7719. Please see the acknowledgements sections in those two documents for the extensive list of contributors. Index A C D E F G H I K L M N O P Q R S T U V W Z A + ADoT + ADoT Address records Address records Alias Alias Anycast Anycast Apex Apex Asterisk label Asterisk label @@ -2118,41 +2179,56 @@ arpa: Address and Routing Parameter Area Domain C CNAME CNAME Canonical name Canonical name Child Child Class independent Class independent + Classic DNS + Classic DNS Class Class Closest encloser Closest encloser Closest provable encloser Closest provable encloser Combined signing key (CSK) Combined signing key (CSK) D DNS operator DNS operator + DNS-over-HTTPS + DNS-over-HTTPS + DNS-over-QUIC + DNS-over-QUIC + DNS-over-TLS + DNS-over-TLS DNSSEC Policy (DP) DNSSEC Policy (DP) DNSSEC Practice Statement (DPS) DNSSEC Practice Statement (DPS) DNSSEC-aware and DNSSEC-unaware DNSSEC-aware and DNSSEC-unaware Delegation-centric zone Delegation-centric zone Delegation Delegation + DoH + DoH + + DoQ + DoQ + DoT + DoT Domain name Domain name E EDNS EDNS EPP EPP Empty non-terminals (ENT) Empty non-terminals (ENT) F @@ -2278,26 +2354,30 @@ Private DNS Private DNS Public suffix Public suffix Q QNAME QNAME R RDAP RDAP + RDoT + RDoT REFUSED REFUSED RRset RRset RR RR + Recursive DoT + Recursive DoT Recursive mode Recursive mode Recursive query Recursive query Recursive resolver Recursive resolver Referrals Referrals Registrant Registrant