idnits 2.17.1 draft-ietf-dnsop-terminology-bis-07.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 925: '...s. An in-domain name server name MUST...' RFC 2119 keyword, line 1147: '...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 (October 18, 2017) is 2382 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 1235, but not defined ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) ** 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: 6 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: April 21, 2018 JPRS 8 October 18, 2017 10 DNS Terminology 11 draft-ietf-dnsop-terminology-bis-07 13 Abstract 15 The DNS is defined in literally dozens of different RFCs. The 16 terminology used by implementers and developers of DNS protocols, and 17 by operators of DNS systems, has sometimes changed in the decades 18 since the DNS was first defined. This document gives current 19 definitions for many of the terms used in the DNS in a single 20 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 http://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 April 21, 2018. 42 Copyright Notice 44 Copyright (c) 2017 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 (http://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 Header and Response Codes . . . . . . . . . . . . . . . . 9 62 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 11 63 5. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 13 64 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 65 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 23 66 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 24 67 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 28 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 72 12.2. Informative References . . . . . . . . . . . . . . . . . 33 73 Appendix A. Definitions Updated by this Document . . . . . . . . 36 74 Appendix B. Definitions First Defined in this Document . . . . . 37 75 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 42 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 79 1. Introduction 81 The Domain Name System (DNS) is a simple query-response protocol 82 whose messages in both directions have the same format. (See 83 Section 2 for a fuller definition.) The protocol and message format 84 are defined in [RFC1034] and [RFC1035]. These RFCs defined some 85 terms, but later documents defined others. Some of the terms from 86 [RFC1034] and [RFC1035] now have somewhat different meanings than 87 they did in 1987. 89 This document collects a wide variety of DNS-related terms. Some of 90 them have been precisely defined in earlier RFCs, some have been 91 loosely defined in earlier RFCs, and some are not defined in any 92 earlier RFC at all. 94 Most of the definitions here are the consensus definition of the DNS 95 community -- both protocol developers and operators. Some of the 96 definitions differ from earlier RFCs, and those differences are 97 noted. In this document, where the consensus definition is the same 98 as the one in an RFC, that RFC is quoted. Where the consensus 99 definition has changed somewhat, the RFC is mentioned but the new 100 stand-alone definition is given. See Appendix A for a list of the 101 definitions that this document updates. 103 It is important to note that, during the development of this 104 document, it became clear that some DNS-related terms are interpreted 105 quite differently by different DNS experts. Further, some terms that 106 are defined in early DNS RFCs now have definitions that are generally 107 agreed to, but that are different from the original definitions. 108 Therefore, this document is a substantial revision to [RFC7719]. 110 The terms are organized loosely by topic. Some definitions are for 111 new terms for things that are commonly talked about in the DNS 112 community but that never had terms defined for them. 114 Other organizations sometimes define DNS-related terms their own way. 115 For example, the W3C defines "domain" at 116 https://specs.webplatform.org/url/webspecs/develop/. The Root Server 117 System Advisory Committee (RSSAC) has a good lexicon [RSSAC026]. 119 Note that there is no single consistent definition of "the DNS". It 120 can be considered to be some combination of the following: a commonly 121 used naming scheme for objects on the Internet; a distributed 122 database representing the names and certain properties of these 123 objects; an architecture providing distributed maintenance, 124 resilience, and loose coherency for this database; and a simple 125 query-response protocol (as mentioned below) implementing this 126 architecture. Section 2 defines "global DNS" and "private DNS" as a 127 way to deal with these differing definitions. 129 Capitalization in DNS terms is often inconsistent among RFCs and 130 various DNS practitioners. The capitalization used in this document 131 is a best guess at current practices, and is not meant to indicate 132 that other capitalization styles are wrong or archaic. In some 133 cases, multiple styles of capitalization are used for the same term 134 due to quoting from different RFCs. 136 2. Names 138 Naming system: A naming system associates names with data. Naming 139 systems have many significant facets that help differentiate them. 140 Some commonly-identified facets include: 142 * Composition of names 144 * Format of names 145 * Administration of names 147 * Types of data that can be associated with names 149 * Types of metadata for names 151 * Protocol for getting data from a name 153 * Context for resolving a name 155 Note that this list is a small subset of facets that people have 156 identified over time for naming systems, and the IETF has yet to 157 agree on a good set of facets that can be used to compare naming 158 systems. For example, other facets might include "protocol to 159 update data in a name", "privacy of names", and "privacy of data 160 associated with names", but those are not as well-defined as the 161 ones listed above. The list here is chosen because it helps 162 describe the DNS and naming systems similar to the DNS. 164 Domain name: An ordered list of one or more labels. 166 Note that this is a definition independent of the DNS RFCs, and 167 the definition here also applies to systems other than the DNS. 168 [RFC1034] defines the "domain name space" using mathematical trees 169 and their nodes in graph theory, and the definition in [RFC1034] 170 has the same practical result as the definition here. Using graph 171 theory, a domain name is a list of labels identifying a portion 172 along one edge of a directed acyclic graph. A domain name can be 173 relative to other parts of the tree, or it can be fully qualified 174 (in which case, it begins at the common root of the graph). 176 Also note that different IETF and non-IETF documents have used the 177 term "domain name" in many different ways. It is common for 178 earlier documents to use "domain name" to mean "names that match 179 the syntax in [RFC1035]", but possibly with additional rules such 180 as "and are, or will be, resolvable in the global DNS" or "but 181 only using the presentation format". 183 Label: An ordered list of zero or more octets and which makes up a 184 portion of a domain name. Using graph theory, a label identifies 185 one node in a portion of the graph of all possible domain names. 187 Global DNS: Using the short set of facets listed in "Naming system", 188 the global DNS can be defined as follows. Most of the rules here 189 come from [RFC1034] and [RFC1035], although the term "global DNS" 190 has not been defined before now. 192 Composition of names -- A name in the global DNS has one or more 193 labels. The length of each label is between 0 and 63 octets 194 inclusive. In a fully-qualified domain name, the first label in 195 the ordered list is 0 octets long; it is the only label whose 196 length may be 0 octets, and it is called the "root" or "root 197 label". A domain name in the global DNS has a maximum total 198 length of 255 octets in the wire format; the root represents one 199 octet for this calculation. 201 Format of names -- Names in the global DNS are domain names. 202 There are three formats: wire format, presentation format, and 203 common display. 205 The basic wire format for names in the global DNS is a list of 206 labels ordered by decreasing distance from the root, with the root 207 label last. Each label is preceded by a length octet. [RFC1035] 208 also defines a compression scheme that modifies this format. 210 The presentation format for names in the global DNS is a list of 211 labels ordered by decreasing distance from the root, encoded as 212 ASCII, with a "." character between each label. In presentation 213 format, a fully-qualified domain name includes the root label and 214 the associated separator dot. For example, in presentation 215 format, a fully-qualified domain name with two non-root labels is 216 always shown as "example.tld." instead of "example.tld". 217 [RFC1035] defines a method for showing octets that do not display 218 in ASCII. 220 The common display format is used in applications and free text. 221 It is the same as the presentation format, but showing the root 222 label and the "." before it is optional and is rarely done. For 223 example, in common display format, a fully-qualified domain name 224 with two non-root labels is usually shown as "example.tld" instead 225 of "example.tld.". Names in the common display format are 226 normally written such that the directionality of the writing 227 system presents labels by decreasing distance from the root (so, 228 in both English and C the first label in the ordered list is 229 right-most; but in Arabic it may be left-most, depending on local 230 conventions). 232 Administration of names -- Administration is specified by 233 delegation (see the definition of to "delegation" in Section 6). 234 Policies for administration of the root zone in the global DNS are 235 determined by the names operational community, which convenes 236 itself in the Internet Corporation for Assigned Names and Numbers 237 (ICANN). The names operational community selects the IANA 238 Functions Operator for the global DNS root zone. At the time this 239 document is published, that operator is Public Technical 240 Identifiers (PTI). The name servers that serve the root zone are 241 provided by independent root operators. Other zones in the global 242 DNS have their own policies for administration. 244 Types of data that can be associated with names -- A name can have 245 zero or more resource records associated with it. There are 246 numerous types of resource records with unique data structures 247 defined in many different RFCs and in the IANA registry at 248 [IANA_Resource_Registry]. 250 Types of metadata for names -- Any name that is published in the 251 DNS appears as a set of resource records (see the definition of 252 "RRset" in Section 4). Some names do not themselves have data 253 associated with them in the DNS, but "appear" in the DNS anyway 254 because they form part of a longer name that does have data 255 associated with it (see the defintion of "empty non-terminals" in 256 Section 6). 258 Protocol for getting data from a name -- The protocol described in 259 [RFC1035]. 261 Context for resolving a name -- The global DNS root zone 262 distributed by PTI. 264 Private DNS: Names that use the protocol described in [RFC1035] but 265 that do not rely on the global DNS root zone, or names that are 266 otherwise not generally available on the Internet but are using 267 the protocol described in [RFC1035]. A system can use both the 268 global DNS and one or more private DNS systems; for example, see 269 "Split DNS" in Section 7. 271 Note that domain names that do not appear in the DNS, and that are 272 intended never to be looked up using the DNS protocol, are not 273 part of the global DNS or a private DNS even though they are 274 domain names. 276 Locally served DNS zone: A locally served DNS zone is a special case 277 of private DNS. Names are resolved using the DNS protocol in a 278 local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that 279 are locally served zones. Resolution of names through locally 280 served zones may result in ambiguous results. For example, the 281 same name may resolve to different results in different locally 282 served DNS zone contexts. The context through which a locally 283 served zone may be explicit, for example, as defined in [RFC6303], 284 or implicit, as defined by local DNS administration and not known 285 to the resolution client. 287 Fully qualified domain name (FQDN): This is often just a clear way 288 of saying the same thing as "domain name of a node", as outlined 289 above. However, the term is ambiguous. Strictly speaking, a 290 fully qualified domain name would include every label, including 291 the zero-length label of the root: such a name would be written 292 "www.example.net." (note the terminating dot). But because every 293 name eventually shares the common root, names are often written 294 relative to the root (such as "www.example.net") and are still 295 called "fully qualified". This term first appeared in [RFC0819]. 296 In this document, names are often written relative to the root. 298 The need for the term "fully qualified domain name" comes from the 299 existence of partially qualified domain names, which are names 300 where one or more of the earliest labels in the ordered list are 301 omitted (for example, "www"). Such relative names are understood 302 only by context. 304 Host name: This term and its equivalent, "hostname", have been 305 widely used but are not defined in [RFC1034], [RFC1035], 306 [RFC1123], or [RFC2181]. The DNS was originally deployed into the 307 Host Tables environment as outlined in [RFC0952], and it is likely 308 that the term followed informally from the definition there. Over 309 time, the definition seems to have shifted. "Host name" is often 310 meant to be a domain name that follows the rules in Section 3.5 of 311 [RFC1034], the "preferred name syntax". Note that any label in a 312 domain name can contain any octet value; hostnames are generally 313 considered to be domain names where every label follows the rules 314 in the "preferred name syntax", with the amendment that labels can 315 start with ASCII digits (this amendment comes from Section 2.1 of 316 [RFC1123]). 318 People also sometimes use the term hostname to refer to just the 319 first label of an FQDN, such as "printer" in 320 "printer.admin.example.com". (Sometimes this is formalized in 321 configuration in operating systems.) In addition, people 322 sometimes use this term to describe any name that refers to a 323 machine, and those might include labels that do not conform to the 324 "preferred name syntax". 326 TLD: A Top-Level Domain, meaning a zone that is one layer below the 327 root, such as "com" or "jp". There is nothing special, from the 328 point of view of the DNS, about TLDs. Most of them are also 329 delegation-centric zones, and there are significant policy issues 330 around their operation. TLDs are often divided into sub-groups 331 such as Country Code Top-Level Domains (ccTLDs), Generic Top-Level 332 Domains (gTLDs), and others; the division is a matter of policy, 333 and beyond the scope of this document. 335 IDN: The common abbreviation for "Internationalized Domain Name". 336 The IDNA protocol is the standard mechanism for handling domain 337 names with non-ASCII characters in applications in the DNS. The 338 current standard, normally called "IDNA2008", is defined in 339 [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These 340 documents define many IDN-specific terms such as "LDH label", 341 "A-label", and "U-label". [RFC6365] defines more terms that 342 relate to internationalization (some of which relate to IDNs), and 343 [RFC6055] has a much more extensive discussion of IDNs, including 344 some new terminology. 346 Subdomain: "A domain is a subdomain of another domain if it is 347 contained within that domain. This relationship can be tested by 348 seeing if the subdomain's name ends with the containing domain's 349 name." (Quoted from [RFC1034], Section 3.1). For example, in the 350 host name "nnn.mmm.example.com", both "mmm.example.com" and 351 "nnn.mmm.example.com" are subdomains of "example.com". 353 Alias: The owner of a CNAME resource record, or a subdomain of the 354 owner of a DNAME resource record. See also "canonical name". 356 Canonical name: A CNAME resource record "identifies its owner name 357 as an alias, and specifies the corresponding canonical name in the 358 RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) 359 This usage of the word "canonical" is related to the mathematical 360 concept of "canonical form". 362 CNAME: "It is traditional to refer to the owner of a CNAME record as 363 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 364 'canonical name', and the owner of a CNAME record is an alias, not 365 a canonical name." (Quoted from [RFC2181], Section 10.1.1) 367 Public suffix: "A domain that is controlled by a public registry." 368 (Quoted from [RFC6265], Section 5.3) A common definition for this 369 term is a domain under which subdomains can be registered, and on 370 which HTTP cookies ([RFC6265]) should not be set. There is no 371 indication in a domain name whether it is a public suffix; that 372 can only be determined by outside means. In fact, both a domain 373 and a subdomain of that domain can be public suffixes. 375 There is nothing inherent in a domain name to indicate whether it 376 is a public suffix. One resource for identifying public suffixes 377 is the Public Suffix List (PSL) maintained by Mozilla 378 (http://publicsuffix.org/). 380 For example, at the time this document is published, the "com.au" 381 domain is listed as a public suffix in the PSL. (Note that this 382 example might change in the future.) 383 Note that the term "public suffix" is controversial in the DNS 384 community for many reasons, and may be significantly changed in 385 the future. One example of the difficulty of calling a domain a 386 public suffix is that designation can change over time as the 387 registration policy for the zone changes, such as was the case 388 with the "uk" TLD in 2014. 390 3. DNS Header and Response Codes 392 The header of a DNS message is its first 12 octets. Many of the 393 fields and flags in the header diagram in Sections 4.1.1 through 394 4.1.3 of [RFC1035] are referred to by their names in that diagram. 395 For example, the response codes are called "RCODEs", the data for a 396 record is called the "RDATA", and the authoritative answer bit is 397 often called "the AA flag" or "the AA bit". 399 QNAME The most commonly-used rough definition is that the QNAME is a 400 field in the Question section of a query. "A standard query 401 specifies a target domain name (QNAME), query type (QTYPE), and 402 query class (QCLASS) and asks for RRs which match." (Quoted from 403 [RFC1034], Section 3.7.1.). Strictly speaking, the definition 404 comes from [RFC1035], Section 4.1.2, where the QNAME is defined in 405 respect of the Question Section. This definition appears to be 406 applied consistently: the discussion of inverse queries in section 407 6.4 refers to the "owner name of the query RR and its TTL", 408 because inverse queries populate the Answer Section and leave the 409 Question Section empty. (Inverse queries are deprecated in 410 [RFC3425], and so relevant definitions do not appear in this 411 document.) 413 [RFC2308], however, has an alternate definition that puts the 414 QNAME in the answer (or series of answers) instead of the query. 415 It defines QNAME as: "...the name in the query section of an 416 answer, or where this resolves to a CNAME, or CNAME chain, the 417 data field of the last CNAME. The last CNAME in this sense is 418 that which contains a value which does not resolve to another 419 CNAME." This definition has a certain internal logic, because of 420 the way CNAME substitution works and the definition of CNAME. If 421 a name server does not find an RRset that matches a query, but it 422 finds the same name in the same class with a CNAME record, then 423 the name server "includes the CNAME record in the response and 424 restarts the query at the domain name specified in the data field 425 of the CNAME record." ([RFC1034] Section 3.6.2). This is made 426 explicit in the resolution algorithm outlined in Section 4.3.2 of 427 [RFC1034], which says to "change QNAME to the canonical name in 428 the CNAME RR, and go back to step 1" in the case of a CNAME RR. 429 Since a CNAME record explicitly declares that the owner name is 430 canonically named what is in the RDATA, then there is a way to 431 view the new name (i.e. the name that was in the RDATA of the 432 CNAME RR) as also being the QNAME. 434 This creates a kind of confusion, however, because the answer to a 435 query that results in CNAME processing contains in the echoed 436 Question Section one QNAME (the name in the original query), and a 437 second QNAME that is in the data field of the last CNAME. The 438 confusion comes from the iterative/recursive mode of resolution, 439 which finally returns an answer that need not actually have the 440 same owner name as the QNAME contained in the original query. 442 To address this potential confusion, it is helpful to distinguish 443 between three meanings: 445 * QNAME (original): The name actually sent in the Question 446 Section in the orignal query, which is always echoed in the 447 (final) reply in the Question Section when the QR bit is set to 448 1. 450 * QNAME (effective): A name actually resolved, which is either 451 the name originally queried, or a name received in a CNAME 452 chain response. 454 * QNAME (final): The name actually resolved, which is either the 455 name actually queried or else the last name in a CNAME chain 456 response. 458 Some of response codes that are defined in [RFC1035] have acquired 459 their own shorthand names. Some common response code names that 460 appear without reference to the numeric value are "FORMERR", 461 "SERVFAIL", and "NXDOMAIN" (the latter of which is also referred to 462 as "Name Error"). All of the RCODEs are listed at 463 http://www.iana.org/assignments/dns-parameters, although that site 464 uses mixed-case capitalization, while most documents use all-caps. 466 NODATA: "A pseudo RCODE which indicates that the name is valid for 467 the given class, but there are no records of the given type. A 468 NODATA response has to be inferred from the answer." (Quoted from 469 [RFC2308], Section 1.) "NODATA is indicated by an answer with the 470 RCODE set to NOERROR and no relevant answers in the answer 471 section. The authority section will contain an SOA record, or 472 there will be no NS records there." (Quoted from [RFC2308], 473 Section 2.2.) Note that referrals have a similar format to NODATA 474 replies; [RFC2308] explains how to distinguish them. 476 The term "NXRRSET" is sometimes used as a synonym for NODATA. 477 However, this is a mistake, given that NXRRSET is a specific error 478 code defined in [RFC2136]. 480 Negative response: A response that indicates that a particular RRset 481 does not exist, or whose RCODE indicates the nameserver cannot 482 answer. Sections 2 and 7 of [RFC2308] describe the types of 483 negative responses in detail. 485 Referrals: Data from the authority section of a non-authoritative 486 answer. [RFC1035] Section 2.1 defines "authoritative" data. 487 However, referrals at zone cuts (defined in Section 6) are not 488 authoritative. Referrals may be zone cut NS resource records and 489 their glue records. NS records on the parent side of a zone cut 490 are an authoritative delegation, but are normally not treated as 491 authoritative data. In general, a referral is a way for a server 492 to send an answer saying that the server does not know the answer, 493 but knows where the query should be directed in order to get an 494 answer. Historically, many authoritative servers answered with a 495 referral to the root zone when queried for a name for which they 496 were not authoritative, but this practice has declined. 498 4. Resource Records 500 RR: An acronym for resource record. ([RFC1034], Section 3.6.) 502 RRset: A set of resource records with the same label, class and 503 type, but with different data. (Definition from [RFC2181]) Also 504 spelled RRSet in some documents. As a clarification, "same label" 505 in this definition means "same owner name". In addition, 506 [RFC2181] states that "the TTLs of all RRs in an RRSet must be the 507 same". (This definition is definitely not the same as "the 508 response one gets to a query for QTYPE=ANY", which is an 509 unfortunate misunderstanding.) 511 Master file: "Master files are text files that contain RRs in text 512 form. Since the contents of a zone can be expressed in the form 513 of a list of RRs a master file is most often used to define a 514 zone, though it can be used to list a cache's contents." 515 ([RFC1035], Section 5.) 517 Presentation format: The text format used in master files. This 518 format is shown but not formally defined in [RFC1034] and 519 [RFC1035]. The term "presentation format" first appears in 520 [RFC4034]. 522 EDNS: The extension mechanisms for DNS, defined in [RFC6891]. 523 Sometimes called "EDNS0" or "EDNS(0)" to indicate the version 524 number. EDNS allows DNS clients and servers to specify message 525 sizes larger than the original 512 octet limit, to expand the 526 response code space, and potentially to carry additional options 527 that affect the handling of a DNS query. 529 OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to 530 contain control information pertaining to the question-and-answer 531 sequence of a specific transaction. (Definition from [RFC6891], 532 Section 6.1.1) It is used by EDNS. 534 Owner: The domain name where a RR is found ([RFC1034], Section 3.6). 535 Often appears in the term "owner name". 537 SOA field names: DNS documents, including the definitions here, 538 often refer to the fields in the RDATA of an SOA resource record 539 by field name. Those fields are defined in Section 3.3.13 of 540 [RFC1035]. The names (in the order they appear in the SOA RDATA) 541 are MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. 542 Note that the meaning of MINIMUM field is updated in Section 4 of 543 [RFC2308]; the new definition is that the MINIMUM field is only 544 "the TTL to be used for negative responses". This document tends 545 to use field names instead of terms that describe the fields. 547 TTL: The maximum "time to live" of a resource record. "A TTL value 548 is an unsigned number, with a minimum value of 0, and a maximum 549 value of 2147483647. That is, a maximum of 2^31 - 1. When 550 transmitted, the TTL is encoded in the less significant 31 bits of 551 the 32 bit TTL field, with the most significant, or sign, bit set 552 to zero." (Quoted from [RFC2181], Section 8) (Note that [RFC1035] 553 erroneously stated that this is a signed integer; that was fixed 554 by [RFC2181].) 556 The TTL "specifies the time interval that the resource record may 557 be cached before the source of the information should again be 558 consulted". (Quoted from [RFC1035], Section 3.2.1) Also: "the 559 time interval (in seconds) that the resource record may be cached 560 before it should be discarded". (Quoted from [RFC1035], 561 Section 4.1.3). Despite being defined for a resource record, the 562 TTL of every resource record in an RRset is required to be the 563 same ([RFC2181], Section 5.2). 565 The reason that the TTL is the maximum time to live is that a 566 cache operator might decide to shorten the time to live for 567 operational purposes, such as if there is a policy to disallow TTL 568 values over a certain number. Also, if a value is flushed from 569 the cache when its value is still positive, the value effectively 570 becomes zero. Some servers are known to ignore the TTL on some 571 RRsets (such as when the authoritative data has a very short TTL) 572 even though this is against the advice in RFC 1035. 574 There is also the concept of a "default TTL" for a zone, which can 575 be a configuration parameter in the server software. This is 576 often expressed by a default for the entire server, and a default 577 for a zone using the $TTL directive in a zone file. The $TTL 578 directive was added to the master file format by [RFC2308]. 580 Class independent: A resource record type whose syntax and semantics 581 are the same for every DNS class. A resource record type that is 582 not class independent has different meanings depending on the DNS 583 class of the record, or the meaning is undefined for classes other 584 than IN (class 1, the Internet). 586 5. DNS Servers and Clients 588 This section defines the terms used for the systems that act as DNS 589 clients, DNS servers, or both. In the RFCs, DNS servers are 590 sometimes called "name servers", "nameservers", or just "servers". 591 There is no formal definition of DNS server, but the RFCs generally 592 assume that it is an Internet server that listens for queries and 593 sends responses using the DNS protocol defined in [RFC1035] and its 594 successors. 596 For terminology specific to the public DNS root server system, see 597 [RSSAC026]. That document defines terms such as "root server", "root 598 server operator", and terms that are specific to the way that the 599 root zone of the public DNS is served. 601 Resolver: A program "that extract[s] information from name servers 602 in response to client requests." (Quoted from [RFC1034], 603 Section 2.4) "The resolver is located on the same machine as the 604 program that requests the resolver's services, but it may need to 605 consult name servers on other hosts." (Quoted from [RFC1034], 606 Section 5.1) A resolver performs queries for a name, type, and 607 class, and receives answers. The logical function is called 608 "resolution". In practice, the term is usually referring to some 609 specific type of resolver (some of which are defined below), and 610 understanding the use of the term depends on understanding the 611 context. 613 A related term is "resolve", which is not formally defined in 614 [RFC1034] or [RFC1035]. An imputed definition might be "asking a 615 question that consists of a domain name, class, and type, and 616 receiving some sort of answer". Similarly, an imputed definition 617 of "resolution" might be "the answer received from resolving". 619 Stub resolver: A resolver that cannot perform all resolution itself. 620 Stub resolvers generally depend on a recursive resolver to 621 undertake the actual resolution function. Stub resolvers are 622 discussed but never fully defined in Section 5.3.1 of [RFC1034]. 623 They are fully defined in Section 6.1.3.1 of [RFC1123]. 625 Iterative mode: A resolution mode of a server that receives DNS 626 queries and responds with a referral to another server. 627 Section 2.3 of [RFC1034] describes this as "The server refers the 628 client to another server and lets the client pursue the query". A 629 resolver that works in iterative mode is sometimes called an 630 "iterative resolver". 632 Recursive mode: A resolution mode of a server that receives DNS 633 queries and either responds to those queries from a local cache or 634 sends queries to other servers in order to get the final answers 635 to the original queries. Section 2.3 of [RFC1034] describes this 636 as "The first server pursues the query for the client at another 637 server". A server operating in recursive mode may be thought of 638 as having a name server side (which is what answers the query) and 639 a resolver side (which performs the resolution function). Systems 640 operating in this mode are commonly called "recursive servers". 641 Sometimes they are called "recursive resolvers". While strictly 642 the difference between these is that one of them sends queries to 643 another recursive server and the other does not, in practice it is 644 not possible to know in advance whether the server that one is 645 querying will also perform recursion; both terms can be observed 646 in use interchangeably. 648 Full resolver: This term is used in [RFC1035], but it is not defined 649 there. RFC 1123 defines a "full-service resolver" that may or may 650 not be what was intended by "full resolver" in [RFC1035]. This 651 term is not properly defined in any RFC. 653 Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this 654 term to mean a resolver that acts in recursive mode with a cache 655 (and meets other requirements). 657 Recursive resolver: A resolver that acts in recursive mode. In 658 general, a recursive resolver is expected to cache the answers it 659 receives (which would make it a full-service resolver), but some 660 recursive resolvers might not cache. 662 Priming: "The act of finding the list of root servers from a 663 configuration that lists some or all of the purported IP addresses 664 of some or all of those root servers." (Quoted from [RFC8109], 665 Section 2.) Priming is most often done from a configuration 666 setting that contains a list of authoritative servers for the root 667 zone. 669 Root hints: "Operators who manage a DNS recursive resolver typically 670 need to configure a 'root hints file'. This file contains the 671 names and IP addresses of the authoritative name servers for the 672 root zone, so the software can bootstrap the DNS resolution 673 process. For many pieces of software, this list comes built into 674 the software." (Quoted from [IANA_RootFiles]) 676 Negative caching: "The storage of knowledge that something does not 677 exist, cannot give an answer, or does not give an answer." 678 (Quoted from [RFC2308], Section 1) 680 Authoritative server: "A server that knows the content of a DNS zone 681 from local knowledge, and thus can answer queries about that zone 682 without needing to query other servers." (Quoted from [RFC2182], 683 Section 2.) It is a system that responds to DNS queries with 684 information about zones for which it has been configured to answer 685 with the AA flag in the response header set to 1. It is a server 686 that has authority over one or more DNS zones. Note that it is 687 possible for an authoritative server to respond to a query without 688 the parent zone delegating authority to that server. 689 Authoritative servers also provide "referrals", usually to child 690 zones delegated from them; these referrals have the AA bit set to 691 0 and come with referral data in the Authority and (if needed) the 692 Additional sections. 694 Authoritative-only server: A name server that only serves 695 authoritative data and ignores requests for recursion. It will 696 "not normally generate any queries of its own. Instead, it 697 answers non-recursive queries from iterative resolvers looking for 698 information in zones it serves." (Quoted from [RFC4697], 699 Section 2.4) 701 Zone transfer: The act of a client requesting a copy of a zone and 702 an authoritative server sending the needed information. (See 703 Section 6 for a description of zones.) There are two common 704 standard ways to do zone transfers: the AXFR ("Authoritative 705 Transfer") mechanism to copy the full zone (described in 706 [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy 707 only parts of the zone that have changed (described in [RFC1995]). 708 Many systems use non-standard methods for zone transfer outside 709 the DNS protocol. 711 Secondary server: "An authoritative server which uses zone transfer 712 to retrieve the zone" (Quoted from [RFC1996], Section 2.1). 713 [RFC2182] describes secondary servers in detail. Although early 714 DNS RFCs such as [RFC1996] referred to this as a "slave", the 715 current common usage has shifted to calling it a "secondary". 716 Secondary servers are also discussed in [RFC1034]. 718 Slave server: See secondary server. 720 Primary server: "Any authoritative server configured to be the 721 source of zone transfer for one or more [secondary] servers" 722 (Quoted from [RFC1996], Section 2.1) or, more specifically, "an 723 authoritative server configured to be the source of AXFR or IXFR 724 data for one or more [secondary] servers" (Quoted from [RFC2136]). 725 Although early DNS RFCs such as [RFC1996] referred to this as a 726 "master", the current common usage has shifted to "primary". 727 Primary servers are also discussed in [RFC1034]. 729 Master server: See primary server. 731 Primary master: "The primary master is named in the zone's SOA MNAME 732 field and optionally by an NS RR". (Quoted from [RFC1996], 733 Section 2.1). [RFC2136] defines "primary master" as "Master 734 server at the root of the AXFR/IXFR dependency graph. The primary 735 master is named in the zone's SOA MNAME field and optionally by an 736 NS RR. There is by definition only one primary master server per 737 zone." The idea of a primary master is only used by [RFC2136], 738 and is considered archaic in other parts of the DNS. 740 Stealth server: This is "like a slave server except not listed in an 741 NS RR for the zone." (Quoted from [RFC1996], Section 2.1) 743 Hidden master: A stealth server that is a primary server for zone 744 transfers. "In this arrangement, the master name server that 745 processes the updates is unavailable to general hosts on the 746 Internet; it is not listed in the NS RRset." (Quoted from 747 [RFC6781], Section 3.4.3). An earlier RFC, [RFC4641], said that 748 the hidden master's name "appears in the SOA RRs MNAME field", 749 although in some setups, the name does not appear at all in the 750 public DNS. A hidden master can also be a secondary server 751 itself. 753 Forwarding: The process of one server sending a DNS query with the 754 RD bit set to 1 to another server to resolve that query. 755 Forwarding is a function of a DNS resolver; it is different than 756 simply blindly relaying queries. 758 [RFC5625] does not give a specific definition for forwarding, but 759 describes in detail what features a system that forwards need to 760 support. Systems that forward are sometimes called "DNS proxies", 761 but that term has not yet been defined (even in [RFC5625]). 763 Forwarder: Section 1 of [RFC2308] describes a forwarder as "a 764 nameserver used to resolve queries instead of directly using the 765 authoritative nameserver chain". [RFC2308] further says "The 766 forwarder typically either has better access to the internet, or 767 maintains a bigger cache which may be shared amongst many 768 resolvers." That definition appears to suggest that forwarders 769 normally only query authoritative servers. In current use, 770 however, forwarders often stand between stub resolvers and 771 recursive servers. [RFC2308] is silent on whether a forwarder is 772 iterative-only or can be a full-service resolver. 774 Policy-implementing resolver: A resolver acting in recursive mode 775 that changes some of the answers that it returns based on policy 776 criteria, such as to prevent access to malware sites or 777 objectionable content. In general, a stub resolver has no idea 778 whether upstream resolvers implement such policy or, if they do, 779 the exact policy about what changes will be made. In some cases, 780 the user of the stub resolver has selected the policy-implementing 781 resolver with the explicit intention of using it to implement the 782 policies. In other cases, policies are imposed without the user 783 of the stub resolver being informed. 785 Open resolver: A full-service resolver that accepts and processes 786 queries from any (or nearly any) stub resolver. This is sometimes 787 also called a "public resolver", although the term "public 788 resolver" is used more with open resolvers that are meant to be 789 open, as compared to the vast majority of open resolvers that are 790 probably misconfigured to be open. Open resolvers are discussed 791 in [RFC5358] 793 View: A configuration for a DNS server that allows it to provide 794 different answers depending on attributes of the query. 795 Typically, views differ by the source IP address of a query, but 796 can also be based on the destination IP address, the type of query 797 (such as AXFR), whether it is recursive, and so on. Views are 798 often used to provide more names or different addresses to queries 799 from "inside" a protected network than to those "outside" that 800 network. Views are not a standardized part of the DNS, but they 801 are widely implemented in server software. 803 Passive DNS: A mechanism to collect DNS data by storing DNS 804 transactions from name servers. Some of these systems also 805 collect the DNS queries associated with the responses. Passive 806 DNS databases can be used to answer historical questions about DNS 807 zones such as which answers were witnessed at what times in the 808 past. Passive DNS databases allow searching of the stored records 809 on keys other than just the name and type, such as "find all names 810 which have A records of a particular value". 812 Anycast: "The practice of making a particular service address 813 available in multiple, discrete, autonomous locations, such that 814 datagrams sent are routed to one of several available locations." 815 (Quoted from [RFC4786], Section 2) 817 Instance: "When anycast routing is used to allow more than one 818 server to have the same IP address, each one of those servers is 819 commonly referred to as an 'instance'." "An instance of a server, 820 such as a root server, is often referred to as an 'Anycast 821 instance'." (Quoted from [RSSAC026]) 823 Split DNS: "Where a corporate network serves up partly or completely 824 different DNS inside and outside its firewall. There are many 825 possible variants on this; the basic point is that the 826 correspondence between a given FQDN (fully qualified domain name) 827 and a given IPv4 address is no longer universal and stable over 828 long periods." (Quoted from [RFC2775], Section 3.8) 830 6. Zones 832 This section defines terms that are used when discussing zones that 833 are being served or retrieved. 835 Zone: "Authoritative information is organized into units called 836 'zones', and these zones can be automatically distributed to the 837 name servers which provide redundant service for the data in a 838 zone." (Quoted from [RFC1034], Section 2.4) 840 Child: "The entity on record that has the delegation of the domain 841 from the Parent." (Quoted from [RFC7344], Section 1.1) 843 Parent: "The domain in which the Child is registered." (Quoted from 844 [RFC7344], Section 1.1) Earlier, "parent name server" was defined 845 in [RFC0882] as "the name server that has authority over the place 846 in the domain name space that will hold the new domain". (Note 847 that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].) 848 [RFC0819] also has some description of the relationship between 849 parents and children. 851 Origin: 853 (a) "The domain name that appears at the top of a zone (just below 854 the cut that separates the zone from its parent). The name of the 855 zone is the same as the name of the domain at the zone's origin." 856 (Quoted from [RFC2181], Section 6.) These days, this sense of 857 "origin" and "apex" (defined below) are often used 858 interchangeably. 860 (b) The domain name within which a given relative domain name 861 appears in zone files. Generally seen in the context of 862 "$ORIGIN", which is a control entry defined in [RFC1035], 863 Section 5.1, as part of the master file format. For example, if 864 the $ORIGIN is set to "example.org.", then a master file line for 865 "www" is in fact an entry for "www.example.org.". 867 Apex: The point in the tree at an owner of an SOA and corresponding 868 authoritative NS RRset. This is also called the "zone apex". 869 [RFC4033] defines it as "the name at the child's side of a zone 870 cut". The "apex" can usefully be thought of as a data-theoretic 871 description of a tree structure, and "origin" is the name of the 872 same concept when it is implemented in zone files. The 873 distinction is not always maintained in use, however, and one can 874 find uses that conflict subtly with this definition. [RFC1034] 875 uses the term "top node of the zone" as a synonym of "apex", but 876 that term is not widely used. These days, the first sense of 877 "origin" (above) and "apex" are often used interchangeably. 879 Zone cut: The delimitation point between two zones where the origin 880 of one of the zones is the child of the other zone. 882 "Zones are delimited by 'zone cuts'. Each zone cut separates a 883 'child' zone (below the cut) from a 'parent' zone (above the cut). 884 (Quoted from [RFC2181], Section 6; note that this is barely an 885 ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as 886 'zone cut'." 888 Delegation: The process by which a separate zone is created in the 889 name space beneath the apex of a given domain. Delegation happens 890 when an NS RRset is added in the parent zone for the child origin. 891 Delegation inherently happens at a zone cut. The term is also 892 commonly a noun: the new zone that is created by the act of 893 delegating. 895 Glue records: "[Resource records] which are not part of the 896 authoritative data [of the zone], and are address resource records 897 for the [name servers in subzones]. These RRs are only necessary 898 if the name server's name is 'below' the cut, and are only used as 899 part of a referral response." Without glue "we could be faced 900 with the situation where the NS RRs tell us that in order to learn 901 a name server's address, we should contact the server using the 902 address we wish to learn." (Definition from [RFC1034], 903 Section 4.2.1) 905 A later definition is that glue "includes any record in a zone 906 file that is not properly part of that zone, including nameserver 907 records of delegated sub-zones (NS records), address records that 908 accompany those NS records (A, AAAA, etc), and any other stray 909 data that might appear" ([RFC2181], Section 5.4.1). Although glue 910 is sometimes used today with this wider definition in mind, the 911 context surrounding the [RFC2181] definition suggests it is 912 intended to apply to the use of glue within the document itself 913 and not necessarily beyond. 915 In-bailiwick: An adjective to describe a name server whose name is 916 either subordinate to or (rarely) the same as the zone origin. 917 In-bailiwick name servers may have glue records in their parent 918 zone (using the first of the definitions of "glue records" in the 919 definition above). "In-bailiwick" names are divided into two type 920 of name server names: "in-domain" names and "sibling domain" 921 names: 923 * In-domain -- an adjective to describe a name server whose name 924 is either subordinate to or (rarely) the same as the owner name 925 of the NS resource records. An in-domain name server name MUST 926 have glue records or name resolution fails. For example, a 927 delegation for "child.example.com" may have "in-domain" name 928 server name "ns.child.example.com". 930 * Sibling domain: -- a name server's name that is either 931 subordinate to or (rarely) the same as the zone origin and not 932 subordinate to or the same as the owner name of the NS resource 933 records. Glue records for sibling domains are allowed, but not 934 necessary. For example, a delegation for "child.example.com" 935 in "example.com" zone may have "sibling" name server name 936 "ns.another.example.com". 938 Out-of-bailiwick: The antonym of in-bailiwick. An adjective to 939 describe a name server whose name is not subordinate to or the 940 same as the zone origin. Glue records for out-of-bailiwick name 941 servers are useless. 943 Authoritative data: "All of the RRs attached to all of the nodes 944 from the top node of the zone down to leaf nodes or nodes above 945 cuts around the bottom edge of the zone." (Quoted from [RFC1034], 946 Section 4.2.1) It is noted that this definition might 947 inadvertently also include any NS records that appear in the zone, 948 even those that might not truly be authoritative because there are 949 identical NS RRs below the zone cut. This reveals the ambiguity 950 in the notion of authoritative data, because the parent-side NS 951 records authoritatively indicate the delegation, even though they 952 are not themselves authoritative data. 954 Root zone: The zone of a DNS-based tree whose apex is the zero- 955 length label. Also sometimes called "the DNS root". 957 Empty non-terminals (ENT): "Domain names that own no resource 958 records but have subdomains that do." (Quoted from [RFC4592], 959 Section 2.2.2.) A typical example is in SRV records: in the name 960 "_sip._tcp.example.com", it is likely that "_tcp.example.com" has 961 no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV 962 RRset. 964 Delegation-centric zone: A zone that consists mostly of delegations 965 to child zones. This term is used in contrast to a zone that 966 might have some delegations to child zones, but also has many data 967 resource records for the zone itself and/or for child zones. The 968 term is used in [RFC4956] and [RFC5155], but is not defined there. 970 Wildcard: [RFC1034] defined "wildcard", but in a way that turned out 971 to be confusing to implementers. Special treatment is given to 972 RRs with owner names starting with the label "*". "Such RRs are 973 called 'wildcards'. Wildcard RRs can be thought of as 974 instructions for synthesizing RRs." (Quoted from [RFC1034], 975 Section 4.3.3) For an extended discussion of wildcards, including 976 clearer definitions, see [RFC4592]. 978 Asterisk label: "The first octet is the normal label type and length 979 for a 1-octet-long label, and the second octet is the ASCII 980 representation for the '*' character. A descriptive name of a 981 label equaling that value is an 'asterisk label'." (Quoted from 982 [RFC4592], Section 2.1.1) 984 Wildcard domain name: "A 'wildcard domain name' is defined by having 985 its initial (i.e., leftmost or least significant) label be 986 asterisk label." (Quoted from [RFC4592], Section 2.1.1) 988 Closest encloser: "The longest existing ancestor of a name." 989 (Quoted from [RFC5155], Section 1.3) An earlier definition is "The 990 node in the zone's tree of existing domain names that has the most 991 labels matching the query name (consecutively, counting from the 992 root label downward). Each match is a 'label match' and the order 993 of the labels is the same." (Quoted from [RFC4592], 994 Section 3.3.1) 996 Closest provable encloser: "The longest ancestor of a name that can 997 be proven to exist. Note that this is only different from the 998 closest encloser in an Opt-Out zone." (Quoted from [RFC5155], 999 Section 1.3) 1001 Next closer name: "The name one label longer than the closest 1002 provable encloser of a name." (Quoted from [RFC5155], 1003 Section 1.3) 1005 Source of Synthesis: "The source of synthesis is defined in the 1006 context of a query process as that wildcard domain name 1007 immediately descending from the closest encloser, provided that 1008 this wildcard domain name exists. 'Immediately descending' means 1009 that the source of synthesis has a name of the form: .." (Quoted from [RFC4592], 1011 Section 3.3.1) 1013 Occluded name: "The addition of a delegation point via dynamic 1014 update will render all subordinate domain names to be in a limbo, 1015 still part of the zone, but not available to the lookup process. 1016 The addition of a DNAME resource record has the same impact. The 1017 subordinate names are said to be 'occluded'." (Quoted from 1018 [RFC5936], Section 3.5) 1020 Fast flux DNS: This "occurs when a domain is found in DNS using A 1021 records to multiple IP addresses, each of which has a very short 1022 Time-to-Live (TTL) value associated with it. This means that the 1023 domain resolves to varying IP addresses over a short period of 1024 time." (Quoted from [RFC6561], Section 1.1.5, with typo 1025 corrected) It is often used to deliver malware. Because the 1026 addresses change so rapidly, it is difficult to ascertain all the 1027 hosts. It should be noted that the technique also works with AAAA 1028 records, but such use is not frequently observed on the Internet 1029 as of this writing. 1031 Reverse DNS, reverse lookup: "The process of mapping an address to a 1032 name is generally known as a 'reverse lookup', and the IN- 1033 ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse 1034 DNS'." (Quoted from [RFC5855], Section 1) 1036 Forward lookup: "Hostname-to-address translation". (Quoted from 1037 [RFC2133], Section 6) 1039 arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain 1040 was originally established as part of the initial deployment of 1041 the DNS, to provide a transition mechanism from the Host Tables 1042 that were common in the ARPANET, as well as a home for the IPv4 1043 reverse mapping domain. During 2000, the abbreviation was 1044 redesignated to 'Address and Routing Parameter Area' in the hope 1045 of reducing confusion with the earlier network name." (Quoted 1046 from [RFC3172], Section 2.) 1048 Infrastructure domain: A domain whose "role is to support the 1049 operating infrastructure of the Internet". (Quoted from 1050 [RFC3172], Section 2.) 1052 Service name: "Service names are the unique key in the Service Name 1053 and Transport Protocol Port Number registry. This unique symbolic 1054 name for a service may also be used for other purposes, such as in 1055 DNS SRV records." (Quoted from [RFC6335], Section 5.) 1057 7. Registration Model 1059 Registry: The administrative operation of a zone that allows 1060 registration of names within that zone. People often use this 1061 term to refer only to those organizations that perform 1062 registration in large delegation-centric zones (such as TLDs); but 1063 formally, whoever decides what data goes into a zone is the 1064 registry for that zone. This definition of "registry" is from a 1065 DNS point of view; for some zones, the policies that determine 1066 what can go in the zone are decided by superior zones and not the 1067 registry operator. 1069 Registrant: An individual or organization on whose behalf a name in 1070 a zone is registered by the registry. In many zones, the registry 1071 and the registrant may be the same entity, but in TLDs they often 1072 are not. 1074 Registrar: A service provider that acts as a go-between for 1075 registrants and registries. Not all registrations require a 1076 registrar, though it is common to have registrars involved in 1077 registrations in TLDs. 1079 EPP: The Extensible Provisioning Protocol (EPP), which is commonly 1080 used for communication of registration information between 1081 registries and registrars. EPP is defined in [RFC5730]. 1083 WHOIS: A protocol specified in [RFC3912], often used for querying 1084 registry databases. WHOIS data is frequently used to associate 1085 registration data (such as zone management contacts) with domain 1086 names. The term "WHOIS data" is often used as a synonym for the 1087 registry database, even though that database may be served by 1088 different protocols, particularly RDAP. The WHOIS protocol is 1089 also used with IP address registry data. 1091 RDAP: The Registration Data Access Protocol, defined in [RFC7480], 1092 [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The 1093 RDAP protocol and data format are meant as a replacement for 1094 WHOIS. 1096 DNS operator: An entity responsible for running DNS servers. For a 1097 zone's authoritative servers, the registrant may act as their own 1098 DNS operator, or their registrar may do it on their behalf, or 1099 they may use a third-party operator. For some zones, the registry 1100 function is performed by the DNS operator plus other entities who 1101 decide about the allowed contents of the zone. 1103 8. General DNSSEC 1105 Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and 1106 [RFC5155]. The terms that have caused confusion in the DNS community 1107 are highlighted here. 1109 DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in 1110 some RFCs, have not been formally defined. However, Section 2 of 1111 [RFC4033] defines many types of resolvers and validators, 1112 including "non-validating security-aware stub resolver", "non- 1113 validating stub resolver", "security-aware name server", 1114 "security-aware recursive name server", "security-aware resolver", 1115 "security-aware stub resolver", and "security-oblivious 1116 'anything'". (Note that the term "validating resolver", which is 1117 used in some places in DNSSEC-related documents, is also not 1118 defined in those RFCs, but is defined below.) 1120 Signed zone: "A zone whose RRsets are signed and that contains 1121 properly constructed DNSKEY, Resource Record Signature (RRSIG), 1122 Next Secure (NSEC), and (optionally) DS records." (Quoted from 1123 [RFC4033], Section 2.) It has been noted in other contexts that 1124 the zone itself is not really signed, but all the relevant RRsets 1125 in the zone are signed. Nevertheless, if a zone that should be 1126 signed contains any RRsets that are not signed (or opted out), 1127 those RRsets will be treated as bogus, so the whole zone needs to 1128 be handled in some way. 1130 It should also be noted that, since the publication of [RFC6840], 1131 NSEC records are no longer required for signed zones: a signed 1132 zone might include NSEC3 records instead. [RFC7129] provides 1133 additional background commentary and some context for the NSEC and 1134 NSEC3 mechanisms used by DNSSEC to provide authenticated denial- 1135 of-existence responses. NSEC and NSEC3 are described below. 1137 Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that 1138 is not signed". Section 2 of [RFC4035] defines this as "A zone 1139 that does not include these records [properly constructed DNSKEY, 1140 Resource Record Signature (RRSIG), Next Secure (NSEC), and 1141 (optionally) DS records] according to the rules in this section". 1142 There is an important note at the end of Section 5.2 of [RFC4035] 1143 that defines an additional situation in which a zone is considered 1144 unsigned: "If the resolver does not support any of the algorithms 1145 listed in an authenticated DS RRset, then the resolver will not be 1146 able to verify the authentication path to the child zone. In this 1147 case, the resolver SHOULD treat the child zone as if it were 1148 unsigned." 1150 NSEC: "The NSEC record allows a security-aware resolver to 1151 authenticate a negative reply for either name or type non- 1152 existence with the same mechanisms used to authenticate other DNS 1153 replies." (Quoted from [RFC4033], Section 3.2.) In short, an 1154 NSEC record provides authenticated denial of existence. 1156 "The NSEC resource record lists two separate things: the next 1157 owner name (in the canonical ordering of the zone) that contains 1158 authoritative data or a delegation point NS RRset, and the set of 1159 RR types present at the NSEC RR's owner name." (Quoted from 1160 Section 4 of RFC 4034) 1162 NSEC3: Like the NSEC record, the NSEC3 record also provides 1163 authenticated denial of existence; however, NSEC3 records mitigate 1164 against zone enumeration and support Opt-Out. NSEC resource 1165 records require associated NSEC3PARAM resource records. NSEC3 and 1166 NSEC3PARAM resource records are defined in [RFC5155]. 1168 Note that [RFC6840] says that [RFC5155] "is now considered part of 1169 the DNS Security Document Family as described by Section 10 of 1170 [RFC4033]". This means that some of the definitions from earlier 1171 RFCs that only talk about NSEC records should probably be 1172 considered to be talking about both NSEC and NSEC3. 1174 Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover 1175 unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1.) 1176 Opt-out tackles the high costs of securing a delegation to an 1177 insecure zone. When using Opt-Out, names that are an insecure 1178 delegation (and empty non-terminals that are only derived from 1179 insecure delegations) don't require an NSEC3 record or its 1180 corresponding RRSIG records. Opt-Out NSEC3 records are not able 1181 to prove or deny the existence of the insecure delegations. 1182 (Adapted from [RFC7129], Section 5.1) 1184 Insecure delegation: "A signed name containing a delegation (NS 1185 RRset), but lacking a DS RRset, signifying a delegation to an 1186 unsigned subzone." (Quoted from [RFC4956], Section 2.) 1188 Zone enumeration: "The practice of discovering the full content of a 1189 zone via successive queries." (Quoted from [RFC5155], 1190 Section 1.3.) This is also sometimes called "zone walking". Zone 1191 enumeration is different from zone content guessing where the 1192 guesser uses a large dictionary of possible labels and sends 1193 successive queries for them, or matches the contents of NSEC3 1194 records against such a dictionary. 1196 Validation: Validation, in the context of DNSSEC, refers to the 1197 following: 1199 * Checking the validity of DNSSEC signatures 1201 * Checking the validity of DNS responses, such as those including 1202 authenticated denial of existence 1204 * Building an authentication chain from a trust anchor to a DNS 1205 response or individual DNS RRsets in a response 1207 The first two definitions above consider only the validity of 1208 individual DNSSEC components such as the RRSIG validity or NSEC 1209 proof validity. The third definition considers the components of 1210 the entire DNSSEC authentication chain, and thus requires 1211 "configured knowledge of at least one authenticated DNSKEY or DS 1212 RR" (as described in [RFC4035], Section 5). 1214 [RFC4033], Section 2, says that a "Validating Security-Aware Stub 1215 Resolver... performs signature validation" and uses a trust anchor 1216 "as a starting point for building the authentication chain to a 1217 signed DNS response", and thus uses the first and third 1218 definitions above. The process of validating an RRSIG resource 1219 record is described in [RFC4035], Section 5.3. 1221 [RFC5155] refers to validating responses throughout the document, 1222 in the context of hashed authenticated denial of existence; this 1223 uses the second definition above. 1225 The term "authentication" is used interchangeably with 1226 "validation", in the sense of the third definition above. 1227 [RFC4033], Section 2, describes the chain linking trust anchor to 1228 DNS data as the "authentication chain". A response is considered 1229 to be authentic if "all RRsets in the Answer and Authority 1230 sections of the response [are considered] to be authentic" 1231 ([RFC4035]). DNS data or responses deemed to be authentic or 1232 validated have a security status of "secure" ([RFC4035], 1233 Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys 1234 and data is a matter of local policy, which may extend or even 1235 override the [DNSSEC] protocol extensions" ([RFC4033], 1236 Section 3.1). 1238 The term "verification", when used, is usually synonym for 1239 "validation". 1241 Validating resolver: A security-aware recursive name server, 1242 security-aware resolver, or security-aware stub resolver that is 1243 applying at least one of the definitions of validation (above), as 1244 appropriate to the resolution context. For the same reason that 1245 the generic term "resolver" is sometimes ambiguous and needs to be 1246 evaluated in context (see Section 5), "validating resolver" is a 1247 context-sensitive term. 1249 Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY 1250 RRset in a zone."(Quoted from [RFC6781], Section 3.1) 1252 Zone signing key (ZSK): "DNSSEC keys that can be used to sign all 1253 the RRsets in a zone that require signatures, other than the apex 1254 DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Note that the 1255 roles KSK and ZSK are not mutually exclusive: a single key can be 1256 both KSK and ZSK at the same time. Also note that a ZSK is 1257 sometimes used to sign the apex DNSKEY RRset. 1259 Combined signing key (CSK): "In cases where the differentiation 1260 between the KSK and ZSK is not made, i.e., where keys have the 1261 role of both KSK and ZSK, we talk about a Single-Type Signing 1262 Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes 1263 called a "combined signing key" or CSK. It is operational 1264 practice, not protocol, that determines whether a particular key 1265 is a ZSK, a KSK, or a CSK. 1267 Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be 1268 used to distinguish between keys that are intended to be used as 1269 the secure entry point into the zone when building chains of 1270 trust, i.e., they are (to be) pointed to by parental DS RRs or 1271 configured as a trust anchor. Therefore, it is suggested that the 1272 SEP flag be set on keys that are used as KSKs and not on keys that 1273 are used as ZSKs, while in those cases where a distinction between 1274 a KSK and ZSK is not made (i.e., for a Single-Type Signing 1275 Scheme), it is suggested that the SEP flag be set on all keys." 1276 (Quoted from [RFC6781], Section 3.2.3.) Note that the SEP flag is 1277 only a hint, and its presence or absence may not be used to 1278 disqualify a given DNSKEY RR from use as a KSK or ZSK during 1279 validation. 1281 The original defintion of SEPs was in [RFC3757]. That definition 1282 clearly indicated that the SEP was a key, not just a bit in the 1283 key. The abstract of [RFC3757] says: "With the Delegation Signer 1284 (DS) resource record (RR), the concept of a public key acting as a 1285 secure entry point (SEP) has been introduced. During exchanges of 1286 public keys with the parent there is a need to differentiate SEP 1287 keys from other public keys in the Domain Name System KEY (DNSKEY) 1288 resource record set. A flag bit in the DNSKEY RR is defined to 1289 indicate that DNSKEY is to be used as a SEP." That definition of 1290 the SEP as a key was made obsolete by [RFC4034], and the 1291 definition from [RFC6781] is consistent with [RFC4034]. 1293 Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 1294 A validating security-aware resolver uses this public key or hash 1295 as a starting point for building the authentication chain to a 1296 signed DNS response." (Quoted from [RFC4033], Section 2) 1298 DNSSEC Policy (DP): A statement that "sets forth the security 1299 requirements and standards to be implemented for a DNSSEC-signed 1300 zone." (Quoted from [RFC6841], Section 2) 1302 DNSSEC Practice Statement (DPS): "A practices disclosure document 1303 that may support and be a supplemental document to the DNSSEC 1304 Policy (if such exists), and it states how the management of a 1305 given zone implements procedures and controls at a high level." 1306 (Quoted from [RFC6841], Section 2) 1308 Hardware security module (HSM): A specialized piece of hardware that 1309 is used to create keys for signatures and to sign messages. In 1310 DNSSEC, HSMs are often used to hold the private keys for KSKs and 1311 ZSKs and to create the RRSIG records at periodic intervals. 1313 Signing software: Authoritative DNS servers that supports DNSSEC 1314 often contains software that facilitates the creation and 1315 maintenance of DNSSEC signatures in zones. There is also stand- 1316 alone software that can be used to sign a zone regardless of 1317 whether the authoritative server itself supports signing. 1318 Sometimes signing software can support particular HSMs as part of 1319 the signing process. 1321 9. DNSSEC States 1323 A validating resolver can determine that a response is in one of four 1324 states: secure, insecure, bogus, or indeterminate. These states are 1325 defined in [RFC4033] and [RFC4035], although the two definitions 1326 differ a bit. This document makes no effort to reconcile the two 1327 definitions, and takes no position as to whether they need to be 1328 reconciled. 1330 Section 5 of [RFC4033] says: 1332 A validating resolver can determine the following 4 states: 1334 Secure: The validating resolver has a trust anchor, has a chain 1335 of trust, and is able to verify all the signatures in the 1336 response. 1338 Insecure: The validating resolver has a trust anchor, a chain 1339 of trust, and, at some delegation point, signed proof of the 1340 non-existence of a DS record. This indicates that subsequent 1341 branches in the tree are provably insecure. A validating 1342 resolver may have a local policy to mark parts of the domain 1343 space as insecure. 1345 Bogus: The validating resolver has a trust anchor and a secure 1346 delegation indicating that subsidiary data is signed, but 1347 the response fails to validate for some reason: missing 1348 signatures, expired signatures, signatures with unsupported 1349 algorithms, data missing that the relevant NSEC RR says 1350 should be present, and so forth. 1352 Indeterminate: There is no trust anchor that would indicate that a 1353 specific portion of the tree is secure. This is the default 1354 operation mode. 1356 Section 4.3 of [RFC4035] says: 1358 A security-aware resolver must be able to distinguish between four 1359 cases: 1361 Secure: An RRset for which the resolver is able to build a chain 1362 of signed DNSKEY and DS RRs from a trusted security anchor to 1363 the RRset. In this case, the RRset should be signed and is 1364 subject to signature validation, as described above. 1366 Insecure: An RRset for which the resolver knows that it has no 1367 chain of signed DNSKEY and DS RRs from any trusted starting 1368 point to the RRset. This can occur when the target RRset lies 1369 in an unsigned zone or in a descendent [sic] of an unsigned 1370 zone. In this case, the RRset may or may not be signed, but 1371 the resolver will not be able to verify the signature. 1373 Bogus: An RRset for which the resolver believes that it ought to 1374 be able to establish a chain of trust but for which it is 1375 unable to do so, either due to signatures that for some reason 1376 fail to validate or due to missing data that the relevant 1377 DNSSEC RRs indicate should be present. This case may indicate 1378 an attack but may also indicate a configuration error or some 1379 form of data corruption. 1381 Indeterminate: An RRset for which the resolver is not able to 1382 determine whether the RRset should be signed, as the resolver 1383 is not able to obtain the necessary DNSSEC RRs. This can occur 1384 when the security-aware resolver is not able to contact 1385 security-aware name servers for the relevant zones. 1387 10. Security Considerations 1389 These definitions do not change any security considerations for the 1390 DNS. 1392 11. IANA Considerations 1394 None. 1396 12. References 1398 12.1. Normative References 1400 [IANA_RootFiles] 1401 Internet Assigned Numbers Authority, "IANA Root Files", 1402 2016, . 1404 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1405 RFC 882, DOI 10.17487/RFC0882, November 1983, 1406 . 1408 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1409 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1410 . 1412 [RFC1035] Mockapetris, P., "Domain names - implementation and 1413 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1414 November 1987, . 1416 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1417 Application and Support", STD 3, RFC 1123, 1418 DOI 10.17487/RFC1123, October 1989, . 1421 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1422 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1423 August 1996, . 1425 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1426 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1427 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1428 . 1430 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1431 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1432 . 1434 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 1435 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 1436 DOI 10.17487/RFC2182, July 1997, . 1439 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1440 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1441 . 1443 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1444 Rose, "DNS Security Introduction and Requirements", 1445 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1446 . 1448 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1449 Rose, "Resource Records for the DNS Security Extensions", 1450 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1451 . 1453 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1454 Rose, "Protocol Modifications for the DNS Security 1455 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1456 . 1458 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 1459 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 1460 . 1462 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1463 Security (DNSSEC) Hashed Authenticated Denial of 1464 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1465 . 1467 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive 1468 Nameservers in Reflector Attacks", BCP 140, RFC 5358, 1469 DOI 10.17487/RFC5358, October 2008, . 1472 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1473 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1474 . 1476 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 1477 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855, 1478 May 2010, . 1480 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 1481 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 1482 . 1484 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan, 1485 "Recommendations for the Remediation of Bots in ISP 1486 Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012, 1487 . 1489 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1490 Operational Practices, Version 2", RFC 6781, 1491 DOI 10.17487/RFC6781, December 2012, . 1494 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 1495 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 1496 DOI 10.17487/RFC6840, February 2013, . 1499 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 1500 Framework for DNSSEC Policies and DNSSEC Practice 1501 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013, 1502 . 1504 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1505 for DNS (EDNS(0))", STD 75, RFC 6891, 1506 DOI 10.17487/RFC6891, April 2013, . 1509 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 1510 DNSSEC Delegation Trust Maintenance", RFC 7344, 1511 DOI 10.17487/RFC7344, September 2014, . 1514 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1515 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1516 2015, . 1518 12.2. Informative References 1520 [IANA_Resource_Registry] 1521 Internet Assigned Numbers Authority, "Resource Record (RR) 1522 TYPEs", 2017, 1523 . 1525 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for 1526 Internet User Applications", RFC 819, 1527 DOI 10.17487/RFC0819, August 1982, . 1530 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1531 host table specification", RFC 952, DOI 10.17487/RFC0952, 1532 October 1985, . 1534 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1535 DOI 10.17487/RFC1995, August 1996, . 1538 [RFC2133] Gilligan, R., Thomson, S., Bound, J., and W. Stevens, 1539 "Basic Socket Interface Extensions for IPv6", RFC 2133, 1540 DOI 10.17487/RFC2133, April 1997, . 1543 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1544 DOI 10.17487/RFC2775, February 2000, . 1547 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 1548 Requirements for the Address and Routing Parameter Area 1549 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 1550 September 2001, . 1552 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, 1553 DOI 10.17487/RFC3425, November 2002, . 1556 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 1557 System KEY (DNSKEY) Resource Record (RR) Secure Entry 1558 Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April 1559 2004, . 1561 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, 1562 DOI 10.17487/RFC3912, September 2004, . 1565 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1566 RFC 4641, DOI 10.17487/RFC4641, September 2006, 1567 . 1569 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution 1570 Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697, 1571 October 2006, . 1573 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1574 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1575 December 2006, . 1577 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security 1578 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July 1579 2007, . 1581 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 1582 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 1583 . 1585 [RFC5890] Klensin, J., "Internationalized Domain Names for 1586 Applications (IDNA): Definitions and Document Framework", 1587 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1588 . 1590 [RFC5891] Klensin, J., "Internationalized Domain Names in 1591 Applications (IDNA): Protocol", RFC 5891, 1592 DOI 10.17487/RFC5891, August 2010, . 1595 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 1596 Internationalized Domain Names for Applications (IDNA)", 1597 RFC 5892, DOI 10.17487/RFC5892, August 2010, 1598 . 1600 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 1601 for Internationalized Domain Names for Applications 1602 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 1603 . 1605 [RFC5894] Klensin, J., "Internationalized Domain Names for 1606 Applications (IDNA): Background, Explanation, and 1607 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 1608 . 1610 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 1611 Encodings for Internationalized Domain Names", RFC 6055, 1612 DOI 10.17487/RFC6055, February 2011, . 1615 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1616 DOI 10.17487/RFC6265, April 2011, . 1619 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 1620 RFC 6303, DOI 10.17487/RFC6303, July 2011, 1621 . 1623 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1624 Cheshire, "Internet Assigned Numbers Authority (IANA) 1625 Procedures for the Management of the Service Name and 1626 Transport Protocol Port Number Registry", BCP 165, 1627 RFC 6335, DOI 10.17487/RFC6335, August 2011, 1628 . 1630 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 1631 Internationalization in the IETF", BCP 166, RFC 6365, 1632 DOI 10.17487/RFC6365, September 2011, . 1635 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1636 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 1637 February 2014, . 1639 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the 1640 Registration Data Access Protocol (RDAP)", RFC 7480, 1641 DOI 10.17487/RFC7480, March 2015, . 1644 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 1645 Registration Data Access Protocol (RDAP)", RFC 7481, 1646 DOI 10.17487/RFC7481, March 2015, . 1649 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access 1650 Protocol (RDAP) Query Format", RFC 7482, 1651 DOI 10.17487/RFC7482, March 2015, . 1654 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the 1655 Registration Data Access Protocol (RDAP)", RFC 7483, 1656 DOI 10.17487/RFC7483, March 2015, . 1659 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data 1660 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 1661 2015, . 1663 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin, 1664 "Inventory and Analysis of WHOIS Registration Objects", 1665 RFC 7485, DOI 10.17487/RFC7485, March 2015, 1666 . 1668 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS 1669 Resolver with Priming Queries", BCP 209, RFC 8109, 1670 DOI 10.17487/RFC8109, March 2017, . 1673 [RSSAC026] 1674 Root Server System Advisory Committee (RSSAC), "RSSAC 1675 Lexicon", 2017, 1676 . 1679 Appendix A. Definitions Updated by this Document 1681 The following definitions from RFCs are updated by this document: 1683 o Forwarder in [RFC2308] 1685 o Secure Entry Point (SEP) in [RFC3757]; note, however, that this 1686 RFC is already obsolete 1688 Appendix B. Definitions First Defined in this Document 1690 The following definitions are first defined in this document: 1692 o "Alias" in Section 2 1694 o "Apex" in Section 6 1696 o "arpa" in Section 6 1698 o "Class independent" in Section 4 1700 o "Delegation-centric zone" in Section 6 1702 o "Delegation" in Section 6 1704 o "DNS operator" in Section 7 1706 o "DNSSEC-aware" in Section 8 1708 o "DNSSEC-unaware" in Section 8 1710 o "Forwarding" in Section 5 1712 o "Full resolver" in Section 5 1714 o "Fully qualified domain name" in Section 2 1716 o "Global DNS" in Section 2 1718 o "Hardware Security Module (HSM)" in Section 8 1720 o "Host name" in Section 2 1722 o "IDN" in Section 2 1724 o "In-bailiwick" in Section 6 1726 o "Label" in Section 2 1728 o "Locally served DNS zone" in Section 2 1730 o "Naming system" in Section 2 1732 o "Negative response" in Section 3 1734 o "Open resolver" in Section 5 1735 o "Out-of-bailiwick" in Section 6 1737 o "Passive DNS" in Section 5 1739 o "Policy-implementing resolver" in Section 5 1741 o "Presentation format" in Section 4 1743 o "Priming" in Section 5 1745 o "Private DNS" in Section 2 1747 o "Recursive resolver" in Section 5 1749 o "Referrals" in Section 3 1751 o "Registrant" in Section 7 1753 o "Registrar" in Section 7 1755 o "Registry" in Section 7 1757 o "Root zone" in Section 6 1759 o "Secure Entry Point (SEP)" in Section 8 1761 o "Signing software" in Section 8 1763 o "Stub resolver" in Section 5 1765 o "TLD" in Section 2 1767 o "Validating resolver" in Section 8 1769 o "Validation" in Section 8 1771 o "View" in Section 5 1773 o "Zone transfer" in Section 5 1775 Index 1777 A 1778 Alias 8 1779 Anycast 17 1780 Apex 19 1781 Asterisk label 21 1782 Authoritative data 20 1783 Authoritative server 15 1784 Authoritative-only server 15 1785 arpa: Address and Routing Parameter Area Domain 22 1787 C 1788 CNAME 8 1789 Canonical name 8 1790 Child 18 1791 Class independent 13 1792 Closest encloser 21 1793 Closest provable encloser 21 1794 Combined signing key (CSK) 27 1796 D 1797 DNS operator 23 1798 DNSSEC Policy (DP) 28 1799 DNSSEC Practice Statement (DPS) 28 1800 DNSSEC-aware and DNSSEC-unaware 24 1801 Delegation 19 1802 Delegation-centric zone 21 1803 Domain name 4 1805 E 1806 EDNS 11 1807 EPP 23 1808 Empty non-terminals (ENT) 20 1810 F 1811 Fast flux DNS 22 1812 Forward lookup 22 1813 Forwarder 16 1814 Forwarding 16 1815 Full resolver 14 1816 Full-service resolver 14 1817 Fully qualified domain name (FQDN) 7 1819 G 1820 Global DNS 4 1821 Glue records 19 1823 H 1824 Hardware security module (HSM) 28 1825 Hidden master 16 1826 Host name 7 1828 I 1829 IDN 8 1830 In-bailiwick 20 1831 Infrastructure domain 22 1832 Insecure delegation 25 1833 Instance 18 1834 Iterative mode 14 1836 K 1837 Key signing key (KSK) 27 1839 L 1840 Label 4 1841 Locally served DNS zone 6 1843 M 1844 Master file 11 1845 Master server 16 1847 N 1848 NODATA 10 1849 NSEC 25 1850 NSEC3 25 1851 Naming system 3 1852 Negative caching 15 1853 Negative response 11 1854 Next closer name 21 1856 O 1857 OPT 12 1858 Occluded name 22 1859 Open resolver 17 1860 Opt-out 25 1861 Origin 18 1862 Out-of-bailiwick 20 1863 Owner 12 1865 P 1866 Parent 18 1867 Passive DNS 17 1868 Policy-implementing resolver 17 1869 Presentation format 11 1870 Primary master 16 1871 Primary server 16 1872 Priming 14 1873 Private DNS 6 1874 Public suffix 8 1876 R 1877 RDAP 23 1878 RR 11 1879 RRset 11 1880 Recursive mode 14 1881 Recursive resolver 14 1882 Referrals 11 1883 Registrant 23 1884 Registrar 23 1885 Registry 23 1886 Resolver 13 1887 Reverse DNS, reverse lookup 22 1888 Root hints 14 1889 Root zone 20 1891 S 1892 SOA field names 12 1893 Secondary server 15 1894 Secure Entry Point (SEP) 27 1895 Service name 22 1896 Signed zone 24 1897 Signing software 28 1898 Slave server 15 1899 Source of Synthesis 21 1900 Split DNS 18 1901 Stealth server 16 1902 Stub resolver 13 1903 Subdomain 8 1905 T 1906 TLD 7 1907 TTL 12 1908 Trust anchor 28 1910 U 1911 Unsigned zone 24 1913 V 1914 Validating resolver 26 1915 Validation 25 1916 View 17 1918 W 1919 WHOIS 23 1920 Wildcard 21 1921 Wildcard domain name 21 1923 Z 1924 Zone 18 1925 Zone cut 19 1926 Zone enumeration 25 1927 Zone signing key (ZSK) 27 1928 Zone transfer 15 1930 Acknowledgements 1932 The following is the Acknowledgements for RFC 7719. Additional 1933 acknowledgements may be added as this draft is worked on. 1935 The authors gratefully acknowledge all of the authors of DNS-related 1936 RFCs that proceed this one. Comments from Tony Finch, Stephane 1937 Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John 1938 Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, 1939 David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, 1940 John Klensin, David Black, and many others in the DNSOP Working Group 1941 helped shape RFC 7719. 1943 Additional people contributed to this document, including: John 1944 Dickinson, Bob Harold, Peter Koch, [[ MORE NAMES WILL APPEAR HERE AS 1945 FOLKS CONTRIBUTE]]. 1947 Authors' Addresses 1949 Paul Hoffman 1950 ICANN 1952 Email: paul.hoffman@icann.org 1954 Andrew Sullivan 1955 Oracle 1956 100 Milverton Drive 1957 Mississauga, ON L5R 4H1 1958 Canada 1960 Email: andrew.s.sullivan@oracle.com 1962 Kazunori Fujiwara 1963 Japan Registry Services Co., Ltd. 1964 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1965 Chiyoda-ku, Tokyo 101-0065 1966 Japan 1968 Phone: +81 3 5215 8451 1969 Email: fujiwara@jprs.co.jp