From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7719.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc7719.txt (limited to 'doc/rfc/rfc7719.txt') diff --git a/doc/rfc/rfc7719.txt b/doc/rfc/rfc7719.txt new file mode 100644 index 0000000..e327092 --- /dev/null +++ b/doc/rfc/rfc7719.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Hoffman +Request for Comments: 7719 ICANN +Category: Informational A. Sullivan +ISSN: 2070-1721 Dyn + K. Fujiwara + JPRS + December 2015 + + + DNS Terminology + +Abstract + + The 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. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7719. + + + + + + + + + + + + + + + + +Hoffman, et al. Informational [Page 1] + +RFC 7719 DNS Terminology December 2015 + + +Copyright Notice + + Copyright (c) 2015 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 + (http://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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 6 + 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 7 + 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 9 + 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 17 + 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 11.2. Informative References . . . . . . . . . . . . . . . . . 24 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 + +1. Introduction + + The Domain Name System (DNS) is a simple query-response protocol + whose messages in both directions have the same format. The protocol + and message format are defined in [RFC1034] and [RFC1035]. These + RFCs defined some terms, but later documents defined others. Some of + the terms from RFCs 1034 and 1035 now have somewhat different + meanings than they did in 1987. + + This document collects a wide variety of DNS-related terms. Some of + them have been precisely defined in earlier RFCs, some have been + loosely defined in earlier RFCs, and some are not defined in any + earlier RFC at all. + + + + + +Hoffman, et al. Informational [Page 2] + +RFC 7719 DNS Terminology December 2015 + + + Most of the definitions here are the consensus definition of the DNS + community -- both protocol developers and operators. Some of the + definitions differ from earlier RFCs, and those differences are + noted. In this document, where the consensus definition is the same + as the one in an RFC, that RFC is quoted. Where the consensus + definition has changed somewhat, the RFC is mentioned but the new + stand-alone definition is given. + + It is important to note that, during the development of this + document, it became clear that some DNS-related terms are interpreted + quite differently by different DNS experts. Further, some terms that + are defined in early DNS RFCs now have definitions that are generally + agreed to, but that are different from the original definitions. + Therefore, the authors intend to follow this document with a + substantial revision in the not-distant future. That revision will + probably have more in-depth discussion of some terms as well as new + terms; it will also update some of the RFCs with new definitions. + + The terms are organized loosely by topic. Some definitions are for + new terms for things that are commonly talked about in the DNS + community but that never had terms defined for them. + + Other organizations sometimes define DNS-related terms their own way. + For example, the W3C defines "domain" at + https://specs.webplatform.org/url/webspecs/develop/. + + Note that there is no single consistent definition of "the DNS". It + can be considered to be some combination of the following: a commonly + used naming scheme for objects on the Internet; a distributed + database representing the names and certain properties of these + objects; an architecture providing distributed maintenance, + resilience, and loose coherency for this database; and a simple + query-response protocol (as mentioned below) implementing this + architecture. + + Capitalization in DNS terms is often inconsistent among RFCs and + various DNS practitioners. The capitalization used in this document + is a best guess at current practices, and is not meant to indicate + that other capitalization styles are wrong or archaic. In some + cases, multiple styles of capitalization are used for the same term + due to quoting from different RFCs. + + + + + + + + + + +Hoffman, et al. Informational [Page 3] + +RFC 7719 DNS Terminology December 2015 + + +2. Names + + Domain name: Section 3.1 of [RFC1034] talks of "the domain name + space" as a tree structure. "Each node has a label, which is zero + to 63 octets in length. ... The domain name of a node is the list + of the labels on the path from the node to the root of the tree. + ... To simplify implementations, the total number of octets that + represent a domain name (i.e., the sum of all label octets and + label lengths) is limited to 255." Any label in a domain name can + contain any octet value. + + Fully qualified domain name (FQDN): This is often just a clear way + of saying the same thing as "domain name of a node", as outlined + above. However, the term is ambiguous. Strictly speaking, a + fully qualified domain name would include every label, including + the final, zero-length label of the root: such a name would be + written "www.example.net." (note the terminating dot). But + because every name eventually shares the common root, names are + often written relative to the root (such as "www.example.net") and + are still called "fully qualified". This term first appeared in + [RFC819]. In this document, names are often written relative to + the root. + + The need for the term "fully qualified domain name" comes from the + existence of partially qualified domain names, which are names + where some of the right-most names are left off and are understood + only by context. + + Label: The identifier of an individual node in the sequence of nodes + identified by a fully qualified domain name. + + Host name: This term and its equivalent, "hostname", have been + widely used but are not defined in [RFC1034], [RFC1035], + [RFC1123], or [RFC2181]. The DNS was originally deployed into the + Host Tables environment as outlined in [RFC952], and it is likely + that the term followed informally from the definition there. Over + time, the definition seems to have shifted. "Host name" is often + meant to be a domain name that follows the rules in Section 3.5 of + [RFC1034], the "preferred name syntax". Note that any label in a + domain name can contain any octet value; hostnames are generally + considered to be domain names where every label follows the rules + in the "preferred name syntax", with the amendment that labels can + start with ASCII digits (this amendment comes from Section 2.1 of + [RFC1123]). + + People also sometimes use the term hostname to refer to just the + first label of an FQDN, such as "printer" in + "printer.admin.example.com". (Sometimes this is formalized in + + + +Hoffman, et al. Informational [Page 4] + +RFC 7719 DNS Terminology December 2015 + + + configuration in operating systems.) In addition, people + sometimes use this term to describe any name that refers to a + machine, and those might include labels that do not conform to the + "preferred name syntax". + + TLD: A Top-Level Domain, meaning a zone that is one layer below the + root, such as "com" or "jp". There is nothing special, from the + point of view of the DNS, about TLDs. Most of them are also + delegation-centric zones, and there are significant policy issues + around their operation. TLDs are often divided into sub-groups + such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level + Domains (gTLDs), and others; the division is a matter of policy, + and beyond the scope of this document. + + IDN: The common abbreviation for "Internationalized Domain Name". + The IDNA protocol is the standard mechanism for handling domain + names with non-ASCII characters in applications in the DNS. The + current standard, normally called "IDNA2008", is defined in + [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These + documents define many IDN-specific terms such as "LDH label", + "A-label", and "U-label". [RFC6365] defines more terms that + relate to internationalization (some of which relate to IDNs), and + [RFC6055] has a much more extensive discussion of IDNs, including + some new terminology. + + Subdomain: "A domain is a subdomain of another domain if it is + contained within that domain. This relationship can be tested by + seeing if the subdomain's name ends with the containing domain's + name." (Quoted from [RFC1034], Section 3.1). For example, in the + host name "nnn.mmm.example.com", both "mmm.example.com" and + "nnn.mmm.example.com" are subdomains of "example.com". + + Alias: The owner of a CNAME resource record, or a subdomain of the + owner of a DNAME resource record [RFC6672]. See also "canonical + name". + + Canonical name: A CNAME resource record "identifies its owner name + as an alias, and specifies the corresponding canonical name in the + RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) + This usage of the word "canonical" is related to the mathematical + concept of "canonical form". + + CNAME: "It is traditional to refer to the owner of a CNAME record as + 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of + 'canonical name', and the owner of a CNAME record is an alias, not + a canonical name." (Quoted from [RFC2181], Section 10.1.1) + + + + + +Hoffman, et al. Informational [Page 5] + +RFC 7719 DNS Terminology December 2015 + + + Public suffix: "A domain that is controlled by a public registry." + (Quoted from [RFC6265], Section 5.3) A common definition for this + term is a domain under which subdomains can be registered, and on + which HTTP cookies ([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. At the + time this document is published, the IETF DBOUND Working Group + [DBOUND] is dealing with issues concerning 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/). + + 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 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 the case of the + "uk" TLD around the time this document is published. + +3. DNS Header and Response Codes + + The header of a DNS message is its first 12 octets. Many of the + fields and flags in the header diagram in Sections 4.1.1 through + 4.1.3 of [RFC1035] are referred to by their names in that diagram. + For example, the response codes are called "RCODEs", the data for a + record is called the "RDATA", and the authoritative answer bit is + often called "the AA flag" or "the AA bit". + + Some of response codes that are defined in [RFC1035] have gotten + their own shorthand names. Some common response code names that + appear without reference to the numeric value are "FORMERR", + "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to + as "Name Error"). All of the RCODEs are listed at + http://www.iana.org/assignments/dns-parameters, although that site + uses mixed-case capitalization, while most documents use all-caps. + + NODATA: "A pseudo RCODE which indicates that the name is valid for + the given class, but there are no records of the given type. A + NODATA response has to be inferred from the answer." (Quoted from + [RFC2308], Section 1.) "NODATA is indicated by an answer with the + RCODE set to NOERROR and no relevant answers in the answer + + + +Hoffman, et al. Informational [Page 6] + +RFC 7719 DNS Terminology December 2015 + + + section. The authority section will contain an SOA record, or + there will be no NS records there." (Quoted from [RFC2308], + Section 2.2.) Note that referrals have a similar format to NODATA + replies; [RFC2308] explains how to distinguish them. + + The term "NXRRSET" is sometimes used as a synonym for NODATA. + However, this is a mistake, given that NXRRSET is a specific error + code defined in [RFC2136]. + + Negative response: A response that indicates that a particular RRset + does not exist, or whose RCODE indicates the nameserver cannot + answer. Sections 2 and 7 of [RFC2308] describe the types of + negative responses in detail. + + Referrals: Data from the authority section of a non-authoritative + answer. [RFC1035] Section 2.1 defines "authoritative" data. + However, referrals at zone cuts (defined in Section 6) are not + authoritative. Referrals may be zone cut NS resource records and + their glue records. NS records on the parent side of a zone cut + are an authoritative delegation, but are normally not treated as + authoritative data. In general, a referral is a way for a server + to send an answer saying that the server does not know the answer, + but knows where the query should be directed in order to get an + answer. Historically, many authoritative servers answered with a + referral to the root zone when queried for a name for which they + were not authoritative, but this practice has declined. + +4. Resource Records + + RR: An acronym for resource record. ([RFC1034], Section 3.6.) + + RRset: A set of resource records with the same label, class and + type, but with different data. (Definition from [RFC2181]) Also + spelled RRSet in some documents. As a clarification, "same label" + in this definition means "same owner name". In addition, + [RFC2181] states that "the TTLs of all RRs in an RRSet must be the + same". (This definition is definitely not the same as "the + response one gets to a query for QTYPE=ANY", which is an + unfortunate misunderstanding.) + + EDNS: The extension mechanisms for DNS, defined in [RFC6891]. + Sometimes called "EDNS0" or "EDNS(0)" to indicate the version + number. EDNS allows DNS clients and servers to specify message + sizes larger than the original 512 octet limit, to expand the + response code space, and potentially to carry additional options + that affect the handling of a DNS query. + + + + + +Hoffman, et al. Informational [Page 7] + +RFC 7719 DNS Terminology December 2015 + + + OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to + contain control information pertaining to the question-and-answer + sequence of a specific transaction. (Definition from [RFC6891], + Section 6.1.1) It is used by EDNS. + + Owner: The domain name where a RR is found ([RFC1034], Section 3.6). + Often appears in the term "owner name". + + SOA field names: DNS documents, including the definitions here, + often refer to the fields in the RDATA of an SOA resource record + by field name. Those fields are defined in Section 3.3.13 of + [RFC1035]. The names (in the order they appear in the SOA RDATA) + are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. + Note that the meaning of MINIMUM field is updated in Section 4 of + [RFC2308]; the new definition is that the MINIMUM field is only + "the TTL to be used for negative responses". This document tends + to use field names instead of terms that describe the fields. + + TTL: The maximum "time to live" of a resource record. "A TTL value + is an unsigned number, with a minimum value of 0, and a maximum + value of 2147483647. That is, a maximum of 2^31 - 1. When + transmitted, the TTL is encoded in the less significant 31 bits of + the 32 bit TTL field, with the most significant, or sign, bit set + to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035] + erroneously stated that this is a signed integer; that was fixed + by [RFC2181].) + + The TTL "specifies the time interval that the resource record may + be cached before the source of the information should again be + consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the + time interval (in seconds) that the resource record may be cached + before it should be discarded". (Quoted from [RFC1035], + Section 4.1.3). Despite being defined for a resource record, the + TTL of every resource record in an RRset is required to be the + same ([RFC2181], Section 5.2). + + The reason that the TTL is the maximum time to live is that a + cache operator might decide to shorten the time to live for + operational purposes, such as if there is a policy to disallow TTL + values over a certain number. Also, if a value is flushed from + the cache when its value is still positive, the value effectively + becomes zero. Some servers are known to ignore the TTL on some + RRsets (such as when the authoritative data has a very short TTL) + even though this is against the advice in RFC 1035. + + + + + + + +Hoffman, et al. Informational [Page 8] + +RFC 7719 DNS Terminology December 2015 + + + There is also the concept of a "default TTL" for a zone, which can + be a configuration parameter in the server software. This is + often expressed by a default for the entire server, and a default + for a zone using the $TTL directive in a zone file. The $TTL + directive was added to the master file format by [RFC2308]. + + Class independent: A resource record type whose syntax and semantics + are the same for every DNS class. A resource record type that is + not class independent has different meanings depending on the DNS + class of the record, or the meaning is undefined for classes other + than IN (class 1, the Internet). + +5. DNS Servers and Clients + + This section defines the terms used for the systems that act as DNS + clients, DNS servers, or both. + + Resolver: A program "that extract[s] information from name servers + in response to client requests." (Quoted from [RFC1034], + Section 2.4) "The resolver is located on the same machine as the + program that requests the resolver's services, but it may need to + consult name servers on other hosts." (Quoted from [RFC1034], + Section 5.1) A resolver performs queries for a name, type, and + class, and receives answers. 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. + + Stub resolver: A resolver that cannot perform all resolution itself. + Stub resolvers generally depend on a recursive resolver to + undertake the actual resolution function. Stub resolvers are + discussed but never fully defined in Section 5.3.1 of [RFC1034]. + They are fully defined in Section 6.1.3.1 of [RFC1123]. + + Iterative mode: A resolution mode of a server that receives DNS + queries and responds with a referral to another server. + Section 2.3 of [RFC1034] describes this as "The server refers the + client to another server and lets the client pursue the query". A + resolver that works in iterative mode is sometimes called an + "iterative resolver". + + Recursive mode: A resolution mode of a server that receives DNS + queries and either responds to those queries from a local cache or + sends queries to other servers in order to get the final answers + to the original queries. Section 2.3 of [RFC1034] describes this + as "The first server pursues the query for the client at another + server". A server operating in recursive mode may be thought of + + + +Hoffman, et al. Informational [Page 9] + +RFC 7719 DNS Terminology December 2015 + + + as having a name server side (which is what answers the query) and + a resolver side (which performs the resolution function). Systems + operating in this mode are commonly called "recursive servers". + Sometimes they are called "recursive resolvers". While strictly + the difference between these is that one of them sends queries to + another recursive server and the other does not, in practice it is + not possible to know in advance whether the server that one is + querying will also perform recursion; both terms can be observed + in use interchangeably. + + Full resolver: This term is used in [RFC1035], but it is not defined + there. RFC 1123 defines a "full-service resolver" that may or may + not be what was intended by "full resolver" in [RFC1035]. This + term is not properly defined in any RFC. + + Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this + term to mean a resolver that acts in recursive mode with a cache + (and meets other requirements). + + Priming: The mechanism used by a resolver to determine where to send + queries before there is anything in the resolver's cache. Priming + is most often done from a configuration setting that contains a + list of authoritative servers for the root zone. + + Negative caching: "The storage of knowledge that something does not + exist, cannot give an answer, or does not give an answer." + (Quoted from [RFC2308], Section 1) + + Authoritative server: "A server that knows the content of a DNS zone + from local knowledge, and thus can answer queries about that zone + without needing to query other servers." (Quoted from [RFC2182], + Section 2.) It is a system that responds to DNS queries with + information about zones for which it has been configured to answer + with the AA flag in the response header set to 1. It is a server + that has authority over one or more DNS zones. Note that it is + possible for an authoritative server to respond to a query without + the parent zone delegating authority to that server. + Authoritative servers also provide "referrals", usually to child + zones delegated from them; these referrals have the AA bit set to + 0 and come with referral data in the Authority and (if needed) the + Additional sections. + + Authoritative-only server: A name server that only serves + authoritative data and ignores requests for recursion. It will + "not normally generate any queries of its own. Instead, it + answers non-recursive queries from iterative resolvers looking for + information in zones it serves." (Quoted from [RFC4697], + Section 2.4) + + + +Hoffman, et al. Informational [Page 10] + +RFC 7719 DNS Terminology December 2015 + + + Zone transfer: The act of a client requesting a copy of a zone and + an authoritative server sending the needed information. (See + Section 6 for a description of zones.) There are two common + standard ways to do zone transfers: the AXFR ("Authoritative + Transfer") mechanism to copy the full zone (described in + [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy + only parts of the zone that have changed (described in [RFC1995]). + Many systems use non-standard methods for zone transfer outside + the DNS protocol. + + Secondary server: "An authoritative server which uses zone transfer + to retrieve the zone" (Quoted from [RFC1996], Section 2.1). + [RFC2182] describes secondary servers in detail. Although early + DNS RFCs such as [RFC1996] referred to this as a "slave", the + current common usage has shifted to calling it a "secondary". + Secondary servers are also discussed in [RFC1034]. + + Slave server: See secondary server. + + Primary server: "Any authoritative server configured to be the + source of zone transfer for one or more [secondary] servers" + (Quoted from [RFC1996], Section 2.1) or, more specifically, "an + authoritative server configured to be the source of AXFR or IXFR + data for one or more [secondary] servers" (Quoted from [RFC2136]). + Although early DNS RFCs such as [RFC1996] referred to this as a + "master", the current common usage has shifted to "primary". + Primary servers are also discussed in [RFC1034]. + + Master server: See primary server. + + Primary master: "The primary master is named in the zone's SOA MNAME + field and optionally by an NS RR". (Quoted from [RFC1996], + Section 2.1). [RFC2136] defines "primary master" as "Master + server at the root of the AXFR/IXFR dependency graph. The primary + master is named in the zone's SOA MNAME field and optionally by an + NS RR. There is by definition only one primary master server per + zone." The idea of a primary master is only used by [RFC2136], + and is considered archaic in other parts of the DNS. + + Stealth server: This is "like a slave server except not listed in an + NS RR for the zone." (Quoted from [RFC1996], Section 2.1) + + + + + + + + + + +Hoffman, et al. Informational [Page 11] + +RFC 7719 DNS Terminology December 2015 + + + Hidden master: A stealth server that is a master 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 be either a secondary or a primary master. + + 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 need to + support. Systems that forward are sometimes called "DNS proxies", + but that term has not yet been defined (even in [RFC5625]). + + Forwarder: Section 1 of [RFC2308] describes a forwarder as "a + nameserver used to resolve queries instead of directly using the + authoritative nameserver chain". [RFC2308] further says "The + forwarder typically either has better access to the internet, or + maintains a bigger cache which may be shared amongst many + resolvers." That definition appears to suggest that forwarders + normally only query authoritative servers. In current use, + however, forwarders often stand between stub resolvers and + recursive servers. [RFC2308] is silent on whether a forwarder is + iterative-only or can be a full-service resolver. + + Policy-implementing resolver: A resolver acting in recursive mode + that changes some of the answers that it returns based on policy + criteria, such as to prevent access to malware sites or + objectionable content. In general, a stub resolver has no idea + whether upstream resolvers implement such policy or, if they do, + the exact policy about what changes will be made. In some cases, + the user of the stub resolver has selected the policy-implementing + resolver with the explicit intention of using it to implement the + policies. In other cases, policies are imposed without the user + of the stub resolver being informed. + + Open resolver: A full-service resolver that accepts and processes + queries from any (or nearly any) stub resolver. This is sometimes + also called a "public resolver", although the term "public + resolver" is used more with open resolvers that are meant to be + open, as compared to the vast majority of open resolvers that are + probably misconfigured to be open. + + + + +Hoffman, et al. Informational [Page 12] + +RFC 7719 DNS Terminology December 2015 + + + View: A configuration for a DNS server that allows it to provide + different answers depending on attributes of the query. + Typically, views differ by the source IP address of a query, but + can also be based on the destination IP address, the type of query + (such as AXFR), whether it is recursive, and so on. Views are + often used to provide more names or different addresses to queries + from "inside" a protected network than to those "outside" that + network. Views are not a standardized part of the DNS, but they + are widely implemented in server software. + + Passive DNS: A mechanism to collect large amounts of DNS data by + storing DNS responses from servers. Some of these systems also + collect the DNS queries associated with the responses; this can + raise privacy issues. Passive DNS databases can be used to answer + historical questions about DNS zones such as which records were + available for them at what times in the past. Passive DNS + databases allow searching of the stored records on keys other than + just the name, such as "find all names which have A records of a + particular value". + + Anycast: "The practice of making a particular service address + available in multiple, discrete, autonomous locations, such that + datagrams sent are routed to one of several available locations." + (Quoted from [RFC4786], Section 2) + +6. 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) + + Child: "The entity on record that has the delegation of the domain + from the Parent." (Quoted from [RFC7344], Section 1.1) + + Parent: "The domain in which the Child is registered." (Quoted from + [RFC7344], Section 1.1) Earlier, "parent name server" was defined + in [RFC882] as "the name server that has authority over the place + in the domain name space that will hold the new domain". (Note + that [RFC882] was obsoleted by [RFC1034] and [RFC1035].) [RFC819] + also has some description of the relationship between parents and + children. + + + + + + +Hoffman, et al. Informational [Page 13] + +RFC 7719 DNS Terminology December 2015 + + + Origin: + + (a) "The domain name that appears at the top of a zone (just below + the cut that separates the zone from its parent). The name of the + zone is the same as the name of the domain at the zone's origin." + (Quoted from [RFC2181], Section 6.) These days, this sense of + "origin" and "apex" (defined below) are often used + interchangeably. + + (b) The domain name within which a given relative domain name + appears in zone files. Generally seen in the context of + "$ORIGIN", which is a control entry defined in [RFC1035], + Section 5.1, as part of the master file format. For example, if + the $ORIGIN is set to "example.org.", then a master file line for + "www" is in fact an entry for "www.example.org.". + + Apex: The point in the tree at an owner of an SOA and corresponding + authoritative NS RRset. This is also called the "zone apex". + [RFC4033] defines it as "the name at the child's side of a zone + cut". The "apex" can usefully be thought of as a data-theoretic + description of a tree structure, and "origin" is the name of the + same concept when it is implemented in zone files. The + distinction is not always maintained in use, however, and one can + find uses that conflict subtly with this definition. [RFC1034] + uses the term "top node of the zone" as a synonym of "apex", but + that term is not widely used. These days, the first sense of + "origin" (above) and "apex" are often used interchangeably. + + Zone cut: The delimitation point between two zones where the origin + of one of the zones is the child of the other zone. + + "Zones are delimited by 'zone cuts'. Each zone cut separates a + 'child' zone (below the cut) from a 'parent' zone (above the cut). + (Quoted from [RFC2181], Section 6; note that this is barely an + ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as + 'zone cut'." + + Delegation: The process by which a separate zone is created in the + name space beneath the apex of a given domain. Delegation happens + when an NS RRset is added in the parent zone for the child origin. + Delegation inherently happens at a zone cut. The term is also + commonly a noun: the new zone that is created by the act of + delegating. + + + + + + + + +Hoffman, et al. Informational [Page 14] + +RFC 7719 DNS Terminology December 2015 + + + Glue records: "[Resource records] which are not part of the + authoritative data [of the zone], and are address resource records + for the [name servers in subzones]. These RRs are only necessary + if the name server's name is 'below' the cut, and are only used as + part of a referral response." Without glue "we could be faced + with the situation where the NS RRs tell us that in order to learn + a name server's address, we should contact the server using the + address we wish to learn." (Definition from [RFC1034], + Section 4.2.1) + + A later definition is that glue "includes any record in a zone + file that is not properly part of that zone, including nameserver + records of delegated sub-zones (NS records), address records that + accompany those NS records (A, AAAA, etc), and any other stray + data that might appear" ([RFC2181], Section 5.4.1). Although glue + is sometimes used today with this wider definition in mind, the + context surrounding the [RFC2181] definition suggests it is + intended to apply to the use of glue within the document itself + and not necessarily beyond. + + In-bailiwick: + + (a) An adjective to describe a name server whose name is either + subordinate to or (rarely) the same as the zone origin. In- + bailiwick name servers require glue records in their parent zone + (using the first of the definitions of "glue records" in the + definition above). + + (b) Data for which the server is either authoritative, or else + authoritative for an ancestor of the owner name. This sense of + the term normally is used when discussing the relevancy of glue + records in a response. For example, the server for the parent + zone "example.com" might reply with glue records for + "ns.child.example.com". Because the "child.example.com" zone is a + descendant of the "example.com" zone, the glue records are in- + bailiwick. + + Out-of-bailiwick: The antonym of in-bailiwick. + + Authoritative data: "All of the RRs attached to all of the nodes + from the top node of the zone down to leaf nodes or nodes above + cuts around the bottom edge of the zone." (Quoted from [RFC1034], + Section 4.2.1) It is noted that this definition might + inadvertently also include any NS records that appear in the zone, + even those that might not truly be authoritative because there are + identical NS RRs below the zone cut. This reveals the ambiguity + + + + + +Hoffman, et al. Informational [Page 15] + +RFC 7719 DNS Terminology December 2015 + + + in the notion of authoritative data, because the parent-side NS + records authoritatively indicate the delegation, even though they + are not themselves authoritative data. + + Root zone: The zone whose apex is the zero-length label. Also + sometimes called "the DNS root". + + Empty non-terminals: "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. + + Delegation-centric zone: A zone that consists mostly of delegations + to child zones. This term is used in contrast to a zone that + might have some delegations to child zones, but also has many data + resource records for the zone itself and/or for child zones. The + term is used in [RFC4956] and [RFC5155], but is not defined there. + + Wildcard: [RFC1034] defined "wildcard", but in a way that turned out + to be confusing to implementers. Special treatment is given to + RRs with owner names starting with the label "*". "Such RRs are + called 'wildcards'. Wildcard RRs can be thought of as + instructions for synthesizing RRs." (Quoted from [RFC1034], + Section 4.3.3) For an extended discussion of wildcards, including + clearer definitions, see [RFC4592]. + + Occluded name: "The addition of a delegation point via dynamic + update will render all subordinate domain names to be in a limbo, + still part of the zone, but not available to the lookup process. + The addition of a DNAME resource record has the same impact. The + subordinate names are said to be 'occluded'." (Quoted from + [RFC5936], Section 3.5) + + Fast flux DNS: This "occurs when a domain is found in DNS using A + records to multiple IP addresses, each of which has a very short + Time-to-Live (TTL) value associated with it. This means that the + domain resolves to varying IP addresses over a short period of + time." (Quoted from [RFC6561], Section 1.1.5, with typo + corrected) It is often used to deliver malware. Because the + addresses change so rapidly, it is difficult to ascertain all the + hosts. It should be noted that the technique also works with AAAA + records, but such use is not frequently observed on the Internet + as of this writing. + + + + + + +Hoffman, et al. Informational [Page 16] + +RFC 7719 DNS Terminology December 2015 + + +7. Registration Model + + Registry: The administrative operation of a zone that allows + registration of names within that zone. People often use this + term to refer only to those organizations that perform + registration in large delegation-centric zones (such as TLDs); but + formally, whoever decides what data goes into a zone is the + registry for that zone. This definition of "registry" is from a + DNS point of view; for some zones, the policies that determine + what can go in the zone are decided by superior zones and not the + registry operator. + + Registrant: An individual or organization on whose behalf a name in + a zone is registered by the registry. In many zones, the registry + and the registrant may be the same entity, but in TLDs they often + are not. + + Registrar: A service provider that acts as a go-between for + registrants and registries. Not all registrations require a + registrar, though it is common to have registrars involved in + registrations in TLDs. + + EPP: The Extensible Provisioning Protocol (EPP), which is commonly + used for communication of registration information between + registries and registrars. EPP is defined in [RFC5730]. + + WHOIS: A protocol specified in [RFC3912], often used for querying + registry databases. WHOIS data is frequently used to associate + registration data (such as zone management contacts) with domain + names. The term "WHOIS data" is often used as a synonym for the + registry database, even though that database may be served by + different protocols, particularly RDAP. The WHOIS protocol is + also used with IP address registry data. + + RDAP: The Registration Data Access Protocol, defined in [RFC7480], + [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The + RDAP protocol and data format are meant as a replacement for + WHOIS. + + DNS operator: An entity responsible for running DNS servers. For a + zone's authoritative servers, the registrant may act as their own + DNS operator, or their registrar may do it on their behalf, or + they may use a third-party operator. For some zones, the registry + function is performed by the DNS operator plus other entities who + decide about the allowed contents of the zone. + + + + + + +Hoffman, et al. Informational [Page 17] + +RFC 7719 DNS Terminology December 2015 + + +8. General DNSSEC + + Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and + [RFC5155]. The terms that have caused confusion in the DNS community + are highlighted here. + + DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in + some RFCs, have not been formally defined. However, Section 2 of + [RFC4033] defines many types of resolvers and validators, + including "non-validating security-aware stub resolver", "non- + validating stub resolver", "security-aware name server", + "security-aware recursive name server", "security-aware resolver", + "security-aware stub resolver", and "security-oblivious + 'anything'". (Note that the term "validating resolver", which is + used in some places in DNSSEC-related documents, is also not + defined.) + + Signed zone: "A zone whose RRsets are signed and that contains + properly constructed DNSKEY, Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) DS records." (Quoted from + [RFC4033], Section 2.) It has been noted in other contexts that + the zone itself is not really signed, but all the relevant RRsets + in the zone are signed. Nevertheless, if a zone that should be + signed contains any RRsets that are not signed (or opted out), + those RRsets will be treated as bogus, so the whole zone needs to + be handled in some way. + + It should also be noted that, since the publication of [RFC6840], + NSEC records are no longer required for signed zones: a signed + zone might include NSEC3 records instead. [RFC7129] provides + additional background commentary and some context for the NSEC and + NSEC3 mechanisms used by DNSSEC to provide authenticated denial- + of-existence responses. + + Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that + is not signed". Section 2 of [RFC4035] defines this as "A zone + that does not include these records [properly constructed DNSKEY, + Resource Record Signature (RRSIG), Next Secure (NSEC), and + (optionally) DS records] according to the rules in this section". + There is an important note at the end of Section 5.2 of [RFC4035] + that defines an additional situation in which a zone is considered + unsigned: "If the resolver does not support any of the algorithms + listed in an authenticated DS RRset, then the resolver will not be + able to verify the authentication path to the child zone. In this + case, the resolver SHOULD treat the child zone as if it were + unsigned." + + + + + +Hoffman, et al. Informational [Page 18] + +RFC 7719 DNS Terminology December 2015 + + + NSEC: "The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non- + existence with the same mechanisms used to authenticate other DNS + replies." (Quoted from [RFC4033], Section 3.2.) In short, an + NSEC record provides authenticated denial of existence. + + "The NSEC resource record lists two separate things: the next + owner name (in the canonical ordering of the zone) that contains + authoritative data or a delegation point NS RRset, and the set of + RR types present at the NSEC RR's owner name." (Quoted from + Section 4 of RFC 4034) + + NSEC3: Like the NSEC record, the NSEC3 record also provides + authenticated denial of existence; however, NSEC3 records mitigate + against zone enumeration and support Opt-Out. NSEC3 resource + records are defined in [RFC5155]. + + Note that [RFC6840] says that [RFC5155] "is now considered part of + the DNS Security Document Family as described by Section 10 of + [RFC4033]". This means that some of the definitions from earlier + RFCs that only talk about NSEC records should probably be + considered to be talking about both NSEC and NSEC3. + + Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover + unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.) + Opt-out tackles the high costs of securing a delegation to an + insecure zone. When using Opt-Out, names that are an insecure + delegation (and empty non-terminals that are only derived from + insecure delegations) don't require an NSEC3 record or its + corresponding RRSIG records. Opt-Out NSEC3 records are not able + to prove or deny the existence of the insecure delegations. + (Adapted from [RFC7129], Section 5.1) + + Zone enumeration: "The practice of discovering the full content of a + zone via successive queries." (Quoted from [RFC5155], + Section 1.3.) This is also sometimes called "zone walking". Zone + enumeration is different from zone content guessing where the + guesser uses a large dictionary of possible labels and sends + successive queries for them, or matches the contents of NSEC3 + records against such a dictionary. + + Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY + RRset in a zone."(Quoted from [RFC6781], Section 3.1) + + + + + + + + +Hoffman, et al. Informational [Page 19] + +RFC 7719 DNS Terminology December 2015 + + + Zone signing key (ZSK): "DNSSEC keys that can be used to sign all + the RRsets in a zone that require signatures, other than the apex + DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the + roles KSK and ZSK are not mutually exclusive: a single key can be + both KSK and ZSK at the same time. Also note that a ZSK is + sometimes used to sign the apex DNSKEY RRset. + + Combined signing key (CSK): "In cases where the differentiation + between the KSK and ZSK is not made, i.e., where keys have the + role of both KSK and ZSK, we talk about a Single-Type Signing + Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes + called a "combined signing key" or CSK. It is operational + practice, not protocol, that determines whether a particular key + is a ZSK, a KSK, or a CSK. + + Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be + used to distinguish between keys that are intended to be used as + the secure entry point into the zone when building chains of + trust, i.e., they are (to be) pointed to by parental DS RRs or + configured as a trust anchor. Therefore, it is suggested that the + SEP flag be set on keys that are used as KSKs and not on keys that + are used as ZSKs, while in those cases where a distinction between + a KSK and ZSK is not made (i.e., for a Single-Type Signing + Scheme), it is suggested that the SEP flag be set on all keys." + (Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is + only a hint, and its presence or absence may not be used to + disqualify a given DNSKEY RR from use as a KSK or ZSK during + validation. + + DNSSEC Policy (DP): A statement that "sets forth the security + requirements and standards to be implemented for a DNSSEC-signed + zone." (Quoted from [RFC6841], Section 2) + + DNSSEC Practice Statement (DPS): "A practices disclosure document + that may support and be a supplemental document to the DNSSEC + Policy (if such exists), and it states how the management of a + given zone implements procedures and controls at a high level." + (Quoted from [RFC6841], Section 2) + +9. DNSSEC States + + A validating resolver can determine that a response is in one of four + states: secure, insecure, bogus, or indeterminate. These states are + defined in [RFC4033] and [RFC4035], although the two definitions + differ a bit. This document makes no effort to reconcile the two + definitions, and takes no position as to whether they need to be + reconciled. + + + + +Hoffman, et al. Informational [Page 20] + +RFC 7719 DNS Terminology December 2015 + + + Section 5 of [RFC4033] says: + + A validating resolver can determine the following 4 states: + + Secure: The validating resolver has a trust anchor, has a chain + of trust, and is able to verify all the signatures in the + response. + + Insecure: The validating resolver has a trust anchor, a chain + of trust, and, at some delegation point, signed proof of the + non-existence of a DS record. This indicates that subsequent + branches in the tree are provably insecure. A validating + resolver may have a local policy to mark parts of the domain + space as insecure. + + Bogus: The validating resolver has a trust anchor and a secure + delegation indicating that subsidiary data is signed, but + the response fails to validate for some reason: missing + signatures, expired signatures, signatures with unsupported + algorithms, data missing that the relevant NSEC RR says + should be present, and so forth. + + Indeterminate: There is no trust anchor that would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + Section 4.3 of [RFC4035] says: + + A security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain + of signed DNSKEY and DS RRs from a trusted security anchor to + the RRset. In this case, the RRset should be signed and is + subject to signature validation, as described above. + + Insecure: An RRset for which the resolver knows that it has no + chain of signed DNSKEY and DS RRs from any trusted starting + point to the RRset. This can occur when the target RRset lies + in an unsigned zone or in a descendent [sic] of an unsigned + zone. In this case, the RRset may or may not be signed, but + the resolver will not be able to verify the signature. + + + + + + + + + +Hoffman, et al. Informational [Page 21] + +RFC 7719 DNS Terminology December 2015 + + + Bogus: An RRset for which the resolver believes that it ought to + be able to establish a chain of trust but for which it is + unable to do so, either due to signatures that for some reason + fail to validate or due to missing data that the relevant + DNSSEC RRs indicate should be present. This case may indicate + an attack but may also indicate a configuration error or some + form of data corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether the RRset should be signed, as the resolver + is not able to obtain the necessary DNSSEC RRs. This can occur + when the security-aware resolver is not able to contact + security-aware name servers for the relevant zones. + +10. Security Considerations + + These definitions do not change any security considerations for the + DNS. + +11. References + +11.1. Normative References + + [RFC882] Mockapetris, P., "Domain names: Concepts and facilities", + RFC 882, DOI 10.17487/RFC0882, November 1983, + . + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + DOI 10.17487/RFC1123, October 1989, + . + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, + August 1996, . + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, DOI 10.17487/RFC2136, April 1997, + . + + + +Hoffman, et al. Informational [Page 22] + +RFC 7719 DNS Terminology December 2015 + + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, + . + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + DOI 10.17487/RFC2182, July 1997, + . + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, + . + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + . + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, DOI 10.17487/RFC4034, March 2005, + . + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + . + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, DOI 10.17487/RFC4592, July 2006, + . + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, + . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol + (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, + . + + + + + + + +Hoffman, et al. Informational [Page 23] + +RFC 7719 DNS Terminology December 2015 + + + [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, + "Recommendations for the Remediation of Bots in ISP + Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, + . + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + . + + [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC + Operational Practices, Version 2", RFC 6781, + DOI 10.17487/RFC6781, December 2012, + . + + [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and + Implementation Notes for DNS Security (DNSSEC)", RFC 6840, + DOI 10.17487/RFC6840, February 2013, + . + + [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A + Framework for DNSSEC Policies and DNSSEC Practice + Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, + . + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + . + + [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating + DNSSEC Delegation Trust Maintenance", RFC 7344, + DOI 10.17487/RFC7344, September 2014, + . + +11.2. Informative References + + [DBOUND] IETF, "Domain Boundaries (dbound) Working Group", 2015, + . + + [RFC819] Su, Z. and J. Postel, "The Domain Naming Convention for + Internet User Applications", RFC 819, + DOI 10.17487/RFC0819, August 1982, + . + + [RFC952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet + host table specification", RFC 952, DOI 10.17487/RFC0952, + October 1985, . + + + + +Hoffman, et al. Informational [Page 24] + +RFC 7719 DNS Terminology December 2015 + + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + DOI 10.17487/RFC1995, August 1996, + . + + [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, + DOI 10.17487/RFC3912, September 2004, + . + + [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + RFC 4641, DOI 10.17487/RFC4641, September 2006, + . + + [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, + October 2006, . + + [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast + Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, + December 2006, . + + [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security + (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July + 2007, . + + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", + BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, + . + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + . + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and + Internationalized Domain Names for Applications (IDNA)", + RFC 5892, DOI 10.17487/RFC5892, August 2010, + . + + [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts + for Internationalized Domain Names for Applications + (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, + . + + + + +Hoffman, et al. Informational [Page 25] + +RFC 7719 DNS Terminology December 2015 + + + [RFC5894] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Background, Explanation, and + Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, + . + + [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on + Encodings for Internationalized Domain Names", RFC 6055, + DOI 10.17487/RFC6055, February 2011, + . + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + DOI 10.17487/RFC6265, April 2011, + . + + [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in + Internationalization in the IETF", BCP 166, RFC 6365, + DOI 10.17487/RFC6365, September 2011, + . + + [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of + Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, + February 2014, . + + [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the + Registration Data Access Protocol (RDAP)", RFC 7480, + DOI 10.17487/RFC7480, March 2015, + . + + [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the + Registration Data Access Protocol (RDAP)", RFC 7481, + DOI 10.17487/RFC7481, March 2015, + . + + [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access + Protocol (RDAP) Query Format", RFC 7482, + DOI 10.17487/RFC7482, March 2015, + . + + [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the + Registration Data Access Protocol (RDAP)", RFC 7483, + DOI 10.17487/RFC7483, March 2015, + . + + [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data + (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March + 2015, . + + + + + +Hoffman, et al. Informational [Page 26] + +RFC 7719 DNS Terminology December 2015 + + + [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, + "Inventory and Analysis of WHOIS Registration Objects", + RFC 7485, DOI 10.17487/RFC7485, March 2015, + . + +Acknowledgements + + The authors gratefully acknowledge all of the authors of DNS-related + RFCs that proceed this one. Comments from Tony Finch, Stephane + Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John + Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, + David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, + John Klensin, David Black, and many others in the DNSOP Working Group + have helped shape this document. + +Authors' Addresses + + Paul Hoffman + ICANN + + Email: paul.hoffman@icann.org + + + Andrew Sullivan + Dyn + 150 Dow Street, Tower 2 + Manchester, NH 03101 + United States + + Email: asullivan@dyn.com + + + Kazunori Fujiwara + Japan Registry Services Co., Ltd. + Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda + Chiyoda-ku, Tokyo 101-0065 + Japan + + Phone: +81 3 5215 8451 + Email: fujiwara@jprs.co.jp + + + + + + + + + + + +Hoffman, et al. Informational [Page 27] + -- cgit v1.2.3