idnits 2.17.1 draft-ietf-dnsop-rfc8499bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 605: '... An RRset MAY have multiple RRS...' RFC 2119 keyword, line 1440: '...se, the resolver SHOULD treat the chil...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2308, updated by this document, for RFC5378 checks: 1997-01-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 June 2021) is 1030 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC20' is mentioned on line 1277, but not defined == Missing Reference: 'DNSSEC' is mentioned on line 1528, but not defined ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Downref: Normative reference to an Informational RFC: RFC 6561 ** Downref: Normative reference to an Informational RFC: RFC 6781 ** Downref: Normative reference to an Informational RFC: RFC 6841 ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 -- Obsolete informational reference (is this intentional?): RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) -- Obsolete informational reference (is this intentional?): RFC 7482 (Obsoleted by RFC 9082) -- Obsolete informational reference (is this intentional?): RFC 7483 (Obsoleted by RFC 9083) -- Obsolete informational reference (is this intentional?): RFC 7484 (Obsoleted by RFC 9224) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Obsoletes: 8499 (if approved) K. Fujiwara 5 Updates: 2308 (if approved) JPRS 6 Intended status: Best Current Practice 24 June 2021 7 Expires: 26 December 2021 9 DNS Terminology 10 draft-ietf-dnsop-rfc8499bis-02 12 Abstract 14 The Domain Name System (DNS) is defined in literally dozens of 15 different RFCs. The terminology used by implementers and developers 16 of DNS protocols, and by operators of DNS systems, has sometimes 17 changed in the decades since the DNS was first defined. This 18 document gives current definitions for many of the terms used in the 19 DNS in a single document. 21 This document obsoletes RFC 8499 and updates RFC 2308. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 26 December 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 59 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 60 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13 61 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 15 62 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 63 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 27 64 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 28 65 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 30 66 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 35 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 37 71 14.2. Informative References . . . . . . . . . . . . . . . . . 40 72 Appendix A. Definitions Updated by This Document . . . . . . . . 45 73 Appendix B. Definitions First Defined in This Document . . . . . 45 74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 77 1. Introduction 79 The Domain Name System (DNS) is a simple query-response protocol 80 whose messages in both directions have the same format. (Section 2 81 gives a definition of "global DNS", which is often what people mean 82 when they say "the DNS".) The protocol and message format are 83 defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, 84 and later documents defined others. Some of the terms from [RFC1034] 85 and [RFC1035] have somewhat different meanings now than they did in 86 1987. 88 This document contains a collection of a wide variety of DNS-related 89 terms, organized loosely by topic. Some of them have been precisely 90 defined in earlier RFCs, some have been loosely defined in earlier 91 RFCs, and some are not defined in an earlier RFC at all. 93 Other organizations sometimes define DNS-related terms their own way. 94 For example, the WHATWG defines "domain" at 95 . The Root Server System Advisory 96 Committee (RSSAC) has a good lexicon [RSSAC026]. 98 Most of the definitions listed here represent the consensus 99 definition of the DNS community -- both protocol developers and 100 operators. Some of the definitions differ from earlier RFCs, and 101 those differences are noted. In this document, where the consensus 102 definition is the same as the one in an RFC, that RFC is quoted. 103 Where the consensus definition has changed somewhat, the RFC is 104 mentioned but the new stand-alone definition is given. See 105 Appendix A for a list of the definitions that this document updates. 107 It is important to note that, during the development of this 108 document, it became clear that some DNS-related terms are interpreted 109 quite differently by different DNS experts. Further, some terms that 110 are defined in early DNS RFCs now have definitions that are generally 111 agreed to, but that are different from the original definitions. 112 This document is a small revision to [RFC8499]; that document was a 113 substantial revision to [RFC7719]. 115 Note that there is no single consistent definition of "the DNS". It 116 can be considered to be some combination of the following: a commonly 117 used naming scheme for objects on the Internet; a distributed 118 database representing the names and certain properties of these 119 objects; an architecture providing distributed maintenance, 120 resilience, and loose coherency for this database; and a simple 121 query-response protocol (as mentioned below) implementing this 122 architecture. Section 2 defines "global DNS" and "private DNS" as a 123 way to deal with these differing definitions. 125 Capitalization in DNS terms is often inconsistent among RFCs and 126 various DNS practitioners. The capitalization used in this document 127 is a best guess at current practices, and is not meant to indicate 128 that other capitalization styles are wrong or archaic. In some 129 cases, multiple styles of capitalization are used for the same term 130 due to quoting from different RFCs. 132 Readers should note that the terms in this document are grouped by 133 topic. Someone who is not already familiar with the DNS probably 134 cannot learn about the DNS from scratch by reading this document from 135 front to back. Instead, skipping around may be the only way to get 136 enough context to understand some of the definitions. This document 137 has an index that might be useful for readers who are attempting to 138 learn the DNS by reading this document. 140 2. Names 142 Naming system: A naming system associates names with data. Naming 143 systems have many significant facets that help differentiate them 144 from each other. Some commonly identified facets include: 146 * Composition of names 148 * Format of names 150 * Administration of names 152 * Types of data that can be associated with names 154 * Types of metadata for names 156 * Protocol for getting data from a name 158 * Context for resolving a name 160 Note that this list is a small subset of facets that people have 161 identified over time for naming systems, and the IETF has yet to 162 agree on a good set of facets that can be used to compare naming 163 systems. For example, other facets might include "protocol to 164 update data in a name", "privacy of names", and "privacy of data 165 associated with names", but those are not as well defined as the 166 ones listed above. The list here is chosen because it helps 167 describe the DNS and naming systems similar to the DNS. 169 Domain name: An ordered list of one or more labels. 171 Note that this is a definition independent of the DNS RFCs 172 ([RFC1034] and [RFC1035]), and the definition here also applies to 173 systems other than the DNS. [RFC1034] defines the "domain name 174 space" using mathematical trees and their nodes in graph theory, 175 and that definition has the same practical result as the 176 definition here. Any path of a directed acyclic graph can be 177 represented by a domain name consisting of the labels of its 178 nodes, ordered by decreasing distance from the root(s) (which is 179 the normal convention within the DNS, including this document). A 180 domain name whose last label identifies a root of the graph is 181 fully qualified; other domain names whose labels form a strict 182 prefix of a fully-qualified domain name are relative to its first 183 omitted node. 185 Also note that different IETF and non-IETF documents have used the 186 term "domain name" in many different ways. It is common for 187 earlier documents to use "domain name" to mean "names that match 188 the syntax in [RFC1035]", but possibly with additional rules such 189 as "and are, or will be, resolvable in the global DNS" or "but 190 only using the presentation format". 192 Label: An ordered list of zero or more octets that makes up a 193 portion of a domain name. Using graph theory, a label identifies 194 one node in a portion of the graph of all possible domain names. 196 Global DNS: Using the short set of facets listed in "Naming system", 197 the global DNS can be defined as follows. Most of the rules here 198 come from [RFC1034] and [RFC1035], although the term "global DNS" 199 has not been defined before now. 201 Composition of names: A name in the global DNS has one or more 202 labels. The length of each label is between 0 and 63 octets 203 inclusive. In a fully-qualified domain name, the last label in 204 the ordered list is 0 octets long; it is the only label whose 205 length may be 0 octets, and it is called the "root" or "root 206 label". A domain name in the global DNS has a maximum total 207 length of 255 octets in the wire format; the root represents one 208 octet for this calculation. (Multicast DNS [RFC6762] allows names 209 up to 255 bytes plus a terminating zero byte based on a different 210 interpretation of RFC 1035 and what is included in the 255 211 octets.) 213 Format of names: Names in the global DNS are domain names. There 214 are three formats: wire format, presentation format, and common 215 display. 217 The basic wire format for names in the global DNS is a list of 218 labels ordered by decreasing distance from the root, with the 219 root label last. Each label is preceded by a length octet. 220 [RFC1035] also defines a compression scheme that modifies this 221 format. 223 The presentation format for names in the global DNS is a list 224 of labels ordered by decreasing distance from the root, encoded 225 as ASCII, with a "." character between each label. In 226 presentation format, a fully-qualified domain name includes the 227 root label and the associated separator dot. For example, in 228 presentation format, a fully-qualified domain name with two 229 non-root labels is always shown as "example.tld." instead of 230 "example.tld". [RFC1035] defines a method for showing octets 231 that do not display in ASCII. 233 The common display format is used in applications and free 234 text. It is the same as the presentation format, but showing 235 the root label and the "." before it is optional and is rarely 236 done. For example, in common display format, a fully-qualified 237 domain name with two non-root labels is usually shown as 238 "example.tld" instead of "example.tld.". Names in the common 239 display format are normally written such that the 240 directionality of the writing system presents labels by 241 decreasing distance from the root (so, in both English and the 242 C programming language the root or Top-Level Domain (TLD) label 243 in the ordered list is rightmost; but in Arabic, it may be 244 leftmost, depending on local conventions). 246 Administration of names: Administration is specified by delegation 247 (see the definition of "delegation" in Section 7). Policies for 248 administration of the root zone in the global DNS are determined 249 by the names operational community, which convenes itself in the 250 Internet Corporation for Assigned Names and Numbers (ICANN). The 251 names operational community selects the IANA Functions Operator 252 for the global DNS root zone. At the time of writing, that 253 operator is Public Technical Identifiers (PTI). (See 254 for more information about PTI operating 255 the IANA Functions.) The name servers that serve the root zone 256 are provided by independent root operators. Other zones in the 257 global DNS have their own policies for administration. 259 Types of data that can be associated with names: A name can have 260 zero or more resource records associated with it. There are 261 numerous types of resource records with unique data structures 262 defined in many different RFCs and in the IANA registry at 263 [IANA_Resource_Registry]. 265 Types of metadata for names: Any name that is published in the DNS 266 appears as a set of resource records (see the definition of 267 "RRset" in Section 5). Some names do not, themselves, have data 268 associated with them in the DNS, but they "appear" in the DNS 269 anyway because they form part of a longer name that does have data 270 associated with it (see the definition of "empty non-terminals" in 271 Section 7). 273 Protocol for getting data from a name: The protocol described in 274 [RFC1035]. 276 Context for resolving a name: The global DNS root zone distributed 277 by PTI. 279 Private DNS: Names that use the protocol described in [RFC1035] but 280 that do not rely on the global DNS root zone or names that are 281 otherwise not generally available on the Internet but are using 282 the protocol described in [RFC1035]. A system can use both the 283 global DNS and one or more private DNS systems; for example, see 284 "Split DNS" in Section 6. 286 Note that domain names that do not appear in the DNS, and that are 287 intended never to be looked up using the DNS protocol, are not 288 part of the global DNS or a private DNS even though they are 289 domain names. 291 Multicast DNS (mDNS): "Multicast DNS (mDNS) provides the ability to 292 perform DNS-like operations on the local link in the absence of 293 any conventional Unicast DNS server. In addition, Multicast DNS 294 designates a portion of the DNS namespace to be free for local 295 use, without the need to pay any annual fee, and without the need 296 to set up delegations or otherwise configure a conventional DNS 297 server to answer for those names." (Quoted from [RFC6762], 298 Abstract) Although it uses a compatible wire format, mDNS is, 299 strictly speaking, a different protocol than DNS. Also, where the 300 above quote says "a portion of the DNS namespace", it would be 301 clearer to say "a portion of the domain name space". The names in 302 mDNS are not intended to be looked up in the DNS. 304 Locally served DNS zone: A locally served DNS zone is a special case 305 of private DNS. Names are resolved using the DNS protocol in a 306 local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that 307 are locally served zones. Resolution of names through locally 308 served zones may result in ambiguous results. For example, the 309 same name may resolve to different results in different locally 310 served DNS zone contexts. The context for a locally served DNS 311 zone may be explicit, such as those that are listed in [RFC6303] 312 and [RFC7793], or implicit, such as those defined by local DNS 313 administration and not known to the resolution client. 315 Fully-Qualified Domain Name (FQDN): This is often just a clear way 316 of saying the same thing as "domain name of a node", as outlined 317 above. However, the term is ambiguous. Strictly speaking, a 318 fully-qualified domain name would include every label, including 319 the zero-length label of the root: such a name would be written 320 "www.example.net." (note the terminating dot). But, because every 321 name eventually shares the common root, names are often written 322 relative to the root (such as "www.example.net") and are still 323 called "fully qualified". This term first appeared in [RFC0819]. 324 In this document, names are often written relative to the root. 326 The need for the term "fully-qualified domain name" comes from the 327 existence of partially qualified domain names, which are names 328 where one or more of the last labels in the ordered list are 329 omitted (for example, a domain name of "www" relative to 330 "example.net" identifies "www.example.net"). Such relative names 331 are understood only by context. 333 Host name: This term and its equivalent, "hostname", have been 334 widely used but are not defined in [RFC1034], [RFC1035], 335 [RFC1123], or [RFC2181]. The DNS was originally deployed into the 336 Host Tables environment as outlined in [RFC0952], and it is likely 337 that the term followed informally from the definition there. Over 338 time, the definition seems to have shifted. "Host name" is often 339 meant to be a domain name that follows the rules in Section 3.5 of 340 [RFC1034], which is also called the "preferred name syntax". (In 341 that syntax, every character in each label is a letter, a digit, 342 or a hyphen). Note that any label in a domain name can contain 343 any octet value; hostnames are generally considered to be domain 344 names where every label follows the rules in the "preferred name 345 syntax", with the amendment that labels can start with ASCII 346 digits (this amendment comes from Section 2.1 of [RFC1123]). 348 People also sometimes use the term "hostname" to refer to just the 349 first label of an FQDN, such as "printer" in 350 "printer.admin.example.com". (Sometimes this is formalized in 351 configuration in operating systems.) In addition, people 352 sometimes use this term to describe any name that refers to a 353 machine, and those might include labels that do not conform to the 354 "preferred name syntax". 356 Top-Level Domain (TLD): A Top-Level Domain is a zone that is one 357 layer below the root, such as "com" or "jp". There is nothing 358 special, from the point of view of the DNS, about TLDs. Most of 359 them are also delegation-centric zones (defined in Section 7), and 360 there are significant policy issues around their operation. TLDs 361 are often divided into sub-groups such as Country Code Top-Level 362 Domains (ccTLDs), Generic Top-Level Domains (gTLDs), and others; 363 the division is a matter of policy and beyond the scope of this 364 document. 366 Internationalized Domain Name (IDN): The Internationalized Domain 367 Names for Applications (IDNA) protocol is the standard mechanism 368 for handling domain names with non-ASCII characters in 369 applications in the DNS. The current standard at the time of this 370 writing, normally called "IDNA2008", is defined in [RFC5890], 371 [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These documents 372 define many IDN-specific terms such as "LDH label", "A-label", and 373 "U-label". [RFC6365] defines more terms that relate to 374 internationalization (some of which relate to IDNs); [RFC6055] has 375 a much more extensive discussion of IDNs, including some new 376 terminology. 378 Subdomain: "A domain is a subdomain of another domain if it is 379 contained within that domain. This relationship can be tested by 380 seeing if the subdomain's name ends with the containing domain's 381 name." (Quoted from [RFC1034], Section 3.1) For example, in the 382 host name "nnn.mmm.example.com", both "mmm.example.com" and 383 "nnn.mmm.example.com" are subdomains of "example.com". Note that 384 the comparisons here are done on whole labels; that is, 385 "ooo.example.com" is not a subdomain of "oo.example.com". 387 Alias: The owner of a CNAME resource record, or a subdomain of the 388 owner of a DNAME resource record (DNAME records are defined in 389 [RFC6672]). See also "canonical name". 391 Canonical name: A CNAME resource record "identifies its owner name 392 as an alias, and specifies the corresponding canonical name in the 393 RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) 394 This usage of the word "canonical" is related to the mathematical 395 concept of "canonical form". 397 CNAME: "It has been traditional to refer to the [owner] of a CNAME 398 record as 'a CNAME'. This is unfortunate, as 'CNAME' is an 399 abbreviation of 'canonical name', and the [owner] of a CNAME 400 record is most certainly not a canonical name." (Quoted from 401 [RFC2181], Section 10.1.1. The quoted text has been changed from 402 "label" to "owner".) 404 3. DNS Response Codes 406 Some of the response codes (RCODEs) that are defined in [RFC1035] 407 have acquired their own shorthand names. All of the RCODEs are 408 listed at [IANA_Resource_Registry], although that list uses mixed- 409 case capitalization, while most documents use all caps. Some of the 410 common names for values defined in [RFC1035] are described in this 411 section. This section also includes an additional RCODE and a 412 general definition. The official list of all RCODEs is in the IANA 413 registry. 415 NOERROR: This RCODE appears as "No error condition" in Section 4.1.1 416 of [RFC1035]. 418 FORMERR: This RCODE appears as "Format error - The name server was 419 unable to interpret the query" in Section 4.1.1 of [RFC1035]. 421 SERVFAIL: This RCODE appears as "Server failure - The name server 422 was unable to process this query due to a problem with the name 423 server" in Section 4.1.1 of [RFC1035]. 425 NXDOMAIN: This RCODE appears as "Name Error [...] this code 426 signifies that the domain name referenced in the query does not 427 exist." in Section 4.1.1 of [RFC1035]. [RFC2308] established 428 NXDOMAIN as a synonym for Name Error. 430 NOTIMP: This RCODE appears as "Not Implemented - The name server 431 does not support the requested kind of query" in Section 4.1.1 of 432 [RFC1035]. 434 REFUSED: This RCODE appears as "Refused - The name server refuses to 435 perform the specified operation for policy reasons. For example, 436 a name server may not wish to provide the information to the 437 particular requester, or a name server may not wish to perform a 438 particular operation (e.g., zone transfer) for particular data." 439 in Section 4.1.1 of [RFC1035]. 441 NODATA: "A pseudo RCODE which indicates that the name is valid, for 442 the given class, but [there] are no records of the given type. A 443 NODATA response has to be inferred from the answer." (Quoted from 444 [RFC2308], Section 1) "NODATA is indicated by an answer with the 445 RCODE set to NOERROR and no relevant answers in the Answer 446 section. The authority section will contain an SOA record, or 447 there will be no NS records there." (Quoted from [RFC2308], 448 Section 2.2) Note that referrals have a similar format to NODATA 449 replies; [RFC2308] explains how to distinguish them. 451 The term "NXRRSET" is sometimes used as a synonym for NODATA. 452 However, this is a mistake, given that NXRRSET is a specific error 453 code defined in [RFC2136]. 455 Negative response: A response that indicates that a particular RRset 456 does not exist or whose RCODE indicates that the nameserver cannot 457 answer. Sections 2 and 7 of [RFC2308] describe the types of 458 negative responses in detail. 460 4. DNS Transactions 462 The header of a DNS message is its first 12 octets. Many of the 463 fields and flags in the diagrams in Sections 4.1.1 through 4.1.3 of 464 [RFC1035] are referred to by their names in each diagram. For 465 example, the response codes are called "RCODEs", the data for a 466 record is called the "RDATA", and the authoritative answer bit is 467 often called "the AA flag" or "the AA bit". 469 Class: A class "identifies a protocol family or instance of a 470 protocol". (Quoted from [RFC1034], Section 3.6) "The DNS tags all 471 data with a class as well as the type, so that we can allow 472 parallel use of different formats for data of type address." 473 (Quoted from [RFC1034], Section 2.2) In practice, the class for 474 nearly every query is "IN" (the Internet). There are some queries 475 for "CH" (the Chaos class), but they are usually for the purposes 476 of information about the server itself rather than for a different 477 type of address. 479 QNAME: The most commonly used rough definition is that the QNAME is 480 a field in the Question section of a query. "A standard query 481 specifies a target domain name (QNAME), query type (QTYPE), and 482 query class (QCLASS) and asks for RRs which match." (Quoted from 483 [RFC1034], Section 3.7.1) Strictly speaking, the definition comes 484 from [RFC1035], Section 4.1.2, where the QNAME is defined in 485 respect of the Question section. This definition appears to be 486 applied consistently: the discussion of inverse queries in 487 Section 6.4.1 refers to the "owner name of the query RR and its 488 TTL", because inverse queries populate the Answer section and 489 leave the Question section empty. (Inverse queries are deprecated 490 in [RFC3425]; thus, relevant definitions do not appear in this 491 document.) 493 However, [RFC2308] has an alternate definition that puts the QNAME 494 in the answer (or series of answers) instead of the query. It 495 defines QNAME as "...the name in the query section of an answer, 496 or where this resolves to a CNAME, or CNAME chain, the data field 497 of the last CNAME. The last CNAME in this sense is that which 498 contains a value which does not resolve to another CNAME." This 499 definition has a certain internal logic, because of the way CNAME 500 substitution works and the definition of CNAME. If a name server 501 does not find an RRset that matches a query, but does find the 502 same name in the same class with a CNAME record, then the name 503 server "includes the CNAME record in the response and restarts the 504 query at the domain name specified in the data field of the CNAME 505 record." (Quoted from [RFC1034], Section 3.6.2) This is made 506 explicit in the resolution algorithm outlined in Section 4.3.2 of 507 [RFC1034], which says to "change QNAME to the canonical name in 508 the CNAME RR, and go back to step 1" in the case of a CNAME RR. 509 Since a CNAME record explicitly declares that the owner name is 510 canonically named what is in the RDATA, then there is a way to 511 view the new name (i.e., the name that was in the RDATA of the 512 CNAME RR) as also being the QNAME. 514 However, this creates a kind of confusion because the response to 515 a query that results in CNAME processing contains in the echoed 516 Question section one QNAME (the name in the original query) and a 517 second QNAME that is in the data field of the last CNAME. The 518 confusion comes from the iterative/recursive mode of resolution, 519 which finally returns an answer that need not actually have the 520 same owner name as the QNAME contained in the original query. 522 To address this potential confusion, it is helpful to distinguish 523 between three meanings: 525 * QNAME (original): The name actually sent in the Question 526 section in the original query, which is always echoed in the 527 (final) reply in the Question section when the QR bit is set to 528 1. 530 * QNAME (effective): A name actually resolved, which is either 531 the name originally queried or a name received in a CNAME chain 532 response. 534 * QNAME (final): The name actually resolved, which is either the 535 name actually queried or else the last name in a CNAME chain 536 response. 538 Note that, because the definition in [RFC2308] is actually for a 539 different concept than what was in [RFC1034], it would have been 540 better if [RFC2308] had used a different name for that concept. 541 In general use today, QNAME almost always means what is defined 542 above as "QNAME (original)". 544 Referrals: A type of response in which a server, signaling that it 545 is not (completely) authoritative for an answer, provides the 546 querying resolver with an alternative place to send its query. 547 Referrals can be partial. 549 A referral arises when a server is not performing recursive 550 service while answering a query. It appears in step 3(b) of the 551 algorithm in [RFC1034], Section 4.3.2. 553 There are two types of referral response. The first is a downward 554 referral (sometimes described as "delegation response"), where the 555 server is authoritative for some portion of the QNAME. The 556 authority section RRset's RDATA contains the name servers 557 specified at the referred-to zone cut. In normal DNS operation, 558 this kind of response is required in order to find names beneath a 559 delegation. The bare use of "referral" means this kind of 560 referral, and many people believe that this is the only legitimate 561 kind of referral in the DNS. 563 The second is an upward referral (sometimes described as "root 564 referral"), where the server is not authoritative for any portion 565 of the QNAME. When this happens, the referred-to zone in the 566 authority section is usually the root zone ("."). In normal DNS 567 operation, this kind of response is not required for resolution or 568 for correctly answering any query. There is no requirement that 569 any server send upward referrals. Some people regard upward 570 referrals as a sign of a misconfiguration or error. Upward 571 referrals always need some sort of qualifier (such as "upward" or 572 "root") and are never identified simply by the word "referral". 574 A response that has only a referral contains an empty answer 575 section. It contains the NS RRset for the referred-to zone in the 576 Authority section. It may contain RRs that provide addresses in 577 the additional section. The AA bit is clear. 579 In the case where the query matches an alias, and the server is 580 not authoritative for the target of the alias but is authoritative 581 for some name above the target of the alias, the resolution 582 algorithm will produce a response that contains both the 583 authoritative answer for the alias and a referral. Such a partial 584 answer and referral response has data in the Answer section. It 585 has the NS RRset for the referred-to zone in the Authority 586 section. It may contain RRs that provide addresses in the 587 additional section. The AA bit is set, because the first name in 588 the Answer section matches the QNAME and the server is 589 authoritative for that answer (see [RFC1035], Section 4.1.1). 591 5. Resource Records 593 RR: An acronym for resource record. (See [RFC1034], Section 3.6.) 595 RRset: A set of resource records "with the same label, class and 596 type, but with different data" (according to [RFC2181], 597 Section 5). Also written as "RRSet" in some documents. As a 598 clarification, "same label" in this definition means "same owner 599 name". In addition, [RFC2181] states that "the TTLs of all RRs in 600 an RRSet must be the same". 602 Note that RRSIG resource records do not match this definition. 603 [RFC4035] says: 605 An RRset MAY have multiple RRSIG RRs associated with it. Note 606 that as RRSIG RRs are closely tied to the RRsets whose 607 signatures they contain, RRSIG RRs, unlike all other DNS RR 608 types, do not form RRsets. In particular, the TTL values among 609 RRSIG RRs with a common owner name do not follow the RRset 610 rules described in [RFC2181]. 612 Master file: "Master files are text files that contain RRs in text 613 form. Since the contents of a zone can be expressed in the form 614 of a list of RRs a master file is most often used to define a 615 zone, though it can be used to list a cache's contents." (Quoted 616 from [RFC1035], Section 5) Master files are sometimes called "zone 617 files". 619 Presentation format: The text format used in master files. This 620 format is shown but not formally defined in [RFC1034] or 621 [RFC1035]. The term "presentation format" first appears in 622 [RFC4034]. 624 EDNS: The extension mechanisms for DNS, defined in [RFC6891]. 625 Sometimes called "EDNS0" or "EDNS(0)" to indicate the version 626 number. EDNS allows DNS clients and servers to specify message 627 sizes larger than the original 512 octet limit, to expand the 628 response code space and to carry additional options that affect 629 the handling of a DNS query. 631 OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to 632 contain control information pertaining to the question-and-answer 633 sequence of a specific transaction. (Definition paraphrased from 634 [RFC6891], Section 6.1.1.) It is used by EDNS. 636 Owner: "The domain name where the RR is found." (Quoted from 637 [RFC1034], Section 3.6) Often appears in the term "owner name". 639 SOA field names: DNS documents, including the definitions here, 640 often refer to the fields in the RDATA of an SOA resource record 641 by field name. "SOA" stands for "start of a zone of authority". 642 Those fields are defined in Section 3.3.13 of [RFC1035]. The 643 names (in the order they appear in the SOA RDATA) are MNAME, 644 RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the 645 meaning of the MINIMUM field is updated in Section 4 of [RFC2308]; 646 the new definition is that the MINIMUM field is only "the TTL to 647 be used for negative responses". This document tends to use field 648 names instead of terms that describe the fields. 650 TTL: The maximum "time to live" of a resource record. "A TTL value 651 is an unsigned number, with a minimum value of 0, and a maximum 652 value of 2147483647. That is, a maximum of 2^31 - 1. When 653 transmitted, this value shall be encoded in the less significant 654 31 bits of the 32 bit TTL field, with the most significant, or 655 sign, bit set to zero." (Quoted from [RFC2181], Section 8) (Note 656 that [RFC1035] erroneously stated that this is a signed integer; 657 that was fixed by [RFC2181].) 659 The TTL "specifies the time interval that the resource record may 660 be cached before the source of the information should again be 661 consulted." (Quoted from [RFC1035], Section 3.2.1) Section 4.1.3 662 of the same document states: "the time interval (in seconds) that 663 the resource record may be cached before it should be discarded". 664 Despite being defined for a resource record, the TTL of every 665 resource record in an RRset is required to be the same ([RFC2181], 666 Section 5.2). 668 The reason that the TTL is the maximum time to live is that a 669 cache operator might decide to shorten the time to live for 670 operational purposes, such as if there is a policy to disallow TTL 671 values over a certain number. Some servers are known to ignore 672 the TTL on some RRsets (such as when the authoritative data has a 673 very short TTL) even though this is against the advice in RFC 674 1035. An RRset can be flushed from the cache before the end of 675 the TTL interval, at which point, the value of the TTL becomes 676 unknown because the RRset with which it was associated no longer 677 exists. 679 There is also the concept of a "default TTL" for a zone, which can 680 be a configuration parameter in the server software. This is 681 often expressed by a default for the entire server, and a default 682 for a zone using the $TTL directive in a zone file. The $TTL 683 directive was added to the master file format by [RFC2308]. 685 Class independent: A resource record type whose syntax and semantics 686 are the same for every DNS class. A resource record type that is 687 not class independent has different meanings depending on the DNS 688 class of the record, or the meaning is undefined for some class. 689 Most resource record types are defined for class 1 (IN, the 690 Internet), but many are undefined for other classes. 692 Address records: Records whose type is A or AAAA. [RFC2181] 693 informally defines these as "(A, AAAA, etc)". Note that new types 694 of address records could be defined in the future. 696 6. DNS Servers and Clients 698 This section defines the terms used for the systems that act as DNS 699 clients, DNS servers, or both. In past RFCs, DNS servers are 700 sometimes called "name servers", "nameservers", or just "servers". 701 There is no formal definition of "DNS server", but RFCs generally 702 assume that it is an Internet server that listens for queries and 703 sends responses using the DNS protocol defined in [RFC1035] and its 704 successors. 706 It is important to note that the terms "DNS server" and "name server" 707 require context in order to understand the services being provided. 708 Both authoritative servers and recursive resolvers are often called 709 "DNS servers" and "name servers" even though they serve different 710 roles (but may be part of the same software package). 712 For terminology specific to the global DNS root server system, see 713 [RSSAC026]. That document defines terms such as "root server", "root 714 server operator", and terms that are specific to the way that the 715 root zone of the global DNS is served. 717 Resolver: A program "that extract[s] information from name servers 718 in response to client requests." (Quoted from [RFC1034], 719 Section 2.4) A resolver performs queries for a name, type, and 720 class, and receives responses. The logical function is called 721 "resolution". In practice, the term is usually referring to some 722 specific type of resolver (some of which are defined below), and 723 understanding the use of the term depends on understanding the 724 context. 726 A related term is "resolve", which is not formally defined in 727 [RFC1034] or [RFC1035]. An imputed definition might be "asking a 728 question that consists of a domain name, class, and type, and 729 receiving some sort of response". Similarly, an imputed 730 definition of "resolution" might be "the response received from 731 resolving". 733 Stub resolver: A resolver that cannot perform all resolution itself. 734 Stub resolvers generally depend on a recursive resolver to 735 undertake the actual resolution function. Stub resolvers are 736 discussed but never fully defined in Section 5.3.1 of [RFC1034]. 737 They are fully defined in Section 6.1.3.1 of [RFC1123]. 739 Iterative mode: A resolution mode of a server that receives DNS 740 queries and responds with a referral to another server. 741 Section 2.3 of [RFC1034] describes this as "The server refers the 742 client to another server and lets the client pursue the query." A 743 resolver that works in iterative mode is sometimes called an 744 "iterative resolver". See also "iterative resolution" later in 745 this section. 747 Recursive mode: A resolution mode of a server that receives DNS 748 queries and either responds to those queries from a local cache or 749 sends queries to other servers in order to get the final answers 750 to the original queries. Section 2.3 of [RFC1034] describes this 751 as "the first server pursues the query for the client at another 752 server". Section 4.3.1 of [RFC1034] says: "in [recursive] mode 753 the name server acts in the role of a resolver and returns either 754 an error or the answer, but never referrals." That same section 755 also says: 757 The recursive mode occurs when a query with RD set arrives at a 758 server which is willing to provide recursive service; the 759 client can verify that recursive mode was used by checking that 760 both RA and RD are set in the reply. 762 A server operating in recursive mode may be thought of as having a 763 name server side (which is what answers the query) and a resolver 764 side (which performs the resolution function). Systems operating 765 in this mode are commonly called "recursive servers". Sometimes 766 they are called "recursive resolvers". In practice, it is not 767 possible to know in advance whether the server that one is 768 querying will also perform recursion; both terms can be observed 769 in use interchangeably. 771 Recursive resolver: A resolver that acts in recursive mode. In 772 general, a recursive resolver is expected to cache the answers it 773 receives (which would make it a full-service resolver), but some 774 recursive resolvers might not cache. 776 [RFC4697] tried to differentiate between a recursive resolver and 777 an iterative resolver. 779 Recursive query: A query with the Recursion Desired (RD) bit set to 780 1 in the header. (See Section 4.1.1 of [RFC1035].) If recursive 781 service is available and is requested by the RD bit in the query, 782 the server uses its resolver to answer the query. (See 783 Section 4.3.2 of [RFC1034].) 785 Non-recursive query: A query with the Recursion Desired (RD) bit set 786 to 0 in the header. A server can answer non-recursive queries 787 using only local information: the response contains either an 788 error, the answer, or a referral to some other server "closer" to 789 the answer. (See Section 4.3.1 of [RFC1034].) 791 Iterative resolution: A name server may be presented with a query 792 that can only be answered by some other server. The two general 793 approaches to dealing with this problem are "recursive", in which 794 the first server pursues the query on behalf of the client at 795 another server, and "iterative", in which the server refers the 796 client to another server and lets the client pursue the query 797 there. (See Section 2.3 of [RFC1034].) 799 In iterative resolution, the client repeatedly makes non-recursive 800 queries and follows referrals and/or aliases. The iterative 801 resolution algorithm is described in Section 5.3.3 of [RFC1034]. 803 Full resolver: This term is used in [RFC1035], but it is not defined 804 there. RFC 1123 defines a "full-service resolver" that may or may 805 not be what was intended by "full resolver" in [RFC1035]. This 806 term is not properly defined in any RFC. 808 Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this 809 term to mean a resolver that acts in recursive mode with a cache 810 (and meets other requirements). 812 Priming: "The act of finding the list of root servers from a 813 configuration that lists some or all of the purported IP addresses 814 of some or all of those root servers." (Quoted from [RFC8109], 815 Section 2) In order to operate in recursive mode, a resolver needs 816 to know the address of at least one root server. Priming is most 817 often done from a configuration setting that contains a list of 818 authoritative servers for the root zone. 820 Root hints: "Operators who manage a DNS recursive resolver typically 821 need to configure a 'root hints file'. This file contains the 822 names and IP addresses of the authoritative name servers for the 823 root zone, so the software can bootstrap the DNS resolution 824 process. For many pieces of software, this list comes built into 825 the software." (Quoted from [IANA_RootFiles]) This file is often 826 used in priming. 828 Negative caching: "The storage of knowledge that something does not 829 exist, cannot or does not give an answer." (Quoted from 830 [RFC2308], Section 1) 832 Authoritative server: "A server that knows the content of a DNS zone 833 from local knowledge, and thus can answer queries about that zone 834 without needing to query other servers." (Quoted from [RFC2182], 835 Section 2) An authoritative server is named in the NS ("name 836 server") record in a zone. It is a system that responds to DNS 837 queries with information about zones for which it has been 838 configured to answer with the AA flag in the response header set 839 to 1. It is a server that has authority over one or more DNS 840 zones. Note that it is possible for an authoritative server to 841 respond to a query without the parent zone delegating authority to 842 that server. Authoritative servers also provide "referrals", 843 usually to child zones delegated from them; these referrals have 844 the AA bit set to 0 and come with referral data in the Authority 845 and (if needed) the Additional sections. 847 Authoritative-only server: A name server that only serves 848 authoritative data and ignores requests for recursion. It will 849 "not normally generate any queries of its own. Instead it answers 850 non-recursive queries from iterative resolvers looking for 851 information in zones it serves." (Quoted from [RFC4697], 852 Section 2.4) In this case, "ignores requests for recursion" means 853 "responds to requests for recursion with responses indicating that 854 recursion was not performed". 856 Zone transfer: The act of a client requesting a copy of a zone and 857 an authoritative server sending the needed information. (See 858 Section 7 for a description of zones.) There are two common 859 standard ways to do zone transfers: the AXFR ("Authoritative 860 Transfer") mechanism to copy the full zone (described in 861 [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy 862 only parts of the zone that have changed (described in [RFC1995]). 863 Many systems use non-standard methods for zone transfer outside 864 the DNS protocol. 866 Slave server: See "Secondary server". 868 Secondary server: "An authoritative server which uses zone transfer 869 to retrieve the zone." (Quoted from [RFC1996], Section 2.1) 870 Secondary servers are also discussed in [RFC1034]. [RFC2182] 871 describes secondary servers in more detail. Although early DNS 872 RFCs such as [RFC1996] referred to this as a "slave", the current 873 common usage has shifted to calling it a "secondary". 875 Master server: See "Primary server". 877 Primary server: "Any authoritative server configured to be the 878 source of zone transfer for one or more [secondary] servers." 879 (Quoted from [RFC1996], Section 2.1) Or, more specifically, 880 [RFC2136] calls it "an authoritative server configured to be the 881 source of AXFR or IXFR data for one or more [secondary] servers". 882 Primary servers are also discussed in [RFC1034]. Although early 883 DNS RFCs such as [RFC1996] referred to this as a "master", the 884 current common usage has shifted to "primary". 886 Primary master: "The primary master is named in the zone's SOA MNAME 887 field and optionally by an NS RR." (Quoted from [RFC1996], 888 Section 2.1) [RFC2136] defines "primary master" as "Master server 889 at the root of the AXFR/IXFR dependency graph. The primary master 890 is named in the zone's SOA MNAME field and optionally by an NS RR. 891 There is by definition only one primary master server per zone." 893 The idea of a primary master is only used in [RFC1996] and 894 [RFC2136]. A modern interpretation of the term "primary master" 895 is a server that is both authoritative for a zone and that gets 896 its updates to the zone from configuration (such as a master file) 897 or from UPDATE transactions. 899 Stealth server: This is "like a slave server except not listed in an 900 NS RR for the zone." (Quoted from [RFC1996], Section 2.1) 902 Hidden master: A stealth server that is a primary server for zone 903 transfers. "In this arrangement, the master name server that 904 processes the updates is unavailable to general hosts on the 905 Internet; it is not listed in the NS RRset." (Quoted from 906 [RFC6781], Section 3.4.3) An earlier RFC, [RFC4641], said that the 907 hidden master's name "appears in the SOA RRs MNAME field", 908 although, in some setups, the name does not appear at all in the 909 global DNS. A hidden master can also be a secondary server for 910 the zone itself. 912 Forwarding: The process of one server sending a DNS query with the 913 RD bit set to 1 to another server to resolve that query. 914 Forwarding is a function of a DNS resolver; it is different than 915 simply blindly relaying queries. 917 [RFC5625] does not give a specific definition for forwarding, but 918 describes in detail what features a system that forwards needs to 919 support. Systems that forward are sometimes called "DNS proxies", 920 but that term has not yet been defined (even in [RFC5625]). 922 Forwarder: Section 1 of [RFC2308] describes a forwarder as "a 923 nameserver used to resolve queries instead of directly using the 924 authoritative nameserver chain". [RFC2308] further says "The 925 forwarder typically either has better access to the internet, or 926 maintains a bigger cache which may be shared amongst many 927 resolvers." That definition appears to suggest that forwarders 928 normally only query authoritative servers. In current use, 929 however, forwarders often stand between stub resolvers and 930 recursive servers. [RFC2308] is silent on whether a forwarder is 931 iterative-only or can be a full-service resolver. 933 Policy-implementing resolver: A resolver acting in recursive mode 934 that changes some of the answers that it returns based on policy 935 criteria, such as to prevent access to malware sites or 936 objectionable content. In general, a stub resolver has no idea 937 whether upstream resolvers implement such policy or, if they do, 938 the exact policy about what changes will be made. In some cases, 939 the user of the stub resolver has selected the policy-implementing 940 resolver with the explicit intention of using it to implement the 941 policies. In other cases, policies are imposed without the user 942 of the stub resolver being informed. 944 Open resolver: A full-service resolver that accepts and processes 945 queries from any (or nearly any) client. This is sometimes also 946 called a "public resolver", although the term "public resolver" is 947 used more with open resolvers that are meant to be open, as 948 compared to the vast majority of open resolvers that are probably 949 misconfigured to be open. Open resolvers are discussed in 950 [RFC5358]. 952 Split DNS: The terms "split DNS" and "split-horizon DNS" have long 953 been used in the DNS community without formal definition. In 954 general, they refer to situations in which DNS servers that are 955 authoritative for a particular set of domains provide partly or 956 completely different answers in those domains depending on the 957 source of the query. The effect of this is that a domain name 958 that is notionally globally unique nevertheless has different 959 meanings for different network users. This can sometimes be the 960 result of a "view" configuration, described below. 962 Section 3.8 of [RFC2775] gives a related definition that is too 963 specific to be generally useful. 965 View: A configuration for a DNS server that allows it to provide 966 different responses depending on attributes of the query, such as 967 for "split DNS". Typically, views differ by the source IP address 968 of a query, but can also be based on the destination IP address, 969 the type of query (such as AXFR), whether it is recursive, and so 970 on. Views are often used to provide more names or different 971 addresses to queries from "inside" a protected network than to 972 those "outside" that network. Views are not a standardized part 973 of the DNS, but they are widely implemented in server software. 975 Passive DNS: A mechanism to collect DNS data by storing DNS 976 responses from name servers. Some of these systems also collect 977 the DNS queries associated with the responses, although doing so 978 raises some privacy concerns. Passive DNS databases can be used 979 to answer historical questions about DNS zones such as which 980 values were present at a given time in the past, or when a name 981 was spotted first. Passive DNS databases allow searching of the 982 stored records on keys other than just the name and type, such as 983 "find all names which have A records of a particular value". 985 Anycast: "The practice of making a particular service address 986 available in multiple, discrete, autonomous locations, such that 987 datagrams sent are routed to one of several available locations." 988 (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail 989 on Anycast and other terms that are specific to its use. 991 Instance: "When anycast routing is used to allow more than one 992 server to have the same IP address, each one of those servers is 993 commonly referred to as an 'instance'." It goes on to say: "An 994 instance of a server, such as a root server, is often referred to 995 as an 'Anycast instance'." (Quoted from [RSSAC026]) 997 Privacy-enabling DNS server: "A DNS server that implements DNS over 998 TLS [RFC7858] and may optionally implement DNS over DTLS 999 [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS 1000 servers might also be considered privacy-enabling, such as those 1001 running DNS over HTTPS [RFC8484]. 1003 DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its 1004 successors. 1006 DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its 1007 successors. 1009 DNS-over-QUIC (DoQ): DNS over QUIC as defined in 1010 [I-D.ietf-dprive-dnsoquic] 1012 Classic DNS: DNS over UDP or TCP as defined in [RFC1035] and its 1013 successors. Classic DNS applies to DNS communication between stub 1014 resolvers and recursive resolvers, and between recursive resolvers 1015 and authoritative servers. This has sometimes been called "Do53". 1016 Classic DNS is not encrypted. 1018 Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for 1019 transport between a stub resolver and a recursive resolver, or 1020 between a recursive resolver and another recursive resolver. This 1021 term is necessary because it is expected that DNS-over-TLS will 1022 later be defined as a transport between recursive resolvers and 1023 authoritative servers, 1025 Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a 1026 transport between recursive resolvers and authoritative servers, 1027 ADoT specifically means DNS-over-TLS for transport between 1028 recursive resolvers and authoritative servers. 1030 7. Zones 1032 This section defines terms that are used when discussing zones that 1033 are being served or retrieved. 1035 Zone: "Authoritative information is organized into units called 1036 ZONEs, and these zones can be automatically distributed to the 1037 name servers which provide redundant service for the data in a 1038 zone." (Quoted from [RFC1034], Section 2.4) 1040 Child: "The entity on record that has the delegation of the domain 1041 from the Parent." (Quoted from [RFC7344], Section 1.1) 1043 Parent: "The domain in which the Child is registered." (Quoted from 1044 [RFC7344], Section 1.1) Earlier, "parent name server" was defined 1045 in [RFC0882] as "the name server that has authority over the place 1046 in the domain name space that will hold the new domain". (Note 1047 that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].) 1048 [RFC0819] also has some description of the relationship between 1049 parents and children. 1051 Origin: 1053 There are two different uses for this term: 1055 (a) "The domain name that appears at the top of a zone (just 1056 below the cut that separates the zone from its parent)... The 1057 name of the zone is the same as the name of the domain at the 1058 zone's origin." (Quoted from [RFC2181], Section 6) These 1059 days, this sense of "origin" and "apex" (defined below) are 1060 often used interchangeably. 1062 (b) The domain name within which a given relative domain name 1063 appears in zone files. Generally seen in the context of 1064 "$ORIGIN", which is a control entry defined in [RFC1035], 1065 Section 5.1, as part of the master file format. For example, 1066 if the $ORIGIN is set to "example.org.", then a master file 1067 line for "www" is in fact an entry for "www.example.org.". 1069 Apex: The point in the tree at an owner of an SOA and corresponding 1070 authoritative NS RRset. This is also called the "zone apex". 1071 [RFC4033] defines it as "the name at the child's side of a zone 1072 cut". The "apex" can usefully be thought of as a data-theoretic 1073 description of a tree structure, and "origin" is the name of the 1074 same concept when it is implemented in zone files. The 1075 distinction is not always maintained in use, however, and one can 1076 find uses that conflict subtly with this definition. [RFC1034] 1077 uses the term "top node of the zone" as a synonym of "apex", but 1078 that term is not widely used. These days, the first sense of 1079 "origin" (above) and "apex" are often used interchangeably. 1081 Zone cut: The delimitation point between two zones where the origin 1082 of one of the zones is the child of the other zone. 1084 "Zones are delimited by 'zone cuts'. Each zone cut separates a 1085 'child' zone (below the cut) from a 'parent' zone (above the 1086 cut)." (Quoted from [RFC2181], Section 6; note that this is 1087 barely an ostensive definition.) Section 4.2 of [RFC1034] uses 1088 "cuts" instead of "zone cut". 1090 Delegation: The process by which a separate zone is created in the 1091 name space beneath the apex of a given domain. Delegation happens 1092 when an NS RRset is added in the parent zone for the child origin. 1093 Delegation inherently happens at a zone cut. The term is also 1094 commonly a noun: the new zone that is created by the act of 1095 delegating. 1097 Authoritative data: "All of the RRs attached to all of the nodes 1098 from the top node of the zone down to leaf nodes or nodes above 1099 cuts around the bottom edge of the zone." (Quoted from [RFC1034], 1100 Section 4.2.1) Note that this definition might inadvertently also 1101 cause any NS records that appear in the zone to be included, even 1102 those that might not truly be authoritative because there are 1103 identical NS RRs below the zone cut. This reveals the ambiguity 1104 in the notion of authoritative data, because the parent-side NS 1105 records authoritatively indicate the delegation, even though they 1106 are not themselves authoritative data. 1108 [RFC4033], Section 2, defines "Authoritative RRset", which is 1109 related to authoritative data but has a more precise definition. 1111 Lame delegation: "A lame delegations exists [sic] when a nameserver 1112 is delegated responsibility for providing nameservice for a zone 1113 (via NS records) but is not performing nameservice for that zone 1114 (usually because it is not set up as a primary or secondary for 1115 the zone)." (Quoted from [RFC1912], Section 2.8) Another 1116 definition is that a lame delegation "...happens when a name 1117 server is listed in the NS records for some domain and in fact it 1118 is not a server for that domain. Queries are thus sent to the 1119 wrong servers, who don't know nothing [sic] (at least not as 1120 expected) about the queried domain. Furthermore, sometimes these 1121 hosts (if they exist!) don't even run name servers." (Quoted from 1122 [RFC1713], Section 2.3) 1124 Glue records: "...[Resource records] which are not part of the 1125 authoritative data [of the zone], and are address RRs for the 1126 [name] servers [in subzones]. These RRs are only necessary if the 1127 name server's name is 'below' the cut, and are only used as part 1128 of a referral response." Without glue "we could be faced with the 1129 situation where the NS RRs tell us that in order to learn a name 1130 server's address, we should contact the server using the address 1131 we wish to learn." (Quoted from [RFC1034], Section 4.2.1) 1133 A later definition is that glue "includes any record in a zone 1134 file that is not properly part of that zone, including nameserver 1135 records of delegated sub-zones (NS records), address records that 1136 accompany those NS records (A, AAAA, etc), and any other stray 1137 data that might appear." (Quoted from [RFC2181], Section 5.4.1) 1138 Although glue is sometimes used today with this wider definition 1139 in mind, the context surrounding the definition in [RFC2181] 1140 suggests it is intended to apply to the use of glue within the 1141 document itself and not necessarily beyond. 1143 Bailiwick: "In-bailiwick" is a modifier to describe a name server 1144 whose name is either a subdomain of or (rarely) the same as the 1145 origin of the zone that contains the delegation to the name 1146 server. In-bailiwick name servers may have glue records in their 1147 parent zone (using the first of the definitions of "glue records" 1148 in the definition above). (The word "bailiwick" means the 1149 district or territory where a bailiff or policeman has 1150 jurisdiction.) 1152 "In-bailiwick" names are divided into two types of names for name 1153 servers: "in-domain" names and "sibling domain" names. 1155 * In-domain: a modifier to describe a name server whose name is 1156 either subordinate to or (rarely) the same as the owner name of 1157 the NS resource records. An in-domain name server name needs 1158 to have glue records or name resolution fails. For example, a 1159 delegation for "child.example.com" may have "in-domain" name 1160 server name "ns.child.example.com". 1162 * Sibling domain: a name server's name that is either subordinate 1163 to or (rarely) the same as the zone origin and not subordinate 1164 to or the same as the owner name of the NS resource records. 1165 Glue records for sibling domains are allowed, but not 1166 necessary. For example, a delegation for "child.example.com" 1167 in "example.com" zone may have "sibling" name server name 1168 "ns.another.example.com". 1170 "Out-of-bailiwick" is the antonym of "in-bailiwick". It is a 1171 modifier to describe a name server whose name is not subordinate 1172 to or the same as the zone origin. Glue records for out-of- 1173 bailiwick name servers are useless. 1175 The following table shows examples of delegation types. 1177 +=============+========+====================+==================+ 1178 | Delegation | Parent | Name Server Name | Type | 1179 +=============+========+====================+==================+ 1180 | com | . | a.gtld-servers.net | in-bailiwick / | 1181 | | | | sibling domain | 1182 +-------------+--------+--------------------+------------------+ 1183 | net | . | a.gtld-servers.net | in-bailiwick / | 1184 | | | | in-domain | 1185 +-------------+--------+--------------------+------------------+ 1186 | example.org | org | ns.example.org | in-bailiwick / | 1187 | | | | in-domain | 1188 +-------------+--------+--------------------+------------------+ 1189 | example.org | org | ns.ietf.org | in-bailiwick / | 1190 | | | | sibling domain | 1191 +-------------+--------+--------------------+------------------+ 1192 | example.org | org | ns.example.com | out-of-bailiwick | 1193 +-------------+--------+--------------------+------------------+ 1194 | example.jp | jp | ns.example.jp | in-bailiwick / | 1195 | | | | in-domain | 1196 +-------------+--------+--------------------+------------------+ 1197 | example.jp | jp | ns.example.ne.jp | in-bailiwick / | 1198 | | | | sibling domain | 1199 +-------------+--------+--------------------+------------------+ 1200 | example.jp | jp | ns.example.com | out-of-bailiwick | 1201 +-------------+--------+--------------------+------------------+ 1203 Table 1 1205 Root zone: The zone of a DNS-based tree whose apex is the zero- 1206 length label. Also sometimes called "the DNS root". 1208 Empty non-terminals (ENT): "Domain names that own no resource 1209 records but have subdomains that do." (Quoted from [RFC4592], 1210 Section 2.2.2) A typical example is in SRV records: in the name 1211 "_sip._tcp.example.com", it is likely that "_tcp.example.com" has 1212 no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV 1213 RRset. 1215 Delegation-centric zone: A zone that consists mostly of delegations 1216 to child zones. This term is used in contrast to a zone that 1217 might have some delegations to child zones but also has many data 1218 resource records for the zone itself and/or for child zones. The 1219 term is used in [RFC4956] and [RFC5155], but it is not defined in 1220 either document. 1222 Occluded name: "The addition of a delegation point via dynamic 1223 update will render all subordinate domain names to be in a limbo, 1224 still part of the zone but not available to the lookup process. 1225 The addition of a DNAME resource record has the same impact. The 1226 subordinate names are said to be 'occluded'." (Quoted from 1227 [RFC5936], Section 3.5) 1229 Fast flux DNS: This "occurs when a domain is [found] in DNS using A 1230 records to multiple IP addresses, each of which has a very short 1231 Time-to-Live (TTL) value associated with it. This means that the 1232 domain resolves to varying IP addresses over a short period of 1233 time." (Quoted from [RFC6561], Section 1.1.5, with a typo 1234 corrected) In addition to having legitimate uses, fast flux DNS 1235 can used to deliver malware. Because the addresses change so 1236 rapidly, it is difficult to ascertain all the hosts. It should be 1237 noted that the technique also works with AAAA records, but such 1238 use is not frequently observed on the Internet as of this writing. 1240 Reverse DNS, reverse lookup: "The process of mapping an address to a 1241 name is generally known as a 'reverse lookup', and the IN- 1242 ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse 1243 DNS'." (Quoted from [RFC5855], Section 1) 1245 Forward lookup: "Hostname-to-address translation". (Quoted from 1246 [RFC3493], Section 6) 1248 arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain 1249 was originally established as part of the initial deployment of 1250 the DNS, to provide a transition mechanism from the Host Tables 1251 that were common in the ARPANET, as well as a home for the IPv4 1252 reverse mapping domain. During 2000, the abbreviation was 1253 redesignated to 'Address and Routing Parameter Area' in the hope 1254 of reducing confusion with the earlier network name." (Quoted 1255 from [RFC3172], Section 2) .arpa is an "infrastructure domain", a 1256 domain whose "role is to support the operating infrastructure of 1257 the Internet". (Quoted from [RFC3172], Section 2) See [RFC3172] 1258 for more history of this name. 1260 Service name: "Service names are the unique key in the Service Name 1261 and Transport Protocol Port Number registry. This unique symbolic 1262 name for a service may also be used for other purposes, such as in 1263 DNS SRV records." (Quoted from [RFC6335], Section 5) 1265 8. Wildcards 1267 Wildcard: [RFC1034] defined "wildcard", but in a way that turned out 1268 to be confusing to implementers. For an extended discussion of 1269 wildcards, including clearer definitions, see [RFC4592]. Special 1270 treatment is given to RRs with owner names starting with the label 1271 "*". "Such RRs are called 'wildcards'. Wildcard RRs can be 1272 thought of as instructions for synthesizing RRs." (Quoted from 1273 [RFC1034], Section 4.3.3) 1275 Asterisk label: "The first octet is the normal label type and length 1276 for a 1-octet-long label, and the second octet is the ASCII 1277 representation [RFC20] for the '*' character. A descriptive name 1278 of a label equaling that value is an 'asterisk label'." (Quoted 1279 from [RFC4592], Section 2.1.1) 1281 Wildcard domain name: "A 'wildcard domain name' is defined by having 1282 its initial (i.e., leftmost or least significant) label, in binary 1283 format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)". 1284 (Quoted from [RFC4592], Section 2.1.1) The second octet in this 1285 label is the ASCII representation for the "*" character. 1287 Closest encloser: "The longest existing ancestor of a name." 1288 (Quoted from [RFC5155], Section 1.3) An earlier definition is "The 1289 node in the zone's tree of existing domain names that has the most 1290 labels matching the query name (consecutively, counting from the 1291 root label downward). Each match is a 'label match' and the order 1292 of the labels is the same." (Quoted from [RFC4592], 1293 Section 3.3.1) 1295 Closest provable encloser: "The longest ancestor of a name that can 1296 be proven to exist. Note that this is only different from the 1297 closest encloser in an Opt-Out zone." (Quoted from [RFC5155], 1298 Section 1.3) See Section 10 for more on "opt-out". 1300 Next closer name: "The name one label longer than the closest 1301 provable encloser of a name." (Quoted from [RFC5155], 1302 Section 1.3) 1304 Source of Synthesis: "The source of synthesis is defined in the 1305 context of a query process as that wildcard domain name 1306 immediately descending from the closest encloser, provided that 1307 this wildcard domain name exists. 'Immediately descending' means 1308 that the source of synthesis has a name of the form: 1310 .." 1312 (Quoted from [RFC4592], Section 3.3.1) 1314 9. Registration Model 1316 Registry: The administrative operation of a zone that allows 1317 registration of names within that zone. People often use this 1318 term to refer only to those organizations that perform 1319 registration in large delegation-centric zones (such as TLDs); but 1320 formally, whoever decides what data goes into a zone is the 1321 registry for that zone. This definition of "registry" is from a 1322 DNS point of view; for some zones, the policies that determine 1323 what can go in the zone are decided by zones that are 1324 superordinate and not the registry operator. 1326 Registrant: An individual or organization on whose behalf a name in 1327 a zone is registered by the registry. In many zones, the registry 1328 and the registrant may be the same entity, but in TLDs they often 1329 are not. 1331 Registrar: A service provider that acts as a go-between for 1332 registrants and registries. Not all registrations require a 1333 registrar, though it is common to have registrars involved in 1334 registrations in TLDs. 1336 EPP: The Extensible Provisioning Protocol (EPP), which is commonly 1337 used for communication of registration information between 1338 registries and registrars. EPP is defined in [RFC5730]. 1340 WHOIS: A protocol specified in [RFC3912], often used for querying 1341 registry databases. WHOIS data is frequently used to associate 1342 registration data (such as zone management contacts) with domain 1343 names. The term "WHOIS data" is often used as a synonym for the 1344 registry database, even though that database may be served by 1345 different protocols, particularly RDAP. The WHOIS protocol is 1346 also used with IP address registry data. 1348 RDAP: The Registration Data Access Protocol, defined in [RFC7480], 1349 [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The 1350 RDAP protocol and data format are meant as a replacement for 1351 WHOIS. 1353 DNS operator: An entity responsible for running DNS servers. For a 1354 zone's authoritative servers, the registrant may act as their own 1355 DNS operator, their registrar may do it on their behalf, or they 1356 may use a third-party operator. For some zones, the registry 1357 function is performed by the DNS operator plus other entities who 1358 decide about the allowed contents of the zone. 1360 Public suffix: "A domain that is controlled by a public registry." 1361 (Quoted from [RFC6265], Section 5.3) A common definition for this 1362 term is a domain under which subdomains can be registered by third 1363 parties and on which HTTP cookies (which are described in detail 1364 in [RFC6265]) should not be set. There is no indication in a 1365 domain name whether it is a public suffix; that can only be 1366 determined by outside means. In fact, both a domain and a 1367 subdomain of that domain can be public suffixes. 1369 There is nothing inherent in a domain name to indicate whether it 1370 is a public suffix. One resource for identifying public suffixes 1371 is the Public Suffix List (PSL) maintained by Mozilla 1372 (https://publicsuffix.org/). 1374 For example, at the time this document is published, the "com.au" 1375 domain is listed as a public suffix in the PSL. (Note that this 1376 example might change in the future.) 1378 Note that the term "public suffix" is controversial in the DNS 1379 community for many reasons, and it may be significantly changed in 1380 the future. One example of the difficulty of calling a domain a 1381 public suffix is that designation can change over time as the 1382 registration policy for the zone changes, such as was the case 1383 with the "uk" TLD in 2014. 1385 Subordinate and Superordinate: These terms are introduced in 1386 [RFC5731] for use in the registration model, but not defined 1387 there. Instead, they are given in examples. "For example, domain 1388 name 'example.com' has a superordinate relationship to host name 1389 ns1.example.com'... For example, host ns1.example1.com is a 1390 subordinate host of domain example1.com, but it is a not a 1391 subordinate host of domain example2.com." (Quoted from [RFC5731], 1392 Section 1.1) These terms are strictly ways of referring to the 1393 relationship standing of two domains where one is a subdomain of 1394 the other. 1396 10. General DNSSEC 1398 Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and 1399 [RFC5155]. The terms that have caused confusion in the DNS community 1400 are highlighted here. 1402 DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in 1403 some RFCs, have not been formally defined. However, Section 2 of 1404 [RFC4033] defines many types of resolvers and validators, 1405 including "non-validating security-aware stub resolver", "non- 1406 validating stub resolver", "security-aware name server", 1407 "security-aware recursive name server", "security-aware resolver", 1408 "security-aware stub resolver", and "security-oblivious 1409 'anything'". (Note that the term "validating resolver", which is 1410 used in some places in DNSSEC-related documents, is also not 1411 defined in those RFCs, but is defined below.) 1413 Signed zone: "A zone whose RRsets are signed and that contains 1414 properly constructed DNSKEY, Resource Record Signature (RRSIG), 1415 Next Secure (NSEC), and (optionally) DS records." (Quoted from 1416 [RFC4033], Section 2) It has been noted in other contexts that the 1417 zone itself is not really signed, but all the relevant RRsets in 1418 the zone are signed. Nevertheless, if a zone that should be 1419 signed contains any RRsets that are not signed (or opted out), 1420 those RRsets will be treated as bogus, so the whole zone needs to 1421 be handled in some way. 1423 It should also be noted that, since the publication of [RFC6840], 1424 NSEC records are no longer required for signed zones: a signed 1425 zone might include NSEC3 records instead. [RFC7129] provides 1426 additional background commentary and some context for the NSEC and 1427 NSEC3 mechanisms used by DNSSEC to provide authenticated denial- 1428 of-existence responses. NSEC and NSEC3 are described below. 1430 Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that 1431 is not signed". Section 2 of [RFC4035] defines this as a "zone 1432 that does not include these records [properly constructed DNSKEY, 1433 Resource Record Signature (RRSIG), Next Secure (NSEC), and 1434 (optionally) DS records] according to the rules in this 1435 section..." There is an important note at the end of Section 5.2 1436 of [RFC4035] that defines an additional situation in which a zone 1437 is considered unsigned: "If the resolver does not support any of 1438 the algorithms listed in an authenticated DS RRset, then the 1439 resolver will not be able to verify the authentication path to the 1440 child zone. In this case, the resolver SHOULD treat the child 1441 zone as if it were unsigned." 1443 NSEC: "The NSEC record allows a security-aware resolver to 1444 authenticate a negative reply for either name or type non- 1445 existence with the same mechanisms used to authenticate other DNS 1446 replies." (Quoted from [RFC4033], Section 3.2) In short, an NSEC 1447 record provides authenticated denial of existence. 1449 "The NSEC resource record lists two separate things: the next 1450 owner name (in the canonical ordering of the zone) that contains 1451 authoritative data or a delegation point NS RRset, and the set of 1452 RR types present at the NSEC RR's owner name." (Quoted from 1453 Section 4 of RFC 4034) 1455 NSEC3: Like the NSEC record, the NSEC3 record also provides 1456 authenticated denial of existence; however, NSEC3 records mitigate 1457 zone enumeration and support Opt-Out. NSEC3 resource records 1458 require associated NSEC3PARAM resource records. NSEC3 and 1459 NSEC3PARAM resource records are defined in [RFC5155]. 1461 Note that [RFC6840] says that [RFC5155] "is now considered part of 1462 the DNS Security Document Family as described by Section 10 of 1463 [RFC4033]". This means that some of the definitions from earlier 1464 RFCs that only talk about NSEC records should probably be 1465 considered to be talking about both NSEC and NSEC3. 1467 Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover 1468 unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1) 1469 Opt-out tackles the high costs of securing a delegation to an 1470 insecure zone. When using Opt-Out, names that are an insecure 1471 delegation (and empty non-terminals that are only derived from 1472 insecure delegations) don't require an NSEC3 record or its 1473 corresponding RRSIG records. Opt-Out NSEC3 records are not able 1474 to prove or deny the existence of the insecure delegations. 1475 (Adapted from [RFC7129], Section 5.1) 1477 Insecure delegation: "A signed name containing a delegation (NS 1478 RRset), but lacking a DS RRset, signifying a delegation to an 1479 unsigned subzone." (Quoted from [RFC4956], Section 2) 1481 Zone enumeration: "The practice of discovering the full content of a 1482 zone via successive queries." (Quoted from [RFC5155], 1483 Section 1.3) This is also sometimes called "zone walking". Zone 1484 enumeration is different from zone content guessing where the 1485 guesser uses a large dictionary of possible labels and sends 1486 successive queries for them, or matches the contents of NSEC3 1487 records against such a dictionary. 1489 Validation: Validation, in the context of DNSSEC, refers to one of 1490 the following: 1492 * Checking the validity of DNSSEC signatures, 1494 * Checking the validity of DNS responses, such as those including 1495 authenticated denial of existence, or 1497 * Building an authentication chain from a trust anchor to a DNS 1498 response or individual DNS RRsets in a response 1500 The first two definitions above consider only the validity of 1501 individual DNSSEC components such as the RRSIG validity or NSEC 1502 proof validity. The third definition considers the components of 1503 the entire DNSSEC authentication chain; thus, it requires 1504 "configured knowledge of at least one authenticated DNSKEY or DS 1505 RR" (as described in [RFC4035], Section 5). 1507 [RFC4033], Section 2, says that a "Validating Security-Aware Stub 1508 Resolver... performs signature validation" and uses a trust anchor 1509 "as a starting point for building the authentication chain to a 1510 signed DNS response"; thus, it uses the first and third 1511 definitions above. The process of validating an RRSIG resource 1512 record is described in [RFC4035], Section 5.3. 1514 [RFC5155] refers to validating responses throughout the document, 1515 in the context of hashed authenticated denial of existence; this 1516 uses the second definition above. 1518 The term "authentication" is used interchangeably with 1519 "validation", in the sense of the third definition above. 1520 [RFC4033], Section 2, describes the chain linking trust anchor to 1521 DNS data as the "authentication chain". A response is considered 1522 to be authentic if "all RRsets in the Answer and Authority 1523 sections of the response [are considered] to be authentic" (Quoted 1524 from [RFC4035]) DNS data or responses deemed to be authentic or 1525 validated have a security status of "secure" ([RFC4035], 1526 Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys 1527 and data is a matter of local policy, which may extend or even 1528 override the [DNSSEC] protocol extensions..." (Quoted from 1529 [RFC4033], Section 3.1) 1531 The term "verification", when used, is usually a synonym for 1532 "validation". 1534 Validating resolver: A security-aware recursive name server, 1535 security-aware resolver, or security-aware stub resolver that is 1536 applying at least one of the definitions of validation (above), as 1537 appropriate to the resolution context. For the same reason that 1538 the generic term "resolver" is sometimes ambiguous and needs to be 1539 evaluated in context (see Section 6), "validating resolver" is a 1540 context-sensitive term. 1542 Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY 1543 RRset in a zone." (Quoted from [RFC6781], Section 3.1) 1545 Zone signing key (ZSK): "DNSSEC keys that can be used to sign all 1546 the RRsets in a zone that require signatures, other than the apex 1547 DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note 1548 that a ZSK is sometimes used to sign the apex DNSKEY RRset. 1550 Combined signing key (CSK): "In cases where the differentiation 1551 between the KSK and ZSK is not made, i.e., where keys have the 1552 role of both KSK and ZSK, we talk about a Single-Type Signing 1553 Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes 1554 called a "combined signing key" or "CSK". It is operational 1555 practice, not protocol, that determines whether a particular key 1556 is a ZSK, a KSK, or a CSK. 1558 Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be 1559 used to distinguish between keys that are intended to be used as 1560 the secure entry point into the zone when building chains of 1561 trust, i.e., they are (to be) pointed to by parental DS RRs or 1562 configured as a trust anchor.... Therefore, it is suggested that 1563 the SEP flag be set on keys that are used as KSKs and not on keys 1564 that are used as ZSKs, while in those cases where a distinction 1565 between a KSK and ZSK is not made (i.e., for a Single-Type Signing 1566 Scheme), it is suggested that the SEP flag be set on all keys." 1567 (Quoted from [RFC6781], Section 3.2.3) Note that the SEP flag is 1568 only a hint, and its presence or absence may not be used to 1569 disqualify a given DNSKEY RR from use as a KSK or ZSK during 1570 validation. 1572 The original definition of SEPs was in [RFC3757]. That definition 1573 clearly indicated that the SEP was a key, not just a bit in the 1574 key. The abstract of [RFC3757] says: "With the Delegation Signer 1575 (DS) resource record (RR), the concept of a public key acting as a 1576 secure entry point (SEP) has been introduced. During exchanges of 1577 public keys with the parent there is a need to differentiate SEP 1578 keys from other public keys in the Domain Name System KEY (DNSKEY) 1579 resource record set. A flag bit in the DNSKEY RR is defined to 1580 indicate that DNSKEY is to be used as a SEP." That definition of 1581 the SEP as a key was made obsolete by [RFC4034], and the 1582 definition from [RFC6781] is consistent with [RFC4034]. 1584 Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 1585 A validating security-aware resolver uses this public key or hash 1586 as a starting point for building the authentication chain to a 1587 signed DNS response. In general, a validating resolver will have 1588 to obtain the initial values of its trust anchors via some secure 1589 or trusted means outside the DNS protocol." (Quoted from 1590 [RFC4033], Section 2) 1592 DNSSEC Policy (DP): A statement that "sets forth the security 1593 requirements and standards to be implemented for a DNSSEC-signed 1594 zone." (Quoted from [RFC6841], Section 2) 1596 DNSSEC Practice Statement (DPS): "A practices disclosure document 1597 that may support and be a supplemental document to the DNSSEC 1598 Policy (if such exists), and it states how the management of a 1599 given zone implements procedures and controls at a high level." 1600 (Quoted from [RFC6841], Section 2) 1602 Hardware security module (HSM): A specialized piece of hardware that 1603 is used to create keys for signatures and to sign messages without 1604 ever disclosing the private key. In DNSSEC, HSMs are often used 1605 to hold the private keys for KSKs and ZSKs and to create the 1606 signatures used in RRSIG records at periodic intervals. 1608 Signing software: Authoritative DNS servers that support DNSSEC 1609 often contain software that facilitates the creation and 1610 maintenance of DNSSEC signatures in zones. There is also stand- 1611 alone software that can be used to sign a zone regardless of 1612 whether the authoritative server itself supports signing. 1613 Sometimes signing software can support particular HSMs as part of 1614 the signing process. 1616 11. DNSSEC States 1618 A validating resolver can determine that a response is in one of four 1619 states: secure, insecure, bogus, or indeterminate. These states are 1620 defined in [RFC4033] and [RFC4035], although the definitions in the 1621 two documents differ a bit. This document makes no effort to 1622 reconcile the definitions in the two documents, and takes no position 1623 as to whether they need to be reconciled. 1625 Section 5 of [RFC4033] says: 1627 A validating resolver can determine the following 4 states: 1629 Secure: The validating resolver has a trust anchor, has a chain 1630 of trust, and is able to verify all the signatures in the 1631 response. 1633 Insecure: The validating resolver has a trust anchor, a chain 1634 of trust, and, at some delegation point, signed proof of the 1635 non-existence of a DS record. This indicates that subsequent 1636 branches in the tree are provably insecure. A validating 1637 resolver may have a local policy to mark parts of the domain 1638 space as insecure. 1640 Bogus: The validating resolver has a trust anchor and a secure 1641 delegation indicating that subsidiary data is signed, but 1642 the response fails to validate for some reason: missing 1643 signatures, expired signatures, signatures with unsupported 1644 algorithms, data missing that the relevant NSEC RR says 1645 should be present, and so forth. 1647 Indeterminate: There is no trust anchor that would indicate that a 1648 specific portion of the tree is secure. This is the default 1649 operation mode. 1651 Section 4.3 of [RFC4035] says: 1653 A security-aware resolver must be able to distinguish between four 1654 cases: 1656 Secure: An RRset for which the resolver is able to build a chain 1657 of signed DNSKEY and DS RRs from a trusted security anchor to 1658 the RRset. In this case, the RRset should be signed and is 1659 subject to signature validation, as described above. 1661 Insecure: An RRset for which the resolver knows that it has no 1662 chain of signed DNSKEY and DS RRs from any trusted starting 1663 point to the RRset. This can occur when the target RRset lies 1664 in an unsigned zone or in a descendent [sic] of an unsigned 1665 zone. In this case, the RRset may or may not be signed, but 1666 the resolver will not be able to verify the signature. 1668 Bogus: An RRset for which the resolver believes that it ought to 1669 be able to establish a chain of trust but for which it is 1670 unable to do so, either due to signatures that for some reason 1671 fail to validate or due to missing data that the relevant 1672 DNSSEC RRs indicate should be present. This case may indicate 1673 an attack but may also indicate a configuration error or some 1674 form of data corruption. 1676 Indeterminate: An RRset for which the resolver is not able to 1677 determine whether the RRset should be signed, as the resolver 1678 is not able to obtain the necessary DNSSEC RRs. This can occur 1679 when the security-aware resolver is not able to contact 1680 security-aware name servers for the relevant zones. 1682 12. Security Considerations 1684 These definitions do not change any security considerations for the 1685 DNS. 1687 13. IANA Considerations 1689 This document has no IANA actions. 1691 14. References 1693 14.1. Normative References 1695 [IANA_RootFiles] 1696 IANA, "Root Files", 1697 . 1699 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1700 RFC 882, DOI 10.17487/RFC0882, November 1983, 1701 . 1703 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1704 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1705 . 1707 [RFC1035] Mockapetris, P., "Domain names - implementation and 1708 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1709 November 1987, . 1711 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1712 Application and Support", STD 3, RFC 1123, 1713 DOI 10.17487/RFC1123, October 1989, 1714 . 1716 [RFC1912] Barr, D., "Common DNS Operational and Configuration 1717 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 1718 . 1720 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1721 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1722 August 1996, . 1724 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1725 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1726 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1727 . 1729 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1730 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1731 . 1733 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 1734 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 1735 DOI 10.17487/RFC2182, July 1997, 1736 . 1738 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1739 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1740 . 1742 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1743 Rose, "DNS Security Introduction and Requirements", 1744 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1745 . 1747 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1748 Rose, "Resource Records for the DNS Security Extensions", 1749 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1750 . 1752 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1753 Rose, "Protocol Modifications for the DNS Security 1754 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1755 . 1757 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1758 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 1759 . 1761 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1762 Security (DNSSEC) Hashed Authenticated Denial of 1763 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1764 . 1766 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 1767 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 1768 DOI 10.17487/RFC5358, October 2008, 1769 . 1771 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1772 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1773 . 1775 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1776 Domain Name Mapping", STD 69, RFC 5731, 1777 DOI 10.17487/RFC5731, August 2009, 1778 . 1780 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 1781 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, 1782 May 2010, . 1784 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1785 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1786 . 1788 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, 1789 "Recommendations for the Remediation of Bots in ISP 1790 Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, 1791 . 1793 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1794 Operational Practices, Version 2", RFC 6781, 1795 DOI 10.17487/RFC6781, December 2012, 1796 . 1798 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 1799 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 1800 DOI 10.17487/RFC6840, February 2013, 1801 . 1803 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 1804 Framework for DNSSEC Policies and DNSSEC Practice 1805 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 1806 . 1808 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1809 for DNS (EDNS(0))", STD 75, RFC 6891, 1810 DOI 10.17487/RFC6891, April 2013, 1811 . 1813 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1814 DNSSEC Delegation Trust Maintenance", RFC 7344, 1815 DOI 10.17487/RFC7344, September 2014, 1816 . 1818 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1819 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1820 2015, . 1822 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1823 for DNS over TLS and DNS over DTLS", RFC 8310, 1824 DOI 10.17487/RFC8310, March 2018, 1825 . 1827 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1828 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1829 January 2019, . 1831 14.2. Informative References 1833 [I-D.ietf-dprive-dnsoquic] 1834 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1835 of DNS over Dedicated QUIC Connections", Work in Progress, 1836 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 1837 2021, . 1840 [IANA_Resource_Registry] 1841 IANA, "Resource Record (RR) TYPEs", 1842 . 1844 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 1845 Internet User Applications", RFC 819, 1846 DOI 10.17487/RFC0819, August 1982, 1847 . 1849 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1850 host table specification", RFC 952, DOI 10.17487/RFC0952, 1851 October 1985, . 1853 [RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713, 1854 DOI 10.17487/RFC1713, November 1994, 1855 . 1857 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1858 DOI 10.17487/RFC1995, August 1996, 1859 . 1861 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1862 DOI 10.17487/RFC2775, February 2000, 1863 . 1865 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1866 Requirements for the Address and Routing Parameter Area 1867 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1868 September 2001, . 1870 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, 1871 DOI 10.17487/RFC3425, November 2002, 1872 . 1874 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 1875 Stevens, "Basic Socket Interface Extensions for IPv6", 1876 RFC 3493, DOI 10.17487/RFC3493, February 2003, 1877 . 1879 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 1880 System KEY (DNSKEY) Resource Record (RR) Secure Entry 1881 Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April 1882 2004, . 1884 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1885 DOI 10.17487/RFC3912, September 2004, 1886 . 1888 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1889 RFC 4641, DOI 10.17487/RFC4641, September 2006, 1890 . 1892 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution 1893 Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, 1894 October 2006, . 1896 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1897 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1898 December 2006, . 1900 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1901 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 1902 2007, . 1904 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1905 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1906 . 1908 [RFC5890] Klensin, J., "Internationalized Domain Names for 1909 Applications (IDNA): Definitions and Document Framework", 1910 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1911 . 1913 [RFC5891] Klensin, J., "Internationalized Domain Names in 1914 Applications (IDNA): Protocol", RFC 5891, 1915 DOI 10.17487/RFC5891, August 2010, 1916 . 1918 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1919 Internationalized Domain Names for Applications (IDNA)", 1920 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1921 . 1923 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 1924 for Internationalized Domain Names for Applications 1925 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 1926 . 1928 [RFC5894] Klensin, J., "Internationalized Domain Names for 1929 Applications (IDNA): Background, Explanation, and 1930 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 1931 . 1933 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 1934 Encodings for Internationalized Domain Names", RFC 6055, 1935 DOI 10.17487/RFC6055, February 2011, 1936 . 1938 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1939 DOI 10.17487/RFC6265, April 2011, 1940 . 1942 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 1943 RFC 6303, DOI 10.17487/RFC6303, July 2011, 1944 . 1946 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1947 Cheshire, "Internet Assigned Numbers Authority (IANA) 1948 Procedures for the Management of the Service Name and 1949 Transport Protocol Port Number Registry", BCP 165, 1950 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1951 . 1953 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1954 Internationalization in the IETF", BCP 166, RFC 6365, 1955 DOI 10.17487/RFC6365, September 2011, 1956 . 1958 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 1959 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 1960 . 1962 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1963 DOI 10.17487/RFC6762, February 2013, 1964 . 1966 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1967 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 1968 February 2014, . 1970 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1971 Registration Data Access Protocol (RDAP)", STD 95, 1972 RFC 7480, DOI 10.17487/RFC7480, March 2015, 1973 . 1975 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 1976 Registration Data Access Protocol (RDAP)", STD 95, 1977 RFC 7481, DOI 10.17487/RFC7481, March 2015, 1978 . 1980 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 1981 Protocol (RDAP) Query Format", RFC 7482, 1982 DOI 10.17487/RFC7482, March 2015, 1983 . 1985 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 1986 Registration Data Access Protocol (RDAP)", RFC 7483, 1987 DOI 10.17487/RFC7483, March 2015, 1988 . 1990 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1991 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1992 2015, . 1994 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 1995 "Inventory and Analysis of WHOIS Registration Objects", 1996 RFC 7485, DOI 10.17487/RFC7485, March 2015, 1997 . 1999 [RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4 2000 Locally-Served DNS Zones Registry", BCP 163, RFC 7793, 2001 DOI 10.17487/RFC7793, May 2016, 2002 . 2004 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2005 and P. Hoffman, "Specification for DNS over Transport 2006 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2007 2016, . 2009 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 2010 Transport Layer Security (DTLS)", RFC 8094, 2011 DOI 10.17487/RFC8094, February 2017, 2012 . 2014 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS 2015 Resolver with Priming Queries", BCP 209, RFC 8109, 2016 DOI 10.17487/RFC8109, March 2017, 2017 . 2019 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 2020 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 2021 . 2023 [RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC 2024 Lexicon", 2017, 2025 . 2028 Appendix A. Definitions Updated by This Document 2030 The following definitions from RFCs are updated by this document: 2032 * Forwarder in [RFC2308] 2034 * QNAME in [RFC2308] 2036 * Secure Entry Point (SEP) in [RFC3757]; note, however, that this 2037 RFC is already obsolete (see [RFC4033], [RFC4034], [RFC4035]). 2039 Appendix B. Definitions First Defined in This Document 2041 The following definitions are first defined in this document: 2043 * "Alias" in Section 2 2045 * "Apex" in Section 7 2047 * "arpa" in Section 7 2049 * "Authoritative DoT (ADot)" in Section 6 2051 * "Bailiwick" in Section 7 2053 * "Class independent" in Section 5 2055 * "Classic DNS" in Section 6 2057 * "Delegation-centric zone" in Section 7 2059 * "Delegation" in Section 7 2061 * "DNS operator" in Section 9 2063 * "DNSSEC-aware" in Section 10 2065 * "DNSSEC-unaware" in Section 10 2067 * "Forwarding" in Section 6 2069 * "Full resolver" in Section 6 2071 * "Fully-qualified domain name" in Section 2 2073 * "Global DNS" in Section 2 2075 * "Hardware Security Module (HSM)" in Section 10 2076 * "Host name" in Section 2 2078 * "IDN" in Section 2 2080 * "In-bailiwick" in Section 7 2082 * "Iterative resolution" in Section 6 2084 * "Label" in Section 2 2086 * "Locally served DNS zone" in Section 2 2088 * "Naming system" in Section 2 2090 * "Negative response" in Section 3 2092 * "Non-recursive query" in Section 6 2094 * "Open resolver" in Section 6 2096 * "Out-of-bailiwick" in Section 7 2098 * "Passive DNS" in Section 6 2100 * "Policy-implementing resolver" in Section 6 2102 * "Presentation format" in Section 5 2104 * "Priming" in Section 6 2106 * "Private DNS" in Section 2 2108 * "Recrusive DoT (RDot)" in Section 6 2110 * "Recursive resolver" in Section 6 2112 * "Referrals" in Section 4 2114 * "Registrant" in Section 9 2116 * "Registrar" in Section 9 2118 * "Registry" in Section 9 2120 * "Root zone" in Section 7 2122 * "Secure Entry Point (SEP)" in Section 10 2123 * "Signing software" in Section 10 2125 * "Split DNS" in Section 6 2127 * "Stub resolver" in Section 6 2129 * "Subordinate" in Section 8 2131 * "Superordinate" in Section 8 2133 * "TLD" in Section 2 2135 * "Validating resolver" in Section 10 2137 * "Validation" in Section 10 2139 * "View" in Section 6 2141 * "Zone transfer" in Section 6 2143 Acknowledgements 2145 RFC 8499 and its predecessor, RFC 7719, were co-authored by Andrew 2146 Sullivan. The current document, which is a small update to RFC 8499, 2147 has just two authors. Andrew's work on the earlier documents is 2148 greatly appreciated. 2150 Numerous people made significant contributions to RFC 8499 and RFC 2151 7719. Please see the acknowledgements sections in those two 2152 documents for the extensive list of contributors. 2154 Index 2156 A C D E F G H I K L M N O P Q R S T U V W Z 2158 A 2159 ADoT 2160 ADoT 2161 Address records 2162 Address records 2163 Alias 2164 Alias 2165 Anycast 2166 Anycast 2167 Apex 2168 Apex 2169 Asterisk label 2170 Asterisk label 2172 Authoritative data 2173 Authoritative data 2174 Authoritative server 2175 Authoritative server 2176 Authoritative-only server 2177 Authoritative-only server 2178 arpa: Address and Routing Parameter Area Domain 2179 arpa: Address and Routing Parameter Area Domain 2180 C 2181 CNAME 2182 CNAME 2183 Canonical name 2184 Canonical name 2185 Child 2186 Child 2187 Class independent 2188 Class independent 2189 Classic DNS 2190 Classic DNS 2191 Class 2192 Class 2193 Closest encloser 2194 Closest encloser 2195 Closest provable encloser 2196 Closest provable encloser 2197 Combined signing key (CSK) 2198 Combined signing key (CSK) 2199 D 2200 DNS operator 2201 DNS operator 2202 DNS-over-HTTPS 2203 DNS-over-HTTPS 2204 DNS-over-QUIC 2205 DNS-over-QUIC 2206 DNS-over-TLS 2207 DNS-over-TLS 2208 DNSSEC Policy (DP) 2209 DNSSEC Policy (DP) 2210 DNSSEC Practice Statement (DPS) 2211 DNSSEC Practice Statement (DPS) 2212 DNSSEC-aware and DNSSEC-unaware 2213 DNSSEC-aware and DNSSEC-unaware 2214 Delegation-centric zone 2215 Delegation-centric zone 2216 Delegation 2217 Delegation 2218 DoH 2219 DoH 2221 DoQ 2222 DoQ 2223 DoT 2224 DoT 2225 Domain name 2226 Domain name 2227 E 2228 EDNS 2229 EDNS 2230 EPP 2231 EPP 2232 Empty non-terminals (ENT) 2233 Empty non-terminals (ENT) 2234 F 2235 FORMERR 2236 FORMERR 2237 Fast flux DNS 2238 Fast flux DNS 2239 Forward lookup 2240 Forward lookup 2241 Forwarder 2242 Forwarder 2243 Forwarding 2244 Forwarding 2245 Full resolver 2246 Full resolver 2247 Full-service resolver 2248 Full-service resolver 2249 Fully-qualified domain name (FQDN) 2250 Fully-qualified domain name (FQDN) 2251 G 2252 Global DNS 2253 Global DNS 2254 Glue records 2255 Glue records 2256 H 2257 Hardware security module (HSM) 2258 Hardware security module (HSM) 2259 Hidden master 2260 Hidden master 2261 Host name 2262 Host name 2263 I 2264 IDN 2265 IDN 2266 In-bailiwick 2267 In-bailiwick 2268 Insecure delegation 2269 Insecure delegation 2270 Instance 2271 Instance 2272 Internationalized Domain Name 2273 Internationalized Domain Name 2274 Iterative mode 2275 Iterative mode 2276 Iterative resolution 2277 Iterative resolution 2278 K 2279 Key signing key (KSK) 2280 Key signing key (KSK) 2281 L 2282 Label 2283 Label 2284 Lame delegation 2285 Lame delegation 2286 Locally served DNS zone 2287 Locally served DNS zone 2288 M 2289 Master file 2290 Master file 2291 Master server 2292 Master server 2293 Multicast DNS 2294 Multicast DNS 2295 mDNS 2296 mDNS 2297 N 2298 NODATA 2299 NODATA 2300 NOERROR 2301 NOERROR 2302 NOTIMP 2303 NOTIMP 2304 NSEC3 2305 NSEC3 2306 NSEC 2307 NSEC 2308 NS 2309 NS 2310 NXDOMAIN 2311 NXDOMAIN 2312 Naming system 2313 Naming system 2314 Negative caching 2315 Negative caching 2316 Negative response 2317 Negative response 2318 Next closer name 2319 Next closer name 2320 Non-recursive query 2321 Non-recursive query 2322 O 2323 OPT 2324 OPT 2325 Occluded name 2326 Occluded name 2327 Open resolver 2328 Open resolver 2329 Opt-out 2330 Opt-out 2331 Origin 2332 Origin 2333 Out-of-bailiwick 2334 Out-of-bailiwick 2335 Owner 2336 Owner 2337 P 2338 Parent 2339 Parent 2340 Passive DNS 2341 Passive DNS 2342 Policy-implementing resolver 2343 Policy-implementing resolver 2344 Presentation format 2345 Presentation format 2346 Primary master 2347 Primary master 2348 Primary server 2349 Primary server 2350 Priming 2351 Priming 2352 Privacy-enabling DNS server 2353 Privacy-enabling DNS server 2354 Private DNS 2355 Private DNS 2356 Public suffix 2357 Public suffix 2358 Q 2359 QNAME 2360 QNAME 2361 R 2362 RDAP 2363 RDAP 2364 RDoT 2365 RDoT 2366 REFUSED 2367 REFUSED 2368 RRset 2369 RRset 2370 RR 2371 RR 2372 Recursive DoT 2373 Recursive DoT 2374 Recursive mode 2375 Recursive mode 2376 Recursive query 2377 Recursive query 2378 Recursive resolver 2379 Recursive resolver 2380 Referrals 2381 Referrals 2382 Registrant 2383 Registrant 2384 Registrar 2385 Registrar 2386 Registry 2387 Registry 2388 Resolver 2389 Resolver 2390 Reverse DNS, reverse lookup 2391 Reverse DNS, reverse lookup 2392 Root hints 2393 Root hints 2394 Root zone 2395 Root zone 2396 S 2397 SERVFAIL 2398 SERVFAIL 2399 SOA field names 2400 SOA field names 2401 SOA 2402 SOA 2403 Secondary server 2404 Secondary server 2405 Secure Entry Point (SEP) 2406 Secure Entry Point (SEP) 2407 Service name 2408 Service name 2409 Signed zone 2410 Signed zone 2411 Signing software 2412 Signing software 2414 Slave server 2415 Slave server 2416 Source of Synthesis 2417 Source of Synthesis 2418 Split DNS 2419 Split DNS 2420 Split-horizon DNS 2421 Split-horizon DNS 2422 Stealth server 2423 Stealth server 2424 Stub resolver 2425 Stub resolver 2426 Subdomain 2427 Subdomain 2428 Subordinate 2429 Subordinate 2430 Superordinate 2431 Superordinate 2432 T 2433 TLD 2434 TLD 2435 TTL 2436 TTL 2437 Trust anchor 2438 Trust anchor 2439 U 2440 Unsigned zone 2441 Unsigned zone 2442 V 2443 Validating resolver 2444 Validating resolver 2445 Validation 2446 Validation 2447 View 2448 View 2449 W 2450 WHOIS 2451 WHOIS 2452 Wildcard domain name 2453 Wildcard domain name 2454 Wildcard 2455 Wildcard 2456 Z 2457 Zone cut 2458 Zone cut 2459 Zone enumeration 2460 Zone enumeration 2461 Zone signing key (ZSK) 2462 Zone signing key (ZSK) 2463 Zone transfer 2464 Zone transfer 2465 Zone 2466 Zone 2468 Authors' Addresses 2470 Paul Hoffman 2471 ICANN 2473 Email: paul.hoffman@icann.org 2475 Kazunori Fujiwara 2476 Japan Registry Services Co., Ltd. 2478 Email: fujiwara@jprs.co.jp