idnits 2.17.1 draft-ietf-dnsop-terminology-bis-11.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 : ---------------------------------------------------------------------------- ** 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 578: '... [RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated...' RFC 2119 keyword, line 1099: '...s. An in-domain name server name MUST...' RFC 2119 keyword, line 1359: '...se, the resolver SHOULD treat the chil...' -- The draft header indicates that this document obsoletes RFC7719, but the abstract doesn't seem to directly say this. It does mention RFC7719 though, so this could be OK. -- The draft header indicates that this document updates RFC2308, but the abstract doesn't seem to directly say this. It does mention RFC2308 though, so this could be OK. 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 (July 16, 2018) is 2110 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: 'DNSSEC' is mentioned on line 1447, but not defined ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) ** Downref: Normative reference to an Informational RFC: RFC 1912 ** Obsolete normative reference: RFC 3731 (Obsoleted by RFC 4931) ** 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 informational reference (is this intentional?): RFC 2133 (Obsoleted by RFC 2553) -- 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 (~~), 2 warnings (==), 10 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: 7719 (if approved) A. Sullivan 5 Updates: 2308 (if approved) Oracle 6 Intended status: Best Current Practice K. Fujiwara 7 Expires: January 17, 2019 JPRS 8 July 16, 2018 10 DNS Terminology 11 draft-ietf-dnsop-terminology-bis-11 13 Abstract 15 The domain name system (DNS) is defined in literally dozens of 16 different RFCs. The terminology used by implementers and developers 17 of DNS protocols, and by operators of DNS systems, has sometimes 18 changed in the decades since the DNS was first defined. This 19 document gives current definitions for many of the terms used in the 20 DNS in a single document. 22 This document will be the successor to RFC 7719, and thus will 23 obsolete RFC 7719. It will also update RFC 2308. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 17, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9 62 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 10 63 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 12 64 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 14 65 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 66 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 25 67 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 26 68 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 28 69 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 33 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 71 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 34 74 14.2. Informative References . . . . . . . . . . . . . . . . . 37 75 Appendix A. Definitions Updated by this Document . . . . . . . . 41 76 Appendix B. Definitions First Defined in this Document . . . . . 41 77 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 78 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 81 1. Introduction 83 The Domain Name System (DNS) is a simple query-response protocol 84 whose messages in both directions have the same format. (Section 2 85 gives a definition of "public DNS", which is often what people mean 86 when they say "the DNS".) The protocol and message format are 87 defined in [RFC1034] and [RFC1035]. These RFCs defined some terms, 88 but later documents defined others. Some of the terms from [RFC1034] 89 and [RFC1035] now have somewhat different meanings than they did in 90 1987. 92 This document collects a wide variety of DNS-related terms. Some of 93 them have been precisely defined in earlier RFCs, some have been 94 loosely defined in earlier RFCs, and some are not defined in any 95 earlier RFC at all. 97 Most of the definitions here are the consensus definition of the DNS 98 community -- both protocol developers and operators. Some of the 99 definitions differ from earlier RFCs, and those differences are 100 noted. In this document, where the consensus definition is the same 101 as the one in an RFC, that RFC is quoted. Where the consensus 102 definition has changed somewhat, the RFC is mentioned but the new 103 stand-alone definition is given. See Appendix A for a list of the 104 definitions that this document updates. 106 It is important to note that, during the development of this 107 document, it became clear that some DNS-related terms are interpreted 108 quite differently by different DNS experts. Further, some terms that 109 are defined in early DNS RFCs now have definitions that are generally 110 agreed to, but that are different from the original definitions. 111 Therefore, this document is a substantial revision to [RFC7719]. 113 The terms are organized loosely by topic. Some definitions are for 114 new terms for things that are commonly talked about in the DNS 115 community but that never had terms defined for them. 117 Other organizations sometimes define DNS-related terms their own way. 118 For example, the W3C defines "domain" at 119 . The Root Server System Advisory 120 Committee (RSSAC) has a good lexicon [RSSAC026]. 122 Note that there is no single consistent definition of "the DNS". It 123 can be considered to be some combination of the following: a commonly 124 used naming scheme for objects on the Internet; a distributed 125 database representing the names and certain properties of these 126 objects; an architecture providing distributed maintenance, 127 resilience, and loose coherency for this database; and a simple 128 query-response protocol (as mentioned below) implementing this 129 architecture. Section 2 defines "global DNS" and "private DNS" as a 130 way to deal with these differing definitions. 132 Capitalization in DNS terms is often inconsistent among RFCs and 133 various DNS practitioners. The capitalization used in this document 134 is a best guess at current practices, and is not meant to indicate 135 that other capitalization styles are wrong or archaic. In some 136 cases, multiple styles of capitalization are used for the same term 137 due to quoting from different RFCs. 139 2. Names 141 Naming system: A naming system associates names with data. Naming 142 systems have many significant facets that help differentiate them. 143 Some commonly-identified facets include: 145 * Composition of names 147 * Format of names 149 * Administration of names 151 * Types of data that can be associated with names 153 * Types of metadata for names 155 * Protocol for getting data from a name 157 * Context for resolving a name 159 Note that this list is a small subset of facets that people have 160 identified over time for naming systems, and the IETF has yet to 161 agree on a good set of facets that can be used to compare naming 162 systems. For example, other facets might include "protocol to 163 update data in a name", "privacy of names", and "privacy of data 164 associated with names", but those are not as well-defined as the 165 ones listed above. The list here is chosen because it helps 166 describe the DNS and naming systems similar to the DNS. 168 Domain name: An ordered list of one or more labels. 170 Note that this is a definition independent of the DNS RFCs, and 171 the definition here also applies to systems other than the DNS. 172 [RFC1034] defines the "domain name space" using mathematical trees 173 and their nodes in graph theory, and this definition has the same 174 practical result as the definition here. Using graph theory, a 175 domain name is a list of labels identifying a portion along one 176 edge of a directed acyclic graph. A domain name can be relative 177 to parts of the tree, or it can be fully qualified (in which case, 178 it begins at the common root of the graph). 180 Also note that different IETF and non-IETF documents have used the 181 term "domain name" in many different ways. It is common for 182 earlier documents to use "domain name" to mean "names that match 183 the syntax in [RFC1035]", but possibly with additional rules such 184 as "and are, or will be, resolvable in the global DNS" or "but 185 only using the presentation format". 187 Label: An ordered list of zero or more octets and which makes up a 188 portion of a domain name. Using graph theory, a label identifies 189 one node in a portion of the graph of all possible domain names. 191 Global DNS: Using the short set of facets listed in "Naming system", 192 the global DNS can be defined as follows. Most of the rules here 193 come from [RFC1034] and [RFC1035], although the term "global DNS" 194 has not been defined before now. 196 Composition of names -- A name in the global DNS has one or more 197 labels. The length of each label is between 0 and 63 octets 198 inclusive. In a fully-qualified domain name, the first label in 199 the ordered list is 0 octets long; it is the only label whose 200 length may be 0 octets, and it is called the "root" or "root 201 label". A domain name in the global DNS has a maximum total 202 length of 255 octets in the wire format; the root represents one 203 octet for this calculation. (Multicast DNS [RFC6762] allows names 204 up to 255 bytes plus a terminating zero byte based on a different 205 interpretation of RFC 1035 and what is included in the 255 206 octets.) 208 Format of names -- Names in the global DNS are domain names. 209 There are three formats: wire format, presentation format, and 210 common display. 212 The basic wire format for names in the global DNS is a list of 213 labels ordered by decreasing distance from the root, with the root 214 label last. Each label is preceded by a length octet. [RFC1035] 215 also defines a compression scheme that modifies this format. 217 The presentation format for names in the global DNS is a list of 218 labels ordered by decreasing distance from the root, encoded as 219 ASCII, with a "." character between each label. In presentation 220 format, a fully-qualified domain name includes the root label and 221 the associated separator dot. For example, in presentation 222 format, a fully-qualified domain name with two non-root labels is 223 always shown as "example.tld." instead of "example.tld". 224 [RFC1035] defines a method for showing octets that do not display 225 in ASCII. 227 The common display format is used in applications and free text. 228 It is the same as the presentation format, but showing the root 229 label and the "." before it is optional and is rarely done. For 230 example, in common display format, a fully-qualified domain name 231 with two non-root labels is usually shown as "example.tld" instead 232 of "example.tld.". Names in the common display format are 233 normally written such that the directionality of the writing 234 system presents labels by decreasing distance from the root (so, 235 in both English and C the root or TLD label in the ordered list is 236 right-most; but in Arabic it may be left-most, depending on local 237 conventions). 239 Administration of names -- Administration is specified by 240 delegation (see the definition of "delegation" in Section 7). 242 Policies for administration of the root zone in the global DNS are 243 determined by the names operational community, which convenes 244 itself in the Internet Corporation for Assigned Names and Numbers 245 (ICANN). The names operational community selects the IANA 246 Functions Operator for the global DNS root zone. At the time this 247 document is published, that operator is Public Technical 248 Identifiers (PTI). The name servers that serve the root zone are 249 provided by independent root operators. Other zones in the global 250 DNS have their own policies for administration. 252 Types of data that can be associated with names -- A name can have 253 zero or more resource records associated with it. There are 254 numerous types of resource records with unique data structures 255 defined in many different RFCs and in the IANA registry at 256 [IANA_Resource_Registry]. 258 Types of metadata for names -- Any name that is published in the 259 DNS appears as a set of resource records (see the definition of 260 "RRset" in Section 5). Some names do not themselves have data 261 associated with them in the DNS, but "appear" in the DNS anyway 262 because they form part of a longer name that does have data 263 associated with it (see the definition of "empty non-terminals" in 264 Section 7). 266 Protocol for getting data from a name -- The protocol described in 267 [RFC1035]. 269 Context for resolving a name -- The global DNS root zone 270 distributed by PTI. 272 Private DNS: Names that use the protocol described in [RFC1035] but 273 that do not rely on the global DNS root zone, or names that are 274 otherwise not generally available on the Internet but are using 275 the protocol described in [RFC1035]. A system can use both the 276 global DNS and one or more private DNS systems; for example, see 277 "Split DNS" in Section 6. 279 Note that domain names that do not appear in the DNS, and that are 280 intended never to be looked up using the DNS protocol, are not 281 part of the global DNS or a private DNS even though they are 282 domain names. 284 Multicast DNS: "Multicast DNS (mDNS) provides the ability to perform 285 DNS-like operations on the local link in the absence of any 286 conventional Unicast DNS server. In addition, Multicast DNS 287 designates a portion of the DNS namespace to be free for local 288 use, without the need to pay any annual fee, and without the need 289 to set up delegations or otherwise configure a conventional DNS 290 server to answer for those names." (Quoted from [RFC6762], 291 Abstract) Although it uses a compatible wire format, mDNS is 292 strictly speaking a different protocol than DNS. Also, where the 293 above quote says "a portion of the DNS namespace", it would be 294 clearer to say "a portion of the domain name space" The names in 295 mDNS are not intended to be looked up in the DNS. 297 Locally served DNS zone: A locally served DNS zone is a special case 298 of private DNS. Names are resolved using the DNS protocol in a 299 local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that 300 are locally served zones. Resolution of names through locally 301 served zones may result in ambiguous results. For example, the 302 same name may resolve to different results in different locally 303 served DNS zone contexts. The context through which a locally 304 served zone may be explicit, for example, as defined in [RFC6303], 305 or implicit, as defined by local DNS administration and not known 306 to the resolution client. 308 Fully qualified domain name (FQDN): This is often just a clear way 309 of saying the same thing as "domain name of a node", as outlined 310 above. However, the term is ambiguous. Strictly speaking, a 311 fully qualified domain name would include every label, including 312 the zero-length label of the root: such a name would be written 313 "www.example.net." (note the terminating dot). But because every 314 name eventually shares the common root, names are often written 315 relative to the root (such as "www.example.net") and are still 316 called "fully qualified". This term first appeared in [RFC0819]. 317 In this document, names are often written relative to the root. 319 The need for the term "fully qualified domain name" comes from the 320 existence of partially qualified domain names, which are names 321 where one or more of the earliest labels in the ordered list are 322 omitted (for example, a name of "www" derived from 323 "www.example.net"). Such relative names are understood only by 324 context. 326 Host name: This term and its equivalent, "hostname", have been 327 widely used but are not defined in [RFC1034], [RFC1035], 328 [RFC1123], or [RFC2181]. The DNS was originally deployed into the 329 Host Tables environment as outlined in [RFC0952], and it is likely 330 that the term followed informally from the definition there. Over 331 time, the definition seems to have shifted. "Host name" is often 332 meant to be a domain name that follows the rules in Section 3.5 of 333 [RFC1034], the "preferred name syntax" (that is, every character 334 in each label is a letter, a digit, or a hyphen). Note that any 335 label in a domain name can contain any octet value; hostnames are 336 generally considered to be domain names where every label follows 337 the rules in the "preferred name syntax", with the amendment that 338 labels can start with ASCII digits (this amendment comes from 339 Section 2.1 of [RFC1123]). 341 People also sometimes use the term hostname to refer to just the 342 first label of an FQDN, such as "printer" in 343 "printer.admin.example.com". (Sometimes this is formalized in 344 configuration in operating systems.) In addition, people 345 sometimes use this term to describe any name that refers to a 346 machine, and those might include labels that do not conform to the 347 "preferred name syntax". 349 TLD: A Top-Level Domain, meaning a zone that is one layer below the 350 root, such as "com" or "jp". There is nothing special, from the 351 point of view of the DNS, about TLDs. Most of them are also 352 delegation-centric zones (defined in Section 7, and there are 353 significant policy issues around their operation. TLDs are often 354 divided into sub-groups such as Country Code Top-Level Domains 355 (ccTLDs), Generic Top-Level Domains (gTLDs), and others; the 356 division is a matter of policy, and beyond the scope of this 357 document. 359 IDN: The common abbreviation for "Internationalized Domain Name". 360 The IDNA protocol is the standard mechanism for handling domain 361 names with non-ASCII characters in applications in the DNS. The 362 current standard, normally called "IDNA2008", is defined in 363 [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These 364 documents define many IDN-specific terms such as "LDH label", 365 "A-label", and "U-label". [RFC6365] defines more terms that 366 relate to internationalization (some of which relate to IDNs), and 367 [RFC6055] has a much more extensive discussion of IDNs, including 368 some new terminology. 370 Subdomain: "A domain is a subdomain of another domain if it is 371 contained within that domain. This relationship can be tested by 372 seeing if the subdomain's name ends with the containing domain's 373 name." (Quoted from [RFC1034], Section 3.1). For example, in the 374 host name "nnn.mmm.example.com", both "mmm.example.com" and 375 "nnn.mmm.example.com" are subdomains of "example.com". 377 Alias: The owner of a CNAME resource record, or a subdomain of the 378 owner of a DNAME resource record. See also "canonical name". 380 Canonical name: A CNAME resource record "identifies its owner name 381 as an alias, and specifies the corresponding canonical name in the 382 RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) 383 This usage of the word "canonical" is related to the mathematical 384 concept of "canonical form". 386 CNAME: "It is traditional to refer to the owner of a CNAME record as 387 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 388 'canonical name', and the owner of a CNAME record is an alias, not 389 a canonical name." (Quoted from [RFC2181], Section 10.1.1) 391 3. DNS Response Codes 393 Some of response codes that are defined in [RFC1035] have acquired 394 their own shorthand names. All of the RCODEs are listed at 395 [IANA_Resource_Registry], although that site uses mixed-case 396 capitalization, while most documents use all-caps. Some of the 397 common names are described here, but the official list is in the IANA 398 registry. 400 NOERROR: "No error condition" (Quoted from [RFC1035], 401 Section 4.1.1.) 403 FORMERR: "Format error - The name server was unable to interpret the 404 query." (Quoted from [RFC1035], Section 4.1.1.) 406 SERVFAIL: "Server failure - The name server was unable to process 407 this query due to a problem with the name server." (Quoted from 408 [RFC1035], Section 4.1.1.) 410 NXDOMAIN: "Name Error - This code signifies that the domain name 411 referenced in the query does not exist." (Quoted from [RFC1035], 412 Section 4.1.1.) [RFC2308] established NXDOMAIN as a synonym for 413 Name Error. 415 NOTIMP: "Not Implemented - The name server does not support the 416 requested kind of query." (Quoted from [RFC1035], Section 4.1.1.) 418 REFUSED: "Refused - The name server refuses to perform the specified 419 operation for policy reasons. For example, a name server may not 420 wish to provide the information to the particular requester, or a 421 name server may not wish to perform a particular operation (e.g., 422 zone transfer) for particular data." (Quoted from [RFC1035], 423 Section 4.1.1.) 425 NODATA: "A pseudo RCODE which indicates that the name is valid for 426 the given class, but there are no records of the given type. A 427 NODATA response has to be inferred from the answer." (Quoted from 428 [RFC2308], Section 1.) "NODATA is indicated by an answer with the 429 RCODE set to NOERROR and no relevant answers in the answer 430 section. The authority section will contain an SOA record, or 431 there will be no NS records there." (Quoted from [RFC2308], 432 Section 2.2.) Note that referrals have a similar format to NODATA 433 replies; [RFC2308] explains how to distinguish them. 435 The term "NXRRSET" is sometimes used as a synonym for NODATA. 436 However, this is a mistake, given that NXRRSET is a specific error 437 code defined in [RFC2136]. 439 Negative response: A response that indicates that a particular RRset 440 does not exist, or whose RCODE indicates the nameserver cannot 441 answer. Sections 2 and 7 of [RFC2308] describe the types of 442 negative responses in detail. 444 4. DNS Transactions 446 The header of a DNS message is its first 12 octets. Many of the 447 fields and flags in the header diagram in Sections 4.1.1 through 448 4.1.3 of [RFC1035] are referred to by their names in that diagram. 449 For example, the response codes are called "RCODEs", the data for a 450 record is called the "RDATA", and the authoritative answer bit is 451 often called "the AA flag" or "the AA bit". 453 QNAME: The most commonly-used rough definition is that the QNAME is 454 a field in the Question section of a query. "A standard query 455 specifies a target domain name (QNAME), query type (QTYPE), and 456 query class (QCLASS) and asks for RRs which match." (Quoted from 457 [RFC1034], Section 3.7.1.). Strictly speaking, the definition 458 comes from [RFC1035], Section 4.1.2, where the QNAME is defined in 459 respect of the Question Section. This definition appears to be 460 applied consistently: the discussion of inverse queries in section 461 6.4 refers to the "owner name of the query RR and its TTL", 462 because inverse queries populate the Answer Section and leave the 463 Question Section empty. (Inverse queries are deprecated in 464 [RFC3425], and so relevant definitions do not appear in this 465 document.) 467 [RFC2308], however, has an alternate definition that puts the 468 QNAME in the answer (or series of answers) instead of the query. 469 It defines QNAME as: "...the name in the query section of an 470 answer, or where this resolves to a CNAME, or CNAME chain, the 471 data field of the last CNAME. The last CNAME in this sense is 472 that which contains a value which does not resolve to another 473 CNAME." This definition has a certain internal logic, because of 474 the way CNAME substitution works and the definition of CNAME. If 475 a name server does not find an RRset that matches a query, but it 476 finds the same name in the same class with a CNAME record, then 477 the name server "includes the CNAME record in the response and 478 restarts the query at the domain name specified in the data field 479 of the CNAME record." ([RFC1034] Section 3.6.2). This is made 480 explicit in the resolution algorithm outlined in Section 4.3.2 of 481 [RFC1034], which says to "change QNAME to the canonical name in 482 the CNAME RR, and go back to step 1" in the case of a CNAME RR. 484 Since a CNAME record explicitly declares that the owner name is 485 canonically named what is in the RDATA, then there is a way to 486 view the new name (i.e. the name that was in the RDATA of the 487 CNAME RR) as also being the QNAME. 489 This creates a kind of confusion, however, because the answer to a 490 query that results in CNAME processing contains in the echoed 491 Question Section one QNAME (the name in the original query), and a 492 second QNAME that is in the data field of the last CNAME. The 493 confusion comes from the iterative/recursive mode of resolution, 494 which finally returns an answer that need not actually have the 495 same owner name as the QNAME contained in the original query. 497 To address this potential confusion, it is helpful to distinguish 498 between three meanings: 500 * QNAME (original): The name actually sent in the Question 501 Section in the original query, which is always echoed in the 502 (final) reply in the Question Section when the QR bit is set to 503 1. 505 * QNAME (effective): A name actually resolved, which is either 506 the name originally queried, or a name received in a CNAME 507 chain response. 509 * QNAME (final): The name actually resolved, which is either the 510 name actually queried or else the last name in a CNAME chain 511 response. 513 Note that, because the definition in [RFC2308] is actually for a 514 different concept than what was in [RFC1034], it would have be 515 better if [RFC2308] had used a different name for that concept. 516 In general use today, QNAME almost always means what is defined 517 above as "QNAME (original)". 519 Referrals: A type of response in which a server, signaling that it 520 is not (completely) authoritative for an answer, provides the 521 querying resolver with an alternative place to send its query. 522 Referrals can be partial. 524 A referral arises when a server is not performing recursive 525 service while answering a query. It appears in step 3(b) of the 526 algorithm in [RFC1034], Section 4.3.2. 528 There are two types of referral response. The first is a downward 529 referral (sometimes described as "delegation response"), where the 530 server is authoritative for some portion of the QNAME. The 531 authority section RRset's RDATA contains the name servers 532 specified at the referred-to zone cut. In normal DNS operation, 533 this kind of response is required in order to find names beneath a 534 delegation. The bare use of "referral" means this kind of 535 referral, and many people believe that this is the only legitimate 536 kind of referral in the DNS. 538 The second is an upward referral (sometimes described as "root 539 referral"), where the server is not authoritative for any portion 540 of the QNAME. When this happens, the referred-to zone in the 541 authority section is usually the root zone (.). In normal DNS 542 operation, this kind of response is not required for resolution or 543 for correctly answering any query. There is no requirement that 544 any server send upward referrals. Some people regard upward 545 referrals as a sign of a misconfiguration or error. Upward 546 referrals always need some sort of qualifier (such as "upward" or 547 "root"), and are never identified by the bare word "referral". 549 A response that has only a referral contains an empty answer 550 section. It contains the NS RRset for the referred-to zone in the 551 authority section. It may contain RRs that provide addresses in 552 the additional section. The AA bit is clear. 554 In the case where the query matches an alias, and the server is 555 not authoritative for the target of the alias but it is 556 authoritative for some name above the target of the alias, the 557 resolution algorithm will produce a response that contains both 558 the authoritative answer for the alias, and also a referral. Such 559 a partial answer and referral response has data in the answer 560 section. It has the NS RRset for the referred-to zone in the 561 authority section. It may contain RRs that provide addresses in 562 the additional section. The AA bit is set, because the first name 563 in the answer section matches the QNAME and the server is 564 authoritative for that answer (see [RFC1035], Section 4.1.1). 566 5. Resource Records 568 RR: An acronym for resource record. ([RFC1034], Section 3.6.) 570 RRset: A set of resource records with the same label, class and 571 type, but with different data. (Definition from [RFC2181]) Also 572 spelled RRSet in some documents. As a clarification, "same label" 573 in this definition means "same owner name". In addition, 574 [RFC2181] states that "the TTLs of all RRs in an RRSet must be the 575 same". 577 Note that RRSIG resource records do not match this definition. 578 [RFC4035] says: "An RRset MAY have multiple RRSIG RRs associated 579 with it. Note that as RRSIG RRs are closely tied to the RRsets 580 whose signatures they contain, RRSIG RRs, unlike all other DNS RR 581 types, do not form RRsets. In particular, the TTL values among 582 RRSIG RRs with a common owner name do not follow the RRset rules 583 described in [RFC2181]." 585 Master file: "Master files are text files that contain RRs in text 586 form. Since the contents of a zone can be expressed in the form 587 of a list of RRs a master file is most often used to define a 588 zone, though it can be used to list a cache's contents." 589 ([RFC1035], Section 5.) Master files are sometimes called "zone 590 files". 592 Presentation format: The text format used in master files. This 593 format is shown but not formally defined in [RFC1034] and 594 [RFC1035]. The term "presentation format" first appears in 595 [RFC4034]. 597 EDNS: The extension mechanisms for DNS, defined in [RFC6891]. 598 Sometimes called "EDNS0" or "EDNS(0)" to indicate the version 599 number. EDNS allows DNS clients and servers to specify message 600 sizes larger than the original 512 octet limit, to expand the 601 response code space, and potentially to carry additional options 602 that affect the handling of a DNS query. 604 OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to 605 contain control information pertaining to the question-and-answer 606 sequence of a specific transaction. (Definition from [RFC6891], 607 Section 6.1.1) It is used by EDNS. 609 Owner: The domain name where a RR is found ([RFC1034], Section 3.6). 610 Often appears in the term "owner name". 612 SOA field names: DNS documents, including the definitions here, 613 often refer to the fields in the RDATA of an SOA resource record 614 by field name. Those fields are defined in Section 3.3.13 of 615 [RFC1035]. The names (in the order they appear in the SOA RDATA) 616 are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. 617 Note that the meaning of MINIMUM field is updated in Section 4 of 618 [RFC2308]; the new definition is that the MINIMUM field is only 619 "the TTL to be used for negative responses". This document tends 620 to use field names instead of terms that describe the fields. 622 TTL: The maximum "time to live" of a resource record. "A TTL value 623 is an unsigned number, with a minimum value of 0, and a maximum 624 value of 2147483647. That is, a maximum of 2^31 - 1. When 625 transmitted, the TTL is encoded in the less significant 31 bits of 626 the 32 bit TTL field, with the most significant, or sign, bit set 627 to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035] 628 erroneously stated that this is a signed integer; that was fixed 629 by [RFC2181].) 631 The TTL "specifies the time interval that the resource record may 632 be cached before the source of the information should again be 633 consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the 634 time interval (in seconds) that the resource record may be cached 635 before it should be discarded". (Quoted from [RFC1035], 636 Section 4.1.3). Despite being defined for a resource record, the 637 TTL of every resource record in an RRset is required to be the 638 same ([RFC2181], Section 5.2). 640 The reason that the TTL is the maximum time to live is that a 641 cache operator might decide to shorten the time to live for 642 operational purposes, such as if there is a policy to disallow TTL 643 values over a certain number. Some servers are known to ignore 644 the TTL on some RRsets (such as when the authoritative data has a 645 very short TTL) even though this is against the advice in RFC 646 1035. An RRset can be flushed from the cache before the end of 647 the TTL interval, at which point the value of the TTL becomes 648 unknown because the RRset with which it was associated no longer 649 exists. 651 There is also the concept of a "default TTL" for a zone, which can 652 be a configuration parameter in the server software. This is 653 often expressed by a default for the entire server, and a default 654 for a zone using the $TTL directive in a zone file. The $TTL 655 directive was added to the master file format by [RFC2308]. 657 Class independent: A resource record type whose syntax and semantics 658 are the same for every DNS class. A resource record type that is 659 not class independent has different meanings depending on the DNS 660 class of the record, or the meaning is undefined for some class. 661 Most resorece record types are defined for class 1 (IN, the 662 Internet), but many are undefined for other classes. 664 Address records: Records whose type is A or AAAA. [RFC2181] 665 informally defines these as "(A, AAAA, etc)". Note that new types 666 of address records could be defined in the future. 668 6. DNS Servers and Clients 670 This section defines the terms used for the systems that act as DNS 671 clients, DNS servers, or both. In the RFCs, DNS servers are 672 sometimes called "name servers", "nameservers", or just "servers". 673 There is no formal definition of DNS server, but the RFCs generally 674 assume that it is an Internet server that listens for queries and 675 sends responses using the DNS protocol defined in [RFC1035] and its 676 successors. 678 It is important to note that the terms "DNS server" and "name server" 679 require context in order to understand the services being provided. 680 Both authoritative servers and recursive resolvers are often called 681 "DNS servers" and "name servers" even though they serve different 682 roles (but may be part of the same software package). 684 For terminology specific to the public DNS root server system, see 685 [RSSAC026]. That document defines terms such as "root server", "root 686 server operator", and terms that are specific to the way that the 687 root zone of the public DNS is served. 689 Resolver: A program "that extract[s] information from name servers 690 in response to client requests." (Quoted from [RFC1034], 691 Section 2.4) A resolver performs queries for a name, type, and 692 class, and receives answers. The logical function is called 693 "resolution". In practice, the term is usually referring to some 694 specific type of resolver (some of which are defined below), and 695 understanding the use of the term depends on understanding the 696 context. 698 A related term is "resolve", which is not formally defined in 699 [RFC1034] or [RFC1035]. An imputed definition might be "asking a 700 question that consists of a domain name, class, and type, and 701 receiving some sort of answer". Similarly, an imputed definition 702 of "resolution" might be "the answer received from resolving". 704 Stub resolver: A resolver that cannot perform all resolution itself. 705 Stub resolvers generally depend on a recursive resolver to 706 undertake the actual resolution function. Stub resolvers are 707 discussed but never fully defined in Section 5.3.1 of [RFC1034]. 708 They are fully defined in Section 6.1.3.1 of [RFC1123]. 710 Iterative mode: A resolution mode of a server that receives DNS 711 queries and responds with a referral to another server. 712 Section 2.3 of [RFC1034] describes this as "The server refers the 713 client to another server and lets the client pursue the query". A 714 resolver that works in iterative mode is sometimes called an 715 "iterative resolver". See also "iterative resolution" later in 716 this section. 718 Recursive mode: A resolution mode of a server that receives DNS 719 queries and either responds to those queries from a local cache or 720 sends queries to other servers in order to get the final answers 721 to the original queries. Section 2.3 of [RFC1034] describes this 722 as "The first server pursues the query for the client at another 723 server". Section 4.3.1 of of [RFC1034] says "in [recursive] mode 724 the name server acts in the role of a resolver and returns either 725 an error or the answer, but never referrals." That same section 726 also says "The recursive mode occurs when a query with RD set 727 arrives at a server which is willing to provide recursive service; 728 the client can verify that recursive mode was used by checking 729 that both RA and RD are set in the reply." 731 A server operating in recursive mode may be thought of as having a 732 name server side (which is what answers the query) and a resolver 733 side (which performs the resolution function). Systems operating 734 in this mode are commonly called "recursive servers". Sometimes 735 they are called "recursive resolvers". While strictly the 736 difference between these is that one of them sends queries to 737 another recursive server and the other does not, in practice it is 738 not possible to know in advance whether the server that one is 739 querying will also perform recursion; both terms can be observed 740 in use interchangeably. 742 Recursive resolver: A resolver that acts in recursive mode. In 743 general, a recursive resolver is expected to cache the answers it 744 receives (which would make it a full-service resolver), but some 745 recursive resolvers might not cache. 747 [RFC4697] tried to differentiate between a recursive resolver and 748 an iterative resolver. 750 Recursive query: A query with the Recursion Desired (RD) bit set to 751 1 in the header. (See Section 4.1.1 of [RFC1035].) If recursive 752 service is available and is requested by the RD bit in the query, 753 the server uses its resolver to answer the query. (See 754 Section 4.3.2 of [RFC1035].) 756 Non-recursive query: A query with the Recursion Desired (RD) bit set 757 to 0 in the header. A server can answer non-recursive queries 758 using only local information: the response contains either an 759 error, the answer, or a referral to some other server "closer" to 760 the answer. (See Section 4.3.1 of [RFC1035].) 762 Iterative resolution: A name server may be presented with a query 763 that can only be answered by some other server. The two general 764 approaches to dealing with this problem are "recursive", in which 765 the first server pursues the query on behalf of the client at 766 another server, and "iterative", in which the server refers the 767 client to another server and lets the client pursue the query 768 there. (See Section 2.3 of [RFC1034].) 769 In iterative resolution, the client repeatedly makes non-recursive 770 queries and follows referrals and/or aliases. The iterative 771 resolution algorithm is described in Section 5.3.3 of [RFC1034]. 773 Full resolver: This term is used in [RFC1035], but it is not defined 774 there. RFC 1123 defines a "full-service resolver" that may or may 775 not be what was intended by "full resolver" in [RFC1035]. This 776 term is not properly defined in any RFC. 778 Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this 779 term to mean a resolver that acts in recursive mode with a cache 780 (and meets other requirements). 782 Priming: "The act of finding the list of root servers from a 783 configuration that lists some or all of the purported IP addresses 784 of some or all of those root servers." (Quoted from [RFC8109], 785 Section 2.) In order to operate in recursive mode, a resolver 786 needs to know the address of at least one root server. Priming is 787 most often done from a configuration setting that contains a list 788 of authoritative servers for the root zone. 790 Root hints: "Operators who manage a DNS recursive resolver typically 791 need to configure a 'root hints file'. This file contains the 792 names and IP addresses of the authoritative name servers for the 793 root zone, so the software can bootstrap the DNS resolution 794 process. For many pieces of software, this list comes built into 795 the software." (Quoted from [IANA_RootFiles]) This file is often 796 used in priming. 798 Negative caching: "The storage of knowledge that something does not 799 exist, cannot give an answer, or does not give an answer." 800 (Quoted from [RFC2308], Section 1) 802 Authoritative server: "A server that knows the content of a DNS zone 803 from local knowledge, and thus can answer queries about that zone 804 without needing to query other servers." (Quoted from [RFC2182], 805 Section 2.) It is a system that responds to DNS queries with 806 information about zones for which it has been configured to answer 807 with the AA flag in the response header set to 1. It is a server 808 that has authority over one or more DNS zones. Note that it is 809 possible for an authoritative server to respond to a query without 810 the parent zone delegating authority to that server. 811 Authoritative servers also provide "referrals", usually to child 812 zones delegated from them; these referrals have the AA bit set to 813 0 and come with referral data in the Authority and (if needed) the 814 Additional sections. 816 Authoritative-only server: A name server that only serves 817 authoritative data and ignores requests for recursion. It will 818 "not normally generate any queries of its own. Instead, it 819 answers non-recursive queries from iterative resolvers looking for 820 information in zones it serves." (Quoted from [RFC4697], 821 Section 2.4) In this case, "ignores requests for recursion" means 822 "responds to requests for recursion with responses indicating that 823 recursion was not performed". 825 Zone transfer: The act of a client requesting a copy of a zone and 826 an authoritative server sending the needed information. (See 827 Section 7 for a description of zones.) There are two common 828 standard ways to do zone transfers: the AXFR ("Authoritative 829 Transfer") mechanism to copy the full zone (described in 830 [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy 831 only parts of the zone that have changed (described in [RFC1995]). 832 Many systems use non-standard methods for zone transfer outside 833 the DNS protocol. 835 Secondary server: "An authoritative server which uses zone transfer 836 to retrieve the zone" (Quoted from [RFC1996], Section 2.1). 837 Secondary servers are also discussed in [RFC1034]. [RFC2182] 838 describes secondary servers in more detail. Although early DNS 839 RFCs such as [RFC1996] referred to this as a "slave", the current 840 common usage has shifted to calling it a "secondary". 842 Slave server: See secondary server. 844 Primary server: "Any authoritative server configured to be the 845 source of zone transfer for one or more [secondary] servers" 846 (Quoted from [RFC1996], Section 2.1) or, more specifically, "an 847 authoritative server configured to be the source of AXFR or IXFR 848 data for one or more [secondary] servers" (Quoted from [RFC2136]). 849 Primary servers are also discussed in [RFC1034]. Although early 850 DNS RFCs such as [RFC1996] referred to this as a "master", the 851 current common usage has shifted to "primary". 853 Master server: See primary server. 855 Primary master: "The primary master is named in the zone's SOA MNAME 856 field and optionally by an NS RR". (Quoted from [RFC1996], 857 Section 2.1). [RFC2136] defines "primary master" as "Master 858 server at the root of the AXFR/IXFR dependency graph. The primary 859 master is named in the zone's SOA MNAME field and optionally by an 860 NS RR. There is by definition only one primary master server per 861 zone." The idea of a primary master is only used by [RFC2136], 862 and is considered archaic in other parts of the DNS. 864 The idea of a primary master is only used in [RFC1996] and 865 [RFC2136]. A modern interpretation of the term "primary master" 866 is a server that is both authoritative for a zone and that gets 867 its updates to the zone from configuration (such as a master file) 868 or from UPDATE transactions. 870 Stealth server: This is "like a slave server except not listed in an 871 NS RR for the zone." (Quoted from [RFC1996], Section 2.1) 873 Hidden master: A stealth server that is a primary server for zone 874 transfers. "In this arrangement, the master name server that 875 processes the updates is unavailable to general hosts on the 876 Internet; it is not listed in the NS RRset." (Quoted from 877 [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that 878 the hidden master's name "appears in the SOA RRs MNAME field", 879 although in some setups, the name does not appear at all in the 880 public DNS. A hidden master can also be a secondary server for 881 the zone itself. 883 Forwarding: The process of one server sending a DNS query with the 884 RD bit set to 1 to another server to resolve that query. 885 Forwarding is a function of a DNS resolver; it is different than 886 simply blindly relaying queries. 888 [RFC5625] does not give a specific definition for forwarding, but 889 describes in detail what features a system that forwards needs to 890 support. Systems that forward are sometimes called "DNS proxies", 891 but that term has not yet been defined (even in [RFC5625]). 893 Forwarder: Section 1 of [RFC2308] describes a forwarder as "a 894 nameserver used to resolve queries instead of directly using the 895 authoritative nameserver chain". [RFC2308] further says "The 896 forwarder typically either has better access to the internet, or 897 maintains a bigger cache which may be shared amongst many 898 resolvers." That definition appears to suggest that forwarders 899 normally only query authoritative servers. In current use, 900 however, forwarders often stand between stub resolvers and 901 recursive servers. [RFC2308] is silent on whether a forwarder is 902 iterative-only or can be a full-service resolver. 904 Policy-implementing resolver: A resolver acting in recursive mode 905 that changes some of the answers that it returns based on policy 906 criteria, such as to prevent access to malware sites or 907 objectionable content. In general, a stub resolver has no idea 908 whether upstream resolvers implement such policy or, if they do, 909 the exact policy about what changes will be made. In some cases, 910 the user of the stub resolver has selected the policy-implementing 911 resolver with the explicit intention of using it to implement the 912 policies. In other cases, policies are imposed without the user 913 of the stub resolver being informed. 915 Open resolver: A full-service resolver that accepts and processes 916 queries from any (or nearly any) client. This is sometimes also 917 called a "public resolver", although the term "public resolver" is 918 used more with open resolvers that are meant to be open, as 919 compared to the vast majority of open resolvers that are probably 920 misconfigured to be open. Open resolvers are discussed in 921 [RFC5358] 923 Split DNS: The terms "split DNS" and "split-horizon DNS" have long 924 been used in the DNS community without formal definition. In 925 general, they refer to situations in which DNS servers that are 926 authoritative for a particular set of domains provide partly or 927 completely different answers in those domains depending on the 928 source of the query. The effect of this is that a domain name 929 that is notionally globally unique nevertheless has different 930 meanings for different network users. This can sometimes be the 931 result of a "view" configuration, described below. 933 [RFC2775], Section 3.8 gives a related definition that is too 934 specific to be generally useful. 936 View: A configuration for a DNS server that allows it to provide 937 different answers depending on attributes of the query, such as 938 for "split DNS". Typically, views differ by the source IP address 939 of a query, but can also be based on the destination IP address, 940 the type of query (such as AXFR), whether it is recursive, and so 941 on. Views are often used to provide more names or different 942 addresses to queries from "inside" a protected network than to 943 those "outside" that network. Views are not a standardized part 944 of the DNS, but they are widely implemented in server software. 946 Passive DNS: A mechanism to collect DNS data by storing DNS 947 responses from name servers. Some of these systems also collect 948 the DNS queries associated with the responses, although doing so 949 raises some privacy concerns. Passive DNS databases can be used 950 to answer historical questions about DNS zones such as which 951 values were present at a given time in the past, or when a name 952 was spotted first. Passive DNS databases allow searching of the 953 stored records on keys other than just the name and type, such as 954 "find all names which have A records of a particular value". 956 Anycast: "The practice of making a particular service address 957 available in multiple, discrete, autonomous locations, such that 958 datagrams sent are routed to one of several available locations." 959 (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail 960 on Anycast and other terms that are specific to its use. 962 Instance: "When anycast routing is used to allow more than one 963 server to have the same IP address, each one of those servers is 964 commonly referred to as an 'instance'." "An instance of a server, 965 such as a root server, is often referred to as an 'Anycast 966 instance'." (Quoted from [RSSAC026]) 968 Privacy-enabling DNS server: "A DNS server that implements DNS over 969 TLS [RFC7858] and may optionally implement DNS over DTLS 970 [RFC8094]." (Quoted from [RFC8310], Section 2) 972 7. Zones 974 This section defines terms that are used when discussing zones that 975 are being served or retrieved. 977 Zone: "Authoritative information is organized into units called 978 'zones', and these zones can be automatically distributed to the 979 name servers which provide redundant service for the data in a 980 zone." (Quoted from [RFC1034], Section 2.4) 982 Child: "The entity on record that has the delegation of the domain 983 from the Parent." (Quoted from [RFC7344], Section 1.1) 985 Parent: "The domain in which the Child is registered." (Quoted from 986 [RFC7344], Section 1.1) Earlier, "parent name server" was defined 987 in [RFC0882] as "the name server that has authority over the place 988 in the domain name space that will hold the new domain". (Note 989 that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].) 990 [RFC0819] also has some description of the relationship between 991 parents and children. 993 Origin: 995 (a) "The domain name that appears at the top of a zone (just below 996 the cut that separates the zone from its parent). The name of the 997 zone is the same as the name of the domain at the zone's origin." 998 (Quoted from [RFC2181], Section 6.) These days, this sense of 999 "origin" and "apex" (defined below) are often used 1000 interchangeably. 1002 (b) The domain name within which a given relative domain name 1003 appears in zone files. Generally seen in the context of 1004 "$ORIGIN", which is a control entry defined in [RFC1035], 1005 Section 5.1, as part of the master file format. For example, if 1006 the $ORIGIN is set to "example.org.", then a master file line for 1007 "www" is in fact an entry for "www.example.org.". 1009 Apex: The point in the tree at an owner of an SOA and corresponding 1010 authoritative NS RRset. This is also called the "zone apex". 1011 [RFC4033] defines it as "the name at the child's side of a zone 1012 cut". The "apex" can usefully be thought of as a data-theoretic 1013 description of a tree structure, and "origin" is the name of the 1014 same concept when it is implemented in zone files. The 1015 distinction is not always maintained in use, however, and one can 1016 find uses that conflict subtly with this definition. [RFC1034] 1017 uses the term "top node of the zone" as a synonym of "apex", but 1018 that term is not widely used. These days, the first sense of 1019 "origin" (above) and "apex" are often used interchangeably. 1021 Zone cut: The delimitation point between two zones where the origin 1022 of one of the zones is the child of the other zone. 1024 "Zones are delimited by 'zone cuts'. Each zone cut separates a 1025 'child' zone (below the cut) from a 'parent' zone (above the 1026 cut)." (Quoted from [RFC2181], Section 6; note that this is 1027 barely an ostensive definition.) Section 4.2 of [RFC1034] uses 1028 "cuts" instead of "zone cut". 1030 Delegation: The process by which a separate zone is created in the 1031 name space beneath the apex of a given domain. Delegation happens 1032 when an NS RRset is added in the parent zone for the child origin. 1033 Delegation inherently happens at a zone cut. The term is also 1034 commonly a noun: the new zone that is created by the act of 1035 delegating. 1037 Authoritative data: "All of the RRs attached to all of the nodes 1038 from the top node of the zone down to leaf nodes or nodes above 1039 cuts around the bottom edge of the zone." (Quoted from [RFC1034], 1040 Section 4.2.1) Note that this definition might inadvertently also 1041 cause any NS records that appear in the zone to be included, even 1042 those that might not truly be authoritative because there are 1043 identical NS RRs below the zone cut. This reveals the ambiguity 1044 in the notion of authoritative data, because the parent-side NS 1045 records authoritatively indicate the delegation, even though they 1046 are not themselves authoritative data. 1048 [RFC4033], Section 2, defines "Authoritative RRset" which is 1049 related to authoritative data but has a more precise definition. 1051 Lame delegation: "A lame delegations exists when a nameserver is 1052 delegated responsibility for providing nameservice for a zone (via 1053 NS records) but is not performing nameservice for that zone 1054 (usually because it is not set up as a primary or secondary for 1055 the zone)." (Quoted from [RFC1912], Section 2.8) 1057 Another definition is that a lame delegation "happens when a name 1058 server is listed in the NS records for some domain and in fact it 1059 is not a server for that domain. Queries are thus sent to the 1060 wrong servers, who don't know nothing (at least not as expected) 1061 about the queried domain. Furthermore, sometimes these hosts (if 1062 they exist!) don't even run name servers." (Quoted from 1063 [RFC1713], Section 2.3) 1065 Glue records: "[Resource records] which are not part of the 1066 authoritative data [of the zone], and are address resource records 1067 for the [name servers in subzones]. These RRs are only necessary 1068 if the name server's name is 'below' the cut, and are only used as 1069 part of a referral response." Without glue "we could be faced 1070 with the situation where the NS RRs tell us that in order to learn 1071 a name server's address, we should contact the server using the 1072 address we wish to learn." (Definition from [RFC1034], 1073 Section 4.2.1) 1075 A later definition is that glue "includes any record in a zone 1076 file that is not properly part of that zone, including nameserver 1077 records of delegated sub-zones (NS records), address records that 1078 accompany those NS records (A, AAAA, etc), and any other stray 1079 data that might appear" ([RFC2181], Section 5.4.1). Although glue 1080 is sometimes used today with this wider definition in mind, the 1081 context surrounding the [RFC2181] definition suggests it is 1082 intended to apply to the use of glue within the document itself 1083 and not necessarily beyond. 1085 Bailiwick: "In-bailiwick" is an adjective to describe a name server 1086 whose name is either a subdomain of or (rarely) the same as the 1087 origin of the zone that contains the delegation to the name 1088 server. In-bailiwick name servers may have glue records in their 1089 parent zone (using the first of the definitions of "glue records" 1090 in the definition above). (The term "bailiwick" means the 1091 district or territory where a bailiff or policeman has 1092 jurisdiction.) 1094 "In-bailiwick" names are divided into two type of name server 1095 names: "in-domain" names and "sibling domain" names. 1097 * In-domain: an adjective to describe a name server whose name is 1098 either subordinate to or (rarely) the same as the owner name of 1099 the NS resource records. An in-domain name server name MUST 1100 have glue records or name resolution fails. For example, a 1101 delegation for "child.example.com" may have "in-domain" name 1102 server name "ns.child.example.com". 1104 * Sibling domain: a name server's name that is either subordinate 1105 to or (rarely) the same as the zone origin and not subordinate 1106 to or the same as the owner name of the NS resource records. 1107 Glue records for sibling domains are allowed, but not 1108 necessary. For example, a delegation for "child.example.com" 1109 in "example.com" zone may have "sibling" name server name 1110 "ns.another.example.com". 1112 "Out-of-bailiwick" is the antonym of in-bailiwick. An adjective 1113 to describe a name server whose name is not subordinate to or the 1114 same as the zone origin. Glue records for out-of-bailiwick name 1115 servers are useless. Following table shows examples of delegation 1116 types. 1118 Delegation |Parent|Name Server Name | Type 1119 -----------+------+------------------+----------------------------- 1120 com | . |a.gtld-servers.net|in-bailiwick / sibling domain 1121 net | . |a.gtld-servers.net|in-bailiwick / in-domain 1122 example.org| org |ns.example.org |in-bailiwick / in-domain 1123 example.org| org |ns.ietf.org |in-bailiwick / sibling domain 1124 example.org| org |ns.example.com |out-of-bailiwick 1125 example.jp | jp |ns.example.jp |in-bailiwick / in-domain 1126 example.jp | jp |ns.example.ne.jp |in-bailiwick / sibling domain 1127 example.jp | jp |ns.example.com |out-of-bailiwick 1129 Root zone: The zone of a DNS-based tree whose apex is the zero- 1130 length label. Also sometimes called "the DNS root". 1132 Empty non-terminals (ENT): "Domain names that own no resource 1133 records but have subdomains that do." (Quoted from [RFC4592], 1134 Section 2.2.2.) A typical example is in SRV records: in the name 1135 "_sip._tcp.example.com", it is likely that "_tcp.example.com" has 1136 no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV 1137 RRset. 1139 Delegation-centric zone: A zone that consists mostly of delegations 1140 to child zones. This term is used in contrast to a zone that 1141 might have some delegations to child zones, but also has many data 1142 resource records for the zone itself and/or for child zones. The 1143 term is used in [RFC4956] and [RFC5155], but is not defined there. 1145 Occluded name: "The addition of a delegation point via dynamic 1146 update will render all subordinate domain names to be in a limbo, 1147 still part of the zone, but not available to the lookup process. 1148 The addition of a DNAME resource record has the same impact. The 1149 subordinate names are said to be 'occluded'." (Quoted from 1150 [RFC5936], Section 3.5) 1152 Fast flux DNS: This "occurs when a domain is found in DNS using A 1153 records to multiple IP addresses, each of which has a very short 1154 Time-to-Live (TTL) value associated with it. This means that the 1155 domain resolves to varying IP addresses over a short period of 1156 time." (Quoted from [RFC6561], Section 1.1.5, with typo 1157 corrected) In addition to having legitimate uses, fast flux DNS 1158 can used to deliver malware. Because the addresses change so 1159 rapidly, it is difficult to ascertain all the hosts. It should be 1160 noted that the technique also works with AAAA records, but such 1161 use is not frequently observed on the Internet as of this writing. 1163 Reverse DNS, reverse lookup: "The process of mapping an address to a 1164 name is generally known as a 'reverse lookup', and the IN- 1165 ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse 1166 DNS'." (Quoted from [RFC5855], Section 1) 1168 Forward lookup: "Hostname-to-address translation". (Quoted from 1169 [RFC2133], Section 6) 1171 arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain 1172 was originally established as part of the initial deployment of 1173 the DNS, to provide a transition mechanism from the Host Tables 1174 that were common in the ARPANET, as well as a home for the IPv4 1175 reverse mapping domain. During 2000, the abbreviation was 1176 redesignated to 'Address and Routing Parameter Area' in the hope 1177 of reducing confusion with the earlier network name." (Quoted 1178 from [RFC3172], Section 2.) .arpa is an "infrastructure domain", a 1179 domain whose "role is to support the operating infrastructure of 1180 the Internet". (Quoted from [RFC3172], Section 2.) See [RFC3172] 1181 for more history of this name. 1183 Service name: "Service names are the unique key in the Service Name 1184 and Transport Protocol Port Number registry. This unique symbolic 1185 name for a service may also be used for other purposes, such as in 1186 DNS SRV records." (Quoted from [RFC6335], Section 5.) 1188 8. Wildcards 1190 Wildcard: [RFC1034] defined "wildcard", but in a way that turned out 1191 to be confusing to implementers. For an extended discussion of 1192 wildcards, including clearer definitions, see [RFC4592]. Special 1193 treatment is given to RRs with owner names starting with the label 1194 "*". "Such RRs are called 'wildcards'. Wildcard RRs can be 1195 thought of as instructions for synthesizing RRs." (Quoted from 1196 [RFC1034], Section 4.3.3) 1198 Asterisk label: "The first octet is the normal label type and length 1199 for a 1-octet-long label, and the second octet is the ASCII 1200 representation for the '*' character. A descriptive name of a 1201 label equaling that value is an 'asterisk label'." (Quoted from 1202 [RFC4592], Section 2.1.1) 1204 Wildcard domain name: "A 'wildcard domain name' is defined by having 1205 its initial (i.e., leftmost or least significant) label be 1206 asterisk label." (Quoted from [RFC4592], Section 2.1.1) 1208 Closest encloser: "The longest existing ancestor of a name." 1209 (Quoted from [RFC5155], Section 1.3) An earlier definition is "The 1210 node in the zone's tree of existing domain names that has the most 1211 labels matching the query name (consecutively, counting from the 1212 root label downward). Each match is a 'label match' and the order 1213 of the labels is the same." (Quoted from [RFC4592], 1214 Section 3.3.1) 1216 Closest provable encloser: "The longest ancestor of a name that can 1217 be proven to exist. Note that this is only different from the 1218 closest encloser in an Opt-Out zone." (Quoted from [RFC5155], 1219 Section 1.3) 1221 Next closer name: "The name one label longer than the closest 1222 provable encloser of a name." (Quoted from [RFC5155], 1223 Section 1.3) 1225 Source of Synthesis: "The source of synthesis is defined in the 1226 context of a query process as that wildcard domain name 1227 immediately descending from the closest encloser, provided that 1228 this wildcard domain name exists. 'Immediately descending' means 1229 that the source of synthesis has a name of the form: .." (Quoted from [RFC4592], 1231 Section 3.3.1) 1233 9. Registration Model 1235 Registry: The administrative operation of a zone that allows 1236 registration of names within that zone. People often use this 1237 term to refer only to those organizations that perform 1238 registration in large delegation-centric zones (such as TLDs); but 1239 formally, whoever decides what data goes into a zone is the 1240 registry for that zone. This definition of "registry" is from a 1241 DNS point of view; for some zones, the policies that determine 1242 what can go in the zone are decided by superior zones and not the 1243 registry operator. 1245 Registrant: An individual or organization on whose behalf a name in 1246 a zone is registered by the registry. In many zones, the registry 1247 and the registrant may be the same entity, but in TLDs they often 1248 are not. 1250 Registrar: A service provider that acts as a go-between for 1251 registrants and registries. Not all registrations require a 1252 registrar, though it is common to have registrars involved in 1253 registrations in TLDs. 1255 EPP: The Extensible Provisioning Protocol (EPP), which is commonly 1256 used for communication of registration information between 1257 registries and registrars. EPP is defined in [RFC5730]. 1259 WHOIS: A protocol specified in [RFC3912], often used for querying 1260 registry databases. WHOIS data is frequently used to associate 1261 registration data (such as zone management contacts) with domain 1262 names. The term "WHOIS data" is often used as a synonym for the 1263 registry database, even though that database may be served by 1264 different protocols, particularly RDAP. The WHOIS protocol is 1265 also used with IP address registry data. 1267 RDAP: The Registration Data Access Protocol, defined in [RFC7480], 1268 [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The 1269 RDAP protocol and data format are meant as a replacement for 1270 WHOIS. 1272 DNS operator: An entity responsible for running DNS servers. For a 1273 zone's authoritative servers, the registrant may act as their own 1274 DNS operator, or their registrar may do it on their behalf, or 1275 they may use a third-party operator. For some zones, the registry 1276 function is performed by the DNS operator plus other entities who 1277 decide about the allowed contents of the zone. 1279 Public suffix: "A domain that is controlled by a public registry." 1280 (Quoted from [RFC6265], Section 5.3) A common definition for this 1281 term is a domain under which subdomains can be registered by third 1282 parties, and on which HTTP cookies (which are described in detail 1283 in [RFC6265]) should not be set. There is no indication in a 1284 domain name whether it is a public suffix; that can only be 1285 determined by outside means. In fact, both a domain and a 1286 subdomain of that domain can be public suffixes. 1288 There is nothing inherent in a domain name to indicate whether it 1289 is a public suffix. One resource for identifying public suffixes 1290 is the Public Suffix List (PSL) maintained by Mozilla 1291 (http://publicsuffix.org/). 1293 For example, at the time this document is published, the "com.au" 1294 domain is listed as a public suffix in the PSL. (Note that this 1295 example might change in the future.) 1297 Note that the term "public suffix" is controversial in the DNS 1298 community for many reasons, and may be significantly changed in 1299 the future. One example of the difficulty of calling a domain a 1300 public suffix is that designation can change over time as the 1301 registration policy for the zone changes, such as was the case 1302 with the "uk" TLD in 2014. 1304 Subordinate and Superordinate: These terms are introduced in 1305 [RFC3731] for use in the registration model, but not defined 1306 there. Instead, they are given in examples. "For example, domain 1307 name 'example.com' has a superordinate relationship to host name 1308 ns1.example.com'." "For example, host ns1.example1.com is a 1309 subordinate host of domain example1.com, but it is a not a 1310 subordinate host of domain example2.com." (Quoted from [RFC3731], 1311 Section 1.1.) These terms are strictly ways of referring to the 1312 relationship standing of two domains where one is a subdomain of 1313 the other. 1315 10. General DNSSEC 1317 Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and 1318 [RFC5155]. The terms that have caused confusion in the DNS community 1319 are highlighted here. 1321 DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in 1322 some RFCs, have not been formally defined. However, Section 2 of 1323 [RFC4033] defines many types of resolvers and validators, 1324 including "non-validating security-aware stub resolver", "non- 1325 validating stub resolver", "security-aware name server", 1326 "security-aware recursive name server", "security-aware resolver", 1327 "security-aware stub resolver", and "security-oblivious 1328 'anything'". (Note that the term "validating resolver", which is 1329 used in some places in DNSSEC-related documents, is also not 1330 defined in those RFCs, but is defined below.) 1332 Signed zone: "A zone whose RRsets are signed and that contains 1333 properly constructed DNSKEY, Resource Record Signature (RRSIG), 1334 Next Secure (NSEC), and (optionally) DS records." (Quoted from 1335 [RFC4033], Section 2.) It has been noted in other contexts that 1336 the zone itself is not really signed, but all the relevant RRsets 1337 in the zone are signed. Nevertheless, if a zone that should be 1338 signed contains any RRsets that are not signed (or opted out), 1339 those RRsets will be treated as bogus, so the whole zone needs to 1340 be handled in some way. 1342 It should also be noted that, since the publication of [RFC6840], 1343 NSEC records are no longer required for signed zones: a signed 1344 zone might include NSEC3 records instead. [RFC7129] provides 1345 additional background commentary and some context for the NSEC and 1346 NSEC3 mechanisms used by DNSSEC to provide authenticated denial- 1347 of-existence responses. NSEC and NSEC3 are described below. 1349 Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that 1350 is not signed". Section 2 of [RFC4035] defines this as "A zone 1351 that does not include these records [properly constructed DNSKEY, 1352 Resource Record Signature (RRSIG), Next Secure (NSEC), and 1353 (optionally) DS records] according to the rules in this section". 1354 There is an important note at the end of Section 5.2 of [RFC4035] 1355 that defines an additional situation in which a zone is considered 1356 unsigned: "If the resolver does not support any of the algorithms 1357 listed in an authenticated DS RRset, then the resolver will not be 1358 able to verify the authentication path to the child zone. In this 1359 case, the resolver SHOULD treat the child zone as if it were 1360 unsigned." 1362 NSEC: "The NSEC record allows a security-aware resolver to 1363 authenticate a negative reply for either name or type non- 1364 existence with the same mechanisms used to authenticate other DNS 1365 replies." (Quoted from [RFC4033], Section 3.2.) In short, an 1366 NSEC record provides authenticated denial of existence. 1368 "The NSEC resource record lists two separate things: the next 1369 owner name (in the canonical ordering of the zone) that contains 1370 authoritative data or a delegation point NS RRset, and the set of 1371 RR types present at the NSEC RR's owner name." (Quoted from 1372 Section 4 of RFC 4034) 1374 NSEC3: Like the NSEC record, the NSEC3 record also provides 1375 authenticated denial of existence; however, NSEC3 records mitigate 1376 against zone enumeration and support Opt-Out. NSEC3 resource 1377 records require associated NSEC3PARAM resource records. NSEC3 and 1378 NSEC3PARAM resource records are defined in [RFC5155]. 1380 Note that [RFC6840] says that [RFC5155] "is now considered part of 1381 the DNS Security Document Family as described by Section 10 of 1382 [RFC4033]". This means that some of the definitions from earlier 1383 RFCs that only talk about NSEC records should probably be 1384 considered to be talking about both NSEC and NSEC3. 1386 Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover 1387 unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.) 1388 Opt-out tackles the high costs of securing a delegation to an 1389 insecure zone. When using Opt-Out, names that are an insecure 1390 delegation (and empty non-terminals that are only derived from 1391 insecure delegations) don't require an NSEC3 record or its 1392 corresponding RRSIG records. Opt-Out NSEC3 records are not able 1393 to prove or deny the existence of the insecure delegations. 1394 (Adapted from [RFC7129], Section 5.1) 1396 Insecure delegation: "A signed name containing a delegation (NS 1397 RRset), but lacking a DS RRset, signifying a delegation to an 1398 unsigned subzone." (Quoted from [RFC4956], Section 2.) 1400 Zone enumeration: "The practice of discovering the full content of a 1401 zone via successive queries." (Quoted from [RFC5155], 1402 Section 1.3.) This is also sometimes called "zone walking". Zone 1403 enumeration is different from zone content guessing where the 1404 guesser uses a large dictionary of possible labels and sends 1405 successive queries for them, or matches the contents of NSEC3 1406 records against such a dictionary. 1408 Validation: Validation, in the context of DNSSEC, refers to one of 1409 the following: 1411 * Checking the validity of DNSSEC signatures 1413 * Checking the validity of DNS responses, such as those including 1414 authenticated denial of existence 1416 * Building an authentication chain from a trust anchor to a DNS 1417 response or individual DNS RRsets in a response 1419 The first two definitions above consider only the validity of 1420 individual DNSSEC components such as the RRSIG validity or NSEC 1421 proof validity. The third definition considers the components of 1422 the entire DNSSEC authentication chain, and thus requires 1423 "configured knowledge of at least one authenticated DNSKEY or DS 1424 RR" (as described in [RFC4035], Section 5). 1426 [RFC4033], Section 2, says that a "Validating Security-Aware Stub 1427 Resolver... performs signature validation" and uses a trust anchor 1428 "as a starting point for building the authentication chain to a 1429 signed DNS response", and thus uses the first and third 1430 definitions above. The process of validating an RRSIG resource 1431 record is described in [RFC4035], Section 5.3. 1433 [RFC5155] refers to validating responses throughout the document, 1434 in the context of hashed authenticated denial of existence; this 1435 uses the second definition above. 1437 The term "authentication" is used interchangeably with 1438 "validation", in the sense of the third definition above. 1439 [RFC4033], Section 2, describes the chain linking trust anchor to 1440 DNS data as the "authentication chain". A response is considered 1441 to be authentic if "all RRsets in the Answer and Authority 1442 sections of the response [are considered] to be authentic" 1443 ([RFC4035]). DNS data or responses deemed to be authentic or 1444 validated have a security status of "secure" ([RFC4035], 1445 Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys 1446 and data is a matter of local policy, which may extend or even 1447 override the [DNSSEC] protocol extensions" ([RFC4033], 1448 Section 3.1). 1450 The term "verification", when used, is usually synonym for 1451 "validation". 1453 Validating resolver: A security-aware recursive name server, 1454 security-aware resolver, or security-aware stub resolver that is 1455 applying at least one of the definitions of validation (above), as 1456 appropriate to the resolution context. For the same reason that 1457 the generic term "resolver" is sometimes ambiguous and needs to be 1458 evaluated in context (see Section 6), "validating resolver" is a 1459 context-sensitive term. 1461 Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY 1462 RRset in a zone."(Quoted from [RFC6781], Section 3.1) 1464 Zone signing key (ZSK): "DNSSEC keys that can be used to sign all 1465 the RRsets in a zone that require signatures, other than the apex 1466 DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note 1467 that a ZSK is sometimes used to sign the apex DNSKEY RRset. 1469 Combined signing key (CSK): "In cases where the differentiation 1470 between the KSK and ZSK is not made, i.e., where keys have the 1471 role of both KSK and ZSK, we talk about a Single-Type Signing 1472 Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes 1473 called a "combined signing key" or CSK. It is operational 1474 practice, not protocol, that determines whether a particular key 1475 is a ZSK, a KSK, or a CSK. 1477 Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be 1478 used to distinguish between keys that are intended to be used as 1479 the secure entry point into the zone when building chains of 1480 trust, i.e., they are (to be) pointed to by parental DS RRs or 1481 configured as a trust anchor. Therefore, it is suggested that the 1482 SEP flag be set on keys that are used as KSKs and not on keys that 1483 are used as ZSKs, while in those cases where a distinction between 1484 a KSK and ZSK is not made (i.e., for a Single-Type Signing 1485 Scheme), it is suggested that the SEP flag be set on all keys." 1486 (Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is 1487 only a hint, and its presence or absence may not be used to 1488 disqualify a given DNSKEY RR from use as a KSK or ZSK during 1489 validation. 1491 The original definition of SEPs was in [RFC3757]. That definition 1492 clearly indicated that the SEP was a key, not just a bit in the 1493 key. The abstract of [RFC3757] says: "With the Delegation Signer 1494 (DS) resource record (RR), the concept of a public key acting as a 1495 secure entry point (SEP) has been introduced. During exchanges of 1496 public keys with the parent there is a need to differentiate SEP 1497 keys from other public keys in the Domain Name System KEY (DNSKEY) 1498 resource record set. A flag bit in the DNSKEY RR is defined to 1499 indicate that DNSKEY is to be used as a SEP." That definition of 1500 the SEP as a key was made obsolete by [RFC4034], and the 1501 definition from [RFC6781] is consistent with [RFC4034]. 1503 Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 1504 A validating security-aware resolver uses this public key or hash 1505 as a starting point for building the authentication chain to a 1506 signed DNS response. In general, a validating resolver will have 1507 to obtain the initial values of its trust anchors via some secure 1508 or trusted means outside the DNS protocol." (Quoted from 1509 [RFC4033], Section 2) 1511 DNSSEC Policy (DP): A statement that "sets forth the security 1512 requirements and standards to be implemented for a DNSSEC-signed 1513 zone." (Quoted from [RFC6841], Section 2) 1515 DNSSEC Practice Statement (DPS): "A practices disclosure document 1516 that may support and be a supplemental document to the DNSSEC 1517 Policy (if such exists), and it states how the management of a 1518 given zone implements procedures and controls at a high level." 1519 (Quoted from [RFC6841], Section 2) 1521 Hardware security module (HSM): A specialized piece of hardware that 1522 is used to create keys for signatures and to sign messages. In 1523 DNSSEC, HSMs are often used to hold the private keys for KSKs and 1524 ZSKs and to create the signatures used in RRSIG records at 1525 periodic intervals. 1527 Signing software: Authoritative DNS servers that support DNSSEC 1528 often contain software that facilitates the creation and 1529 maintenance of DNSSEC signatures in zones. There is also stand- 1530 alone software that can be used to sign a zone regardless of 1531 whether the authoritative server itself supports signing. 1533 Sometimes signing software can support particular HSMs as part of 1534 the signing process. 1536 11. DNSSEC States 1538 A validating resolver can determine that a response is in one of four 1539 states: secure, insecure, bogus, or indeterminate. These states are 1540 defined in [RFC4033] and [RFC4035], although the two definitions 1541 differ a bit. This document makes no effort to reconcile the two 1542 definitions, and takes no position as to whether they need to be 1543 reconciled. 1545 Section 5 of [RFC4033] says: 1547 A validating resolver can determine the following 4 states: 1549 Secure: The validating resolver has a trust anchor, has a chain 1550 of trust, and is able to verify all the signatures in the 1551 response. 1553 Insecure: The validating resolver has a trust anchor, a chain 1554 of trust, and, at some delegation point, signed proof of the 1555 non-existence of a DS record. This indicates that subsequent 1556 branches in the tree are provably insecure. A validating 1557 resolver may have a local policy to mark parts of the domain 1558 space as insecure. 1560 Bogus: The validating resolver has a trust anchor and a secure 1561 delegation indicating that subsidiary data is signed, but 1562 the response fails to validate for some reason: missing 1563 signatures, expired signatures, signatures with unsupported 1564 algorithms, data missing that the relevant NSEC RR says 1565 should be present, and so forth. 1567 Indeterminate: There is no trust anchor that would indicate that a 1568 specific portion of the tree is secure. This is the default 1569 operation mode. 1571 Section 4.3 of [RFC4035] says: 1573 A security-aware resolver must be able to distinguish between four 1574 cases: 1576 Secure: An RRset for which the resolver is able to build a chain 1577 of signed DNSKEY and DS RRs from a trusted security anchor to 1578 the RRset. In this case, the RRset should be signed and is 1579 subject to signature validation, as described above. 1581 Insecure: An RRset for which the resolver knows that it has no 1582 chain of signed DNSKEY and DS RRs from any trusted starting 1583 point to the RRset. This can occur when the target RRset lies 1584 in an unsigned zone or in a descendent [sic] of an unsigned 1585 zone. In this case, the RRset may or may not be signed, but 1586 the resolver will not be able to verify the signature. 1588 Bogus: An RRset for which the resolver believes that it ought to 1589 be able to establish a chain of trust but for which it is 1590 unable to do so, either due to signatures that for some reason 1591 fail to validate or due to missing data that the relevant 1592 DNSSEC RRs indicate should be present. This case may indicate 1593 an attack but may also indicate a configuration error or some 1594 form of data corruption. 1596 Indeterminate: An RRset for which the resolver is not able to 1597 determine whether the RRset should be signed, as the resolver 1598 is not able to obtain the necessary DNSSEC RRs. This can occur 1599 when the security-aware resolver is not able to contact 1600 security-aware name servers for the relevant zones. 1602 12. Security Considerations 1604 These definitions do not change any security considerations for the 1605 DNS. 1607 13. IANA Considerations 1609 None. 1611 14. References 1613 14.1. Normative References 1615 [IANA_RootFiles] 1616 Internet Assigned Numbers Authority, "IANA Root Files", 1617 2016, . 1619 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1620 RFC 882, DOI 10.17487/RFC0882, November 1983, 1621 . 1623 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1624 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1625 . 1627 [RFC1035] Mockapetris, P., "Domain names - implementation and 1628 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1629 November 1987, . 1631 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1632 Application and Support", STD 3, RFC 1123, 1633 DOI 10.17487/RFC1123, October 1989, 1634 . 1636 [RFC1912] Barr, D., "Common DNS Operational and Configuration 1637 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996, 1638 . 1640 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1641 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1642 August 1996, . 1644 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1645 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1646 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1647 . 1649 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1650 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1651 . 1653 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 1654 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 1655 DOI 10.17487/RFC2182, July 1997, 1656 . 1658 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1659 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1660 . 1662 [RFC3731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1663 Domain Name Mapping", RFC 3731, DOI 10.17487/RFC3731, 1664 March 2004, . 1666 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1667 Rose, "DNS Security Introduction and Requirements", 1668 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1669 . 1671 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1672 Rose, "Resource Records for the DNS Security Extensions", 1673 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1674 . 1676 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1677 Rose, "Protocol Modifications for the DNS Security 1678 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1679 . 1681 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1682 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 1683 . 1685 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1686 Security (DNSSEC) Hashed Authenticated Denial of 1687 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1688 . 1690 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 1691 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 1692 DOI 10.17487/RFC5358, October 2008, 1693 . 1695 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1696 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1697 . 1699 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 1700 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, 1701 May 2010, . 1703 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1704 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1705 . 1707 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, 1708 "Recommendations for the Remediation of Bots in ISP 1709 Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, 1710 . 1712 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1713 Operational Practices, Version 2", RFC 6781, 1714 DOI 10.17487/RFC6781, December 2012, 1715 . 1717 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 1718 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 1719 DOI 10.17487/RFC6840, February 2013, 1720 . 1722 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 1723 Framework for DNSSEC Policies and DNSSEC Practice 1724 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 1725 . 1727 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1728 for DNS (EDNS(0))", STD 75, RFC 6891, 1729 DOI 10.17487/RFC6891, April 2013, 1730 . 1732 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1733 DNSSEC Delegation Trust Maintenance", RFC 7344, 1734 DOI 10.17487/RFC7344, September 2014, 1735 . 1737 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1738 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1739 2015, . 1741 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1742 for DNS over TLS and DNS over DTLS", RFC 8310, 1743 DOI 10.17487/RFC8310, March 2018, 1744 . 1746 14.2. Informative References 1748 [IANA_Resource_Registry] 1749 Internet Assigned Numbers Authority, "Resource Record (RR) 1750 TYPEs", 2017, 1751 . 1753 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 1754 Internet User Applications", RFC 819, 1755 DOI 10.17487/RFC0819, August 1982, 1756 . 1758 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1759 host table specification", RFC 952, DOI 10.17487/RFC0952, 1760 October 1985, . 1762 [RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713, 1763 DOI 10.17487/RFC1713, November 1994, 1764 . 1766 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1767 DOI 10.17487/RFC1995, August 1996, 1768 . 1770 [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 1771 "Basic Socket Interface Extensions for IPv6", RFC 2133, 1772 DOI 10.17487/RFC2133, April 1997, 1773 . 1775 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1776 DOI 10.17487/RFC2775, February 2000, 1777 . 1779 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1780 Requirements for the Address and Routing Parameter Area 1781 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1782 September 2001, . 1784 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, 1785 DOI 10.17487/RFC3425, November 2002, 1786 . 1788 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 1789 System KEY (DNSKEY) Resource Record (RR) Secure Entry 1790 Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April 1791 2004, . 1793 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1794 DOI 10.17487/RFC3912, September 2004, 1795 . 1797 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1798 RFC 4641, DOI 10.17487/RFC4641, September 2006, 1799 . 1801 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution 1802 Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, 1803 October 2006, . 1805 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1806 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1807 December 2006, . 1809 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1810 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 1811 2007, . 1813 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1814 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1815 . 1817 [RFC5890] Klensin, J., "Internationalized Domain Names for 1818 Applications (IDNA): Definitions and Document Framework", 1819 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1820 . 1822 [RFC5891] Klensin, J., "Internationalized Domain Names in 1823 Applications (IDNA): Protocol", RFC 5891, 1824 DOI 10.17487/RFC5891, August 2010, 1825 . 1827 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1828 Internationalized Domain Names for Applications (IDNA)", 1829 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1830 . 1832 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 1833 for Internationalized Domain Names for Applications 1834 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 1835 . 1837 [RFC5894] Klensin, J., "Internationalized Domain Names for 1838 Applications (IDNA): Background, Explanation, and 1839 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 1840 . 1842 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 1843 Encodings for Internationalized Domain Names", RFC 6055, 1844 DOI 10.17487/RFC6055, February 2011, 1845 . 1847 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1848 DOI 10.17487/RFC6265, April 2011, 1849 . 1851 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 1852 RFC 6303, DOI 10.17487/RFC6303, July 2011, 1853 . 1855 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1856 Cheshire, "Internet Assigned Numbers Authority (IANA) 1857 Procedures for the Management of the Service Name and 1858 Transport Protocol Port Number Registry", BCP 165, 1859 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1860 . 1862 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1863 Internationalization in the IETF", BCP 166, RFC 6365, 1864 DOI 10.17487/RFC6365, September 2011, 1865 . 1867 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1868 DOI 10.17487/RFC6762, February 2013, 1869 . 1871 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1872 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 1873 February 2014, . 1875 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1876 Registration Data Access Protocol (RDAP)", RFC 7480, 1877 DOI 10.17487/RFC7480, March 2015, 1878 . 1880 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 1881 Registration Data Access Protocol (RDAP)", RFC 7481, 1882 DOI 10.17487/RFC7481, March 2015, 1883 . 1885 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 1886 Protocol (RDAP) Query Format", RFC 7482, 1887 DOI 10.17487/RFC7482, March 2015, 1888 . 1890 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 1891 Registration Data Access Protocol (RDAP)", RFC 7483, 1892 DOI 10.17487/RFC7483, March 2015, 1893 . 1895 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1896 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1897 2015, . 1899 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 1900 "Inventory and Analysis of WHOIS Registration Objects", 1901 RFC 7485, DOI 10.17487/RFC7485, March 2015, 1902 . 1904 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1905 and P. Hoffman, "Specification for DNS over Transport 1906 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1907 2016, . 1909 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1910 Transport Layer Security (DTLS)", RFC 8094, 1911 DOI 10.17487/RFC8094, February 2017, 1912 . 1914 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS 1915 Resolver with Priming Queries", BCP 209, RFC 8109, 1916 DOI 10.17487/RFC8109, March 2017, 1917 . 1919 [RSSAC026] 1920 Root Server System Advisory Committee (RSSAC), "RSSAC 1921 Lexicon", 2017, 1922 . 1925 Appendix A. Definitions Updated by this Document 1927 The following definitions from RFCs are updated by this document: 1929 o Forwarder in [RFC2308] 1931 o Secure Entry Point (SEP) in [RFC3757]; note, however, that this 1932 RFC is already obsolete 1934 Appendix B. Definitions First Defined in this Document 1936 The following definitions are first defined in this document: 1938 o "Alias" in Section 2 1940 o "Apex" in Section 7 1942 o "arpa" in Section 7 1944 o "Bailiwick" in Section 7 1946 o "Class independent" in Section 5 1947 o "Delegation-centric zone" in Section 7 1949 o "Delegation" in Section 7 1951 o "DNS operator" in Section 9 1953 o "DNSSEC-aware" in Section 10 1955 o "DNSSEC-unaware" in Section 10 1957 o "Forwarding" in Section 6 1959 o "Full resolver" in Section 6 1961 o "Fully qualified domain name" in Section 2 1963 o "Global DNS" in Section 2 1965 o "Hardware Security Module (HSM)" in Section 10 1967 o "Host name" in Section 2 1969 o "IDN" in Section 2 1971 o "In-bailiwick" in Section 7 1973 o "Iterative resolution" in Section 6 1975 o "Label" in Section 2 1977 o "Locally served DNS zone" in Section 2 1979 o "Naming system" in Section 2 1981 o "Negative response" in Section 3 1983 o "Non-recursive query" in Section 6 1985 o "Open resolver" in Section 6 1987 o "Out-of-bailiwick" in Section 7 1989 o "Passive DNS" in Section 6 1991 o "Policy-implementing resolver" in Section 6 1993 o "Presentation format" in Section 5 1994 o "Priming" in Section 6 1996 o "Private DNS" in Section 2 1998 o "Recursive resolver" in Section 6 2000 o "Referrals" in Section 4 2002 o "Registrant" in Section 9 2004 o "Registrar" in Section 9 2006 o "Registry" in Section 9 2008 o "Root zone" in Section 7 2010 o "Secure Entry Point (SEP)" in Section 10 2012 o "Signing software" in Section 10 2014 o "Split DNS" in Section 6 2016 o "Stub resolver" in Section 6 2018 o "Subordinate" in Section 8 2020 o "Superordinate" in Section 8 2022 o "TLD" in Section 2 2024 o "Validating resolver" in Section 10 2026 o "Validation" in Section 10 2028 o "View" in Section 6 2030 o "Zone transfer" in Section 6 2032 Index 2034 A 2035 Address records 14 2036 Alias 8 2037 Anycast 20 2038 Apex 22 2039 Asterisk label 26 2040 Authoritative data 22 2041 Authoritative server 17 2042 Authoritative-only server 18 2043 arpa: Address and Routing Parameter Area Domain 25 2045 C 2046 CNAME 9 2047 Canonical name 8 2048 Child 21 2049 Class independent 14 2050 Closest encloser 26 2051 Closest provable encloser 26 2052 Combined signing key (CSK) 31 2054 D 2055 DNS operator 27 2056 DNSSEC Policy (DP) 32 2057 DNSSEC Practice Statement (DPS) 32 2058 DNSSEC-aware and DNSSEC-unaware 28 2059 Delegation 22 2060 Delegation-centric zone 24 2061 Domain name 4 2063 E 2064 EDNS 13 2065 EPP 27 2066 Empty non-terminals (ENT) 24 2068 F 2069 FORMERR 9 2070 Fast flux DNS 25 2071 Forward lookup 25 2072 Forwarder 19 2073 Forwarding 19 2074 Full resolver 17 2075 Full-service resolver 17 2076 Fully qualified domain name (FQDN) 7 2078 G 2079 Global DNS 4 2080 Glue records 23 2082 H 2083 Hardware security module (HSM) 32 2084 Hidden master 19 2085 Host name 7 2087 I 2088 IDN 8 2089 In-bailiwick 23 2090 Insecure delegation 30 2091 Instance 21 2092 Iterative mode 15 2093 Iterative resolution 16 2095 K 2096 Key signing key (KSK) 31 2098 L 2099 Label 4 2100 Lame delegation 22 2101 Locally served DNS zone 7 2103 M 2104 Master file 13 2105 Master server 18 2106 Multicast DNS 6 2108 N 2109 NODATA 9 2110 NOERROR 9 2111 NOTIMP 9 2112 NSEC 29 2113 NSEC3 29 2114 NXDOMAIN 9 2115 Naming system 3 2116 Negative caching 17 2117 Negative response 10 2118 Next closer name 26 2119 Non-recursive query 16 2121 O 2122 OPT 13 2123 Occluded name 24 2124 Open resolver 20 2125 Opt-out 29 2126 Origin 21 2127 Out-of-bailiwick 23 2128 Owner 13 2130 P 2131 Parent 21 2132 Passive DNS 20 2133 Policy-implementing resolver 19 2134 Presentation format 13 2135 Primary master 18 2136 Primary server 18 2137 Priming 17 2138 Privacy-enabling DNS server 21 2139 Private DNS 6 2140 Public suffix 27 2142 Q 2143 QNAME 10 2145 R 2146 RDAP 27 2147 REFUSED 9 2148 RR 12 2149 RRset 12 2150 Recursive mode 15 2151 Recursive query 16 2152 Recursive resolver 16 2153 Referrals 11 2154 Registrant 27 2155 Registrar 27 2156 Registry 26 2157 Resolver 15 2158 Reverse DNS, reverse lookup 25 2159 Root hints 17 2160 Root zone 24 2162 S 2163 SERVFAIL 9 2164 SOA field names 13 2165 Secondary server 18 2166 Secure Entry Point (SEP) 31 2167 Service name 25 2168 Signed zone 28 2169 Signing software 32 2170 Slave server 18 2171 Source of Synthesis 26 2172 Split DNS 20 2173 Split-horizon DNS 20 2174 Stealth server 19 2175 Stub resolver 15 2176 Subdomain 8 2177 Subordinate 28 2178 Superordinate 28 2180 T 2181 TLD 8 2182 TTL 13 2183 Trust anchor 32 2185 U 2186 Unsigned zone 29 2188 V 2189 Validating resolver 31 2190 Validation 30 2191 View 20 2193 W 2194 WHOIS 27 2195 Wildcard 25 2196 Wildcard domain name 26 2198 Z 2199 Zone 21 2200 Zone cut 22 2201 Zone enumeration 30 2202 Zone signing key (ZSK) 31 2203 Zone transfer 18 2205 Acknowledgements 2207 The following is the Acknowledgements for RFC 7719. Additional 2208 acknowledgements may be added as this draft is worked on. 2210 The authors gratefully acknowledge all of the authors of DNS-related 2211 RFCs that proceed this one. Comments from Tony Finch, Stephane 2212 Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John 2213 Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, 2214 David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, 2215 John Klensin, David Black, and many others in the DNSOP Working Group 2216 helped shape RFC 7719. 2218 Additional people contributed to this document, including: Bob 2219 Harold, Dick Franks, Evan Hunt, John Dickinson, Mark Andrews, Martin 2220 Hoffmann, Paul Vixie, Peter Koch, Duane Wessels [[ MORE NAMES WILL 2221 APPEAR HERE AS FOLKS CONTRIBUTE]]. 2223 Authors' Addresses 2225 Paul Hoffman 2226 ICANN 2228 Email: paul.hoffman@icann.org 2229 Andrew Sullivan 2230 Oracle 2231 100 Milverton Drive 2232 Mississauga, ON L5R 4H1 2233 Canada 2235 Email: andrew.s.sullivan@oracle.com 2237 Kazunori Fujiwara 2238 Japan Registry Services Co., Ltd. 2239 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 2240 Chiyoda-ku, Tokyo 101-0065 2241 Japan 2243 Phone: +81 3 5215 8451 2244 Email: fujiwara@jprs.co.jp