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