idnits 2.17.1 draft-ietf-dnsop-dns-terminology-00.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 651: '... resolver SHOULD treat the child zon...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2015) is 3292 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' ** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035) ** Obsolete normative reference: RFC 1206 (Obsoleted by RFC 1325) ** Downref: Normative reference to an Informational RFC: RFC 6781 ** Downref: Normative reference to an Informational RFC: RFC 6841 Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Best Current Practice A. Sullivan 5 Expires: October 16, 2015 Dyn 6 K. Fujiwara 7 JPRS 8 April 14, 2015 10 DNS Terminology 11 draft-ietf-dnsop-dns-terminology-00 13 Abstract 15 The DNS is defined in literally dozens of different RFCs. The 16 terminology used in by implementers and developers of DNS protocols, 17 and 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 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 16, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. DNS Header and Response Codes . . . . . . . . . . . . . . . . 4 59 4. Resource Records . . . . . . . . . . . . . . . . . . . . . . 5 60 5. DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 7. Registration Model . . . . . . . . . . . . . . . . . . . . . 13 63 8. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 14 64 9. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 15 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 13.2. Informative References . . . . . . . . . . . . . . . . . 19 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 The domain name system (DNS) is a simple query-response protocol 76 whose messages in both directions have the same format. The protocol 77 and message format are defined in [RFC1034] and [RFC1035]. These 78 RFCs defined some terms, but later documents defined others. Some of 79 the terms from RFCs 1034 and 1035 now have somewhat different 80 meanings than they did in 1987. 82 This document collects a wide variety of DNS-related terms. Some of 83 them have been precisely defined in earlier RFCs, some have been 84 loosely defined in earlier RFCs, and some are not defined in any 85 earlier RFC at all. 87 The definitions here are believed to be the consensus definition of 88 the DNS community, both protocol developers and operators. Some of 89 the definitions differ from earlier RFCs, and those differences are 90 noted. The terms are organized loosely by topic. Some definitions 91 are for new terms for things that are commonly talked about in the 92 DNS community but that never had terms defined for them. 94 In this document, where the consensus definition is the same as the 95 one in an RFC, that RFC is quoted. Where the consensus definition 96 has changed somewhat, the RFC is mentioned but the new stand-alone 97 definition is given. 99 Other organizations sometimes define DNS-related terms their own way. 100 For example, the W3C defines "domain" at 101 https://specs.webplatform.org/url/webspecs/develop/. 103 Note that there is no single consistent definition of "the DNS". It 104 can be considered to be some combination of the following: a 105 commonly-used naming scheme for objects on the Internet; a database 106 representing the names and certain properties of these objects; an 107 architecture providing distributed maintenance, resilience, and loose 108 coherency for this database; and a simple query-response protocol (as 109 mentioned in the current draft) implementing this architecture. 111 Capitalization in DNS terms is often inconsistent between RFCs and 112 between DNS practitioners. The capitalization used in this document 113 is a best guess at current practices, and is not meant to indicate 114 that other capitalization styles are wrong or archaic. 116 2. Names 118 Domain name -- Section 3.1 of [RFC1034] talks of "the domain name 119 space" as a tree structure. "Each node has a label, which is zero to 120 63 octets in length. ... The domain name of a node is the list of the 121 labels on the path from the node to the root of the tree. ... To 122 simplify implementations, the total number of octets that represent a 123 domain name (i.e., the sum of all label octets and label lengths) is 124 limited to 255." 126 Fully-qualified domain name (FQDN) -- This is often just a clear way 127 of saying the same thing as "domain name of a node", as outlined 128 above. However, the term is ambiguous. Strictly speaking, a fully- 129 qualified name would include every label, including the final, zero- 130 length label of the root zone: such a name would be written 131 "www.example.net." (note the terminating dot). But because every 132 name eventually shares the common root, names are often written 133 relative to the root (such as "www.example.net") and are still called 134 "fully qualified". 135 This term first appeared in [RFC1206]. 137 Host name -- This term and its equivalent, "hostname", have been 138 widely used but are not defined in [RFC1034], [RFC1035], [RFC1123], 139 or [RFC2181]. The DNS was originally deployed into the Host Tables 140 environment as outlined in [RFC0952], and it is likely that the term 141 followed informally from the definition there. Over time, the 142 definition seems to have shifted. "Host name" is often meant to be a 143 domain name that follows the rules in Section 3.5 of [RFC1034], the 144 "preferred name syntax". Note that any label in any domain name can 145 contain any octet value; hostnames are generally considered to be 146 domain names where every label follows the rules in the "preferred 147 name syntax", with the amendment that labels can start with ASCII 148 digits (this amendment comes from Section 2.1 of [RFC1123]). 150 People also sometimes use the term hostname to refer to just the 151 first label of an FQDN. In addition, people sometimes use this term 152 to describe any name that refers to a machine, and those might 153 include labels that do not conform to the "preferred name syntax". 155 TLD -- A Top-Level Domain, meaning a zone that is one layer below the 156 root, such as .com or .jp. There is nothing special, from the point 157 of view of the DNS, about TLDs. Most of them are also delegation- 158 centric zones, and there are significant policy issues around their 159 operation. 161 ccTLD -- A TLD that is allocated to a country. Historically, these 162 were two-letter TLDs, and were allocated to countries using the two- 163 letter code from the ISO 3166-1 alpha-2 standard [ISO3166]. In 164 recent years, there have been allocations of TLDs that conform to 165 IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); 166 these are still treated as ccTLDs for policy purposes. 168 gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one 169 of the small number of historical TLDs such as .int and .arpa. There 170 is no precise definition for which TLDs that are not ccTLDs are 171 gTLDs. 173 Public suffix -- A domain under which subdomains can be registered, 174 and on which HTTP cookies ([RFC6265]) should not be set. For 175 example, at the time this document is published, .com.au is 176 considered a public suffix, but .au is not. Note that this term is 177 controversial in the DNS community for many reasons, and may be 178 significantly changed in the future. One example of the difficulty 179 of calling a domain a public suffix is that designation can change 180 over time as the registration policy for the zone changes, such as 181 the case of the .uk zone around the time this document is published. 183 3. DNS Header and Response Codes 185 The header of a DNS message is first 12 octets. Many of the fields 186 and flags in the header diagram in section 4.1.1 of [RFC1035] are 187 referred to by their names in that diagram. For example, the 188 response codes are called "RCODEs", and the authoritative answer bit 189 is often called "the AA flag" or "the AA bit". 191 Some of response codes that are defined in [RFC1035] have gotten 192 their own shorthand names. Some common response code names that 193 appear without reference to the numeric value are "FORMERR", 194 "SERVFAIL", and "NXDOMAIN". All of the RCODEs are listed at 195 http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml, 196 although that site uses mixed-case capitalization, while most 197 documents use all-caps. 199 NODATA - This is not an actual response code, but is a particular 200 type of response from a server that indicates that the queried domain 201 name exists for the given class, but the resource record type being 202 queried for does not exist. A NODATA response is a combination of an 203 RCODE of 0 (NOERROR) and an Answer section that is empty. In 204 addition, NODATA responses from authoritative servers have the 205 authoritative answer (AA bit) set to 1 and include an SOA record. 206 Section 1 of [RFC2308] defines NODATA as "a pseudo RCODE which 207 indicates that the name is valid, for the given class, but are no 208 records of the given type". The term "NXRRSET" is becoming more 209 common as a synonym for NODATA. 211 Negative response -- A response whose RCODE indicates that a 212 particular RRset does not exist in the DNS or a failure of a 213 nameserver. Sections 2 and 7 of [RFC2308] describes the types of 214 negative responses in detail. 216 4. Resource Records 218 RR -- A short form for resource record. ([RFC1034], section 3.6.) 220 RRset -- A set of resource records with the same label, class and 221 type, but with different data. (Definition from [RFC2181]) Also 222 spelled RRSet in some documents. As a clarification, "same label" in 223 this definition means "same owner name". In addition, [RFC2181] 224 states that "the TTLs of all RRs in an RRSet must be the same". 226 EDNS -- Also commonly called "EDNS0", this is the extension 227 mechanisms for DNS. The extension mechanism, defined in [RFC6891], 228 allows DNS clients and servers to specify message sizes larger than 229 the original 512 octet limit, to expand the response code space, and 230 to potentially carry additional options that affect the handling of a 231 DNS query. 233 OPT -- A pseudo-RR (sometimes called a meta-RR) that is used only to 234 contain control information pertaining to the question-and-answer 235 sequence of a specific transaction. (Definition from [RFC6891], 236 section 6.1.1) It is used by EDNS. 238 Owner -- The domain name where a RR is found ([RFC1034], section 239 3.6). Often appears in the term "owner name". 241 SOA field names -- DNS documents, including the definitions here, 242 often refer to the fields in the RDATA an SOA resource record by 243 field name. Those fields are defined in Section 3.3.13 of [RFC1035]. 244 The names (in the order they appear in the SOA RDATA) are MNAME, 245 RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the 246 meaning of MINIMUM field is updated in Section 4 of [RFC2308]; the 247 new definition is that the MINIMUM field is only "the TTL to be used 248 for negative responses". 250 TTL -- The maximum "time to live" of a resource record. A TTL value 251 is an unsigned number, with a minimum value of 0, and a maximum value 252 of 2147483647. That is, a maximum of 2^31 - 1. When transmitted, 253 the TTL is encoded in the less significant 31 bits of the 32 bit TTL 254 field, with the most significant, or sign, bit set to zero. (Quoted 255 from [RFC2181], section 8) (Note that [RFC1035] erroneously stated 256 that this is a signed integer; it is fixed in an erratum.) 258 The TTL "specifies the time interval that the resource record may be 259 cached before the source of the information should again be 260 consulted". (Quoted from [RFC1035], section 3.2.1) Also: "the time 261 interval (in seconds) that the resource record may be cached before 262 it should be discarded". (Quoted from [RFC1035], section 4.1.3). 263 Despite being defined for a resource record, the TTL of every 264 resource record in an RRset is required to be the same (RFC2181, 265 section 5.2). 267 The reason that the TTL is the maximum time to live is that a cache 268 operator might decide to shorten the time to live for operational 269 purposes, such as if there is a policy to not allow TTL values over a 270 certain number. Also, if a value is flushed from the cache when its 271 value is still positive, the value effectively becomes zero. Some 272 servers do not honor the TTL on an RRset from the authoritative 273 servers, such as when when the authoritative data has a very short 274 TTL. 276 There is also the concept of a "default TTL" for a zone, which can be 277 a configuration parameter in the server software. This is often 278 expressed by a default for the entire server, and a default for a 279 zone using the $TTL directive in a zone file. The $TTL directive was 280 added to the master file format by [RFC2308]. 282 5. DNS Servers 284 This section defines the terms used for the systems that act as DNS 285 clients, DNS servers, or both. Some terms about servers describe 286 servers that do and do not use DNSSEC; see Section 8 for those 287 definitions. 289 [[ There is a request to "first describe the iterative and recursive 290 resolution processes, and mention the expected values of the RD,RA,AA 291 bits. Then you can describe the distinctions between recursive and 292 iterative clients, and between recursive and authoritative servers, 293 in terms of the roles they play in the different resolution 294 processes." This would require the section to be quite different 295 than the other sections in the document. ]] 297 Resolver -- A program that extracts information from name servers in 298 response to client requests. (Quoted from [RFC1034], section 2.4) It 299 is a program that interfaces user programs to domain name servers. 300 The resolver is located on the same machine as the program that 301 requests the resolver's services. (Quoted from [RFC1034], section 302 5.1) A resolver performs queries for a name, type, and class, and 303 receives answers. The logical function is called "resolution". In 304 practice, the term is usually referring to some specific type of 305 resolver (some of which are defined below), and understanding the use 306 of the term depends on understanding the context. 308 Stub resolver -- A resolver that cannot perform all resolution 309 itself. Stub resolvers generally depend on a recursive resolver to 310 undertake the actual resolution function. Stub resolvers are 311 discussed but never fully defined in Section 5.3.1 of [RFC1034]. 312 They are fully defined in Section 6.1.3.1 of [RFC1123]. 314 Iterative mode -- A resolution mode of a server that receives DNS 315 queries and responds with a referral to another server. Section 2.3 316 of [RFC1034] describes this as "The server refers the client to 317 another server and lets the client pursue the query". A resolver 318 that works in iterative mode is sometimes called an "iterative 319 resolver". 321 Recursive mode -- A resolution mode of a server that receives DNS 322 queries and either responds to those queries from a local cache or 323 sends queries to other servers in order to get the final answers to 324 the original queries. Section 2.3 of [RFC1034] describes this as 325 "The first server pursues the query for the client at another 326 server". A server operating in recursive mode may be thought of as 327 having a name server side (which is what answers the query) and a 328 resolver side (which performs the resolution function). Systems 329 operating in this mode are commonly called "recursive servers". 331 Sometimes they are called "recursive resolvers". While strictly the 332 difference between these is that one of them sends queries to another 333 recursive server and the other does not, in practice it is not 334 possible to know in advance whether the server that one is querying 335 will also perform recursion; both terms can be observed in use 336 interchangeably. Resolvers acting in recursive mode are also 337 sometimes called "caching servers". 339 Full-service resolver -- Section 6.1.3.1 of [RFC1123] defines this 340 term to mean a resolver that acts in recursive mode with a cache, as 341 well as other requirements. 343 Priming -- The mechanism used by a resolver to determine where to 344 send queries before there is anything in the resolver's cache. 345 Priming is most often done from a configuration setting that contains 346 a list of authoritative servers for the DNS root zone. 348 Negative caching -- The storage of knowledge that something does not 349 exist, cannot give an answer, or does not give an answer. (Quoted 350 from Section 1 of [RFC2308]) 352 Authoritative server -- A system that responds to DNS queries with 353 information about zones for which it has been configured to answer 354 with the AA flag in the response header set to 1. It is a server 355 that has authority over one or more DNS zones. Note that it is 356 possible for an authoritative server to respond to a query without 357 the parent zone delegating authority to that server. Authoritative 358 servers also provide "referrals", usually to child zones delegated 359 from them; these referrals have the AA bit set to 0 and come with 360 referral data in the Additional section. 362 Primary servers and secondary servers -- These are synonyms for 363 "master server" and "slave server", which were the terms used in the 364 early DNS RFCs, and defined below. The current common usage has 365 shifted to "primary" and "secondary". 367 Slave server -- An authoritative server which uses zone transfer to 368 retrieve the zone. (Quoted from [RFC1996], section 2.1) [RFC2182] 369 describes slave servers in detail. 371 Master -- Any authoritative server configured to be the source of 372 zone transfer for one or more slave servers. (Quoted from [RFC1996], 373 section 2.1) [RFC2136] defines "master" as "an authoritative server 374 configured to be the source of AXFR or IXFR data for one or more 375 slave servers". 377 Primary master -- The primary master is named in the zone's SOA MNAME 378 field and optionally by an NS resource record. (Quoted from 380 [RFC1996], section 2.1) [RFC2136] defines "primary master" as "Master 381 server at the root of the AXFR/IXFR dependency graph. The primary 382 master is named in the zone's SOA MNAME field and optionally by an NS 383 RR. There is by definition only one primary master server per zone." 385 Stealth server -- This is the same as a slave server except that it 386 is not listed in an NS resource record for the zone. (Quoted from 387 [RFC1996], section 2.1) A stealth server is often actually a master 388 for zone transfers, and in that case is called a "hidden master". 390 Zone transfer -- The act of a client requesting a copy of a zone and 391 an authoritative server sending the needed information. There are 392 two common standard ways to do zone transfers: the AXFR 393 ("Authoritative Transfer") mechanism to copy the full zone, and the 394 IXFR ("Incremental Transfer") mechanism to copy only parts of the 395 zone that have changed. Many systems use non-standard methods for 396 zone transfer outside the DNS protocol. 398 Forwarder -- A system that receives a DNS query, possibly changes the 399 query, sends on the resulting query (usually to a recursive 400 resolver), receives the response, possibly changes the response, and 401 sends the resulting response to the source of the query (usually a 402 stub resolver). Section 1 of [RFC2308] describes a forwarder as "a 403 nameserver used to resolve queries instead of directly using the 404 authoritative nameserver chain". [RFC2308] further says "The 405 forwarder typically either has better access to the internet, or 406 maintains a bigger cache which may be shared amongst many resolvers." 408 [RFC5625] does not give a specific definition for DNS forwarder, but 409 describes in detail what features they need to support. The protocol 410 interfaces for DNS forwarders are exactly the same as those for 411 recursive resolvers (for interactions with DNS stubs) and as those 412 for stub resolvers (for interactions with recursive resolvers). 413 Forwarders are also sometimes called "DNS forwarders". They are 414 sometimes also called "DNS proxies", but that term has not yet been 415 defined (even in [RFC5625]). 417 Full resolver -- This term is used in [RFC1035], but it is not 418 defined there. RFC 1123 defines a "full-service resolver" that may 419 or may not be what was intended by "full resolver" in [RFC1035]. In 420 the vernacular, a full-service resolver is usually one that would be 421 suitable for use by a stub resolver. 423 Consensual policy-implementing resolver -- A resolver that changes 424 some answers it returns based on policy criteria, such as to prevent 425 access to malware sites. These policy criteria are agreed to by 426 systems that query this resolver through some out of band mechanism 427 (such as finding out about the resolver from a web site and reading 428 the policy). 430 Non-consensual policy-implementing resolver -- A resolver that is not 431 a consensual policy-implementing resolver that changes the answers it 432 returns. The difference between this and a consensual policy- 433 implementing resolver is that users of this resolver are not expected 434 to know that there is a policy to change the answers it returns. 436 Open resolver -- A full resolver that accepts and processes queries 437 from any (or nearly any) stub resolver. This is sometimes also 438 called a "public resolver". 440 Open forwarder -- A DNS forwarder that accepts and forwards queries 441 from any (or nearly any) stub resolver to a full resolver. 443 View -- A configuration for a DNS server that allows it to provide 444 different answers depending on attributes of the query. Typically, 445 views differ by the source IP address of a query, but can also be 446 based on the destination IP address, the type of query (such as 447 AXFR), and so on. Views are often used to provide more names or 448 different addresses to queries from "inside" a protected network than 449 to those "outside" that network. Views are not a standardized part 450 of the DNS, but they are widely implemented in server software. 452 Passive DNS -- A mechanism to collect large amounts of DNS data by 453 storing queries and responses from recursive servers. Passive DNS 454 databases can be used to answer historical questions about DNS zones 455 such as which records were available for them at what times in the 456 past. Passive DNS databases allow searching of the stored records on 457 keys other than just the name, such as "find all names which have A 458 records of a particular value". 460 Child-centric resolver -- A DNS resolver that, instead of serving the 461 NS RRset and glue records that it obtained from the parent of a zone, 462 serves data from the authoritative servers for that zone. The term 463 "child-centric" is meant as the opposite of "parent-centric", which 464 means a resolver that simply serves the NS RRset and glue records for 465 a zone that it obtained from the zone's parent, without checking the 466 authoritative servers for that zone. 468 6. Zones 470 This section defines terms that are used when discussing zones that 471 are being served or retrieved. 473 Zone -- A unit of organization of authoritative data. Zones can be 474 automatically distributed to the name servers which provide redundant 475 service for the data in a zone. (Quoted from [RFC1034], section 476 2.4). 478 Child -- The entity on record that has the delegation of the domain 479 from the Parent. (Quoted from [RFC7344], section 1.1) 481 Parent -- The domain in which the Child is registered. (Quoted from 482 [RFC7344], section 1.1) Earlier, "parent name server" was defined in 483 [RFC0882] as "the name server that has authority over the place in 484 the domain name space that will hold the new domain". 486 Origin -- 1. The domain name that appears at the top of a zone. 2. 487 The domain name within which a given relative domain name appears in 488 zone files. Generally seen in the context of "$ORIGIN", which is a 489 control entry defined in [RFC1035], section 5.1, as part of the 490 master file format. For example, if the $ORIGIN is set to 491 "example.org.", then a master file line for "www" is in fact an entry 492 for "www.example.org.". 494 Zone cut -- The delimitation point between two zones where the origin 495 of one of the zones is the child of the other zone. (Section 6 of 496 [RFC2181] uses this term extensively, although never actually defines 497 it.) Section 4.2 of [RFC1034] uses "cuts" as "zone cut". 499 Apex -- The point in the tree at an owner of an SOA and corresponding 500 authoritative NS RRset. This is also called the "zone apex". 501 [RFC4033] defines it as "the name at the child's side of a zone cut". 502 The "apex" can usefully be thought of as a data-theoretic description 503 of a tree structure, and "origin" is the name of the same concept 504 when it is implemented in zone files. The distinction is not always 505 maintained in use, however, and one can find uses that conflict 506 subtly with this definition. 508 Delegation -- The process by which a separate zone is created in the 509 name space beneath the apex of a given domain. Delegation happens 510 when an NS RRset is added in the parent zone for the child origin, 511 and a corresponding zone apex is created at the child origin. 512 Delegation inherently happens at a zone cut. 514 Referrals -- Data from the authority section of a non-authoritative 515 answer. [RFC1035] section 2.1 defines "authoritative" data. 516 However, referrals at zone cuts are not authoritative. Referrals may 517 be a zone cut NS resource records and their glue. NS records on the 518 parent side of a zone cut are an authoritative delegation, but are 519 normally not treated as authoritative data by the client. In 520 general, a referral is a way for a server to send an answer saying 521 that the server does not know the answer, but knows where the query 522 should be directed in order to get an answer. Historically, many 523 authoritative servers answered with a referral to the root zone when 524 queried for a name for which they were not authoritative, but this 525 practice has declined. 527 Glue records -- Resource records which are not part of the 528 authoritative data [for a zone], and are address resource records for 529 the servers [in a subzone]. These RRs are only necessary if the name 530 server's name is "below" the cut, and are only used as part of a 531 referral response. (Definition from [RFC1034], section 4.2.1) 533 A later definition is that glue "includes any record in a zone file 534 that is not properly part of that zone, including nameserver records 535 of delegated sub-zones (NS records), address records that accompany 536 those NS records (A, AAAA, etc), and any other stray data that might 537 appear". (Definition from [RFC2181], section 5.4.1) This definition 538 in [RFC2181] is wider than the one from [RFC1034], and bases the 539 definition on the contents of a zone file. Some implementers might 540 only be thinking about the earlier definition when they see rules 541 about glue records. 543 In-bailiwick - 1. An adjective to describe a name server the name of 544 which is either subordinate to or (rarely) the same as the zone 545 origin. In-bailiwick name servers require glue in their parent zone. 546 2. Data for which the server is either authoritative, or else 547 authoritative for an ancestor of the owner name. This sense of the 548 term normally is used when discussing the relevancy of glue records 549 in a response. For example, the server for the parent zone 550 example.com might reply with glue records for ns.child.example.com. 551 Because the child.example.com zone is a descendant of the example.com 552 zone, both glue records are in-bailiwick. 554 Out-of-bailiwick - The antonym of in-bailiwick. 556 Authoritative data -- All of the RRs attached to all of the nodes 557 from the top node of the zone down to leaf nodes or nodes above cuts 558 around the bottom edge of the zone. (Quoted from Section 4.2.1 of 559 [RFC1034]) It is noted that this definition might inadvertently also 560 include any NS records that appear in the zone, even those that might 561 not truly be authoritative because there are identical NS RRs below 562 the zone cut. This reveals the ambiguity in the notion of 563 authoritative data, because the parent-size NS records 564 authoritatively indicate the delegation, even though they are not 565 themselves authoritative data. 567 Root zone -- The zone whose origin is the zero-length label. Also 568 sometimes called "the DNS root". 570 Empty non-terminal -- A domain name that has no RRsets, but has 571 descendants that have RRsets. A typical example is in SRV records: 572 in the name "_sip._tcp.example.com", it is likely that 573 "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com" 574 has (at least) an SRV RRset. 576 Delegation-centric zone -- A zone which consists mostly of 577 delegations to child zones. This term is used in contrast to a zone 578 which might have some delegations to child zones, but also has many 579 data resource records for the zone itself and/or for child zones. 581 Wildcard -- [RFC1034] defined "wildcard", but in a way that turned 582 out to be confusing to implementers. For an extended discussion of 583 wildcards, including clearer definitions, see [RFC4592]. 585 Occluded name -- The addition of a delegation point via dynamic 586 update will render all subordinate domain names to be in a limbo, 587 still part of the zone but not available to the lookup process. The 588 addition of a DNAME resource record has the same impact. The 589 subordinate names are said to be "occluded". (Quoted from [RFC5936], 590 Section 3.5) 592 Fast flux DNS -- A mechanism where a large number of hosts rapidly 593 update the address records of a zone, often to deliver malware. 594 Because the addresses change so rapidly, it is difficult to 595 definitively find all the hosts. 597 7. Registration Model 599 Registry -- The administrative operation of a zone that allows 600 registration of names within that zone. 602 Registrant -- An individual or organization on whose behalf a name in 603 a zone is registered by the registry. In many zones, the registry 604 and the registrant may be the same entity, but in TLDs they often are 605 not. 607 Registrar -- A service provider that acts as a go-between for 608 registrants and registries. Not all registrations require a 609 registrar, though it is common to have registrars be involved in 610 registrations in TLDs. 612 EPP -- The Extensible Provisioning Protocol (EPP), which is commonly 613 used for communication of registration information between registries 614 and registrars. EPP is defined in [RFC5730]. 616 8. General DNSSEC 618 Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035]. 619 The terms that have caused confusion in the DNS community are 620 highlighted here. 622 DNSSEC-aware and DNSSEC-unaware -- Section 2 of [RFC4033] defines 623 many types of resolvers and validators. In specific, the terms "non- 624 validating security-aware stub resolver", "non-validating stub 625 resolver", "security-aware name server", "security-aware recursive 626 name server", "security-aware resolver", "security-aware stub 627 resolver", and "security-oblivious 'anything'" are all defined. 628 (Note that the term "validating resolver", which is used in some 629 places in those documents, is nevertheless not defined in that 630 section.) 632 Signed zone -- A zone whose RRsets are signed and that contains 633 properly constructed DNSKEY, Resource Record Signature (RRSIG), Next 634 Secure (NSEC), and (optionally) DS records. (Quoted from [RFC4033], 635 section 2) It has been noted in other contexts that the zone itself 636 is not really signed, but all the relevant RRsets in the zone are 637 signed. It should also be noted that, since the publication of 638 [RFC6840], NSEC records are no longer required for signed zones: a 639 signed zone might include NSEC3 records instead. 641 Unsigned zone -- Section 2 of [RFC4033] defines this as "a zone that 642 is not signed". Section 2 of [RFC4035] defines this as "A zone that 643 does not include these records [properly constructed DNSKEY, Resource 644 Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS 645 records] according to the rules in this section". There is an 646 important note at the end of Section 5.2 of [RFC4035] adding an 647 additional situation when a zone is considered unsigned: "If the 648 resolver does not support any of the algorithms listed in an 649 authenticated DS RRset, then the resolver will not be able to verify 650 the authentication path to the child zone. In this case, the 651 resolver SHOULD treat the child zone as if it were unsigned." 653 NSEC -- "The NSEC record allows a security-aware resolver to 654 authenticate a negative reply for either name or type non-existence 655 with the same mechanisms used to authenticate other DNS replies." 656 (Quoted from Section 3.2 of [RFC4033]) In short, an NSEC record 657 provides authenticated denial of existence. 659 The NSEC resource record lists two separate things: the next owner 660 name (in the canonical ordering of the zone) that contains 661 authoritative data or a delegation point NS RRset, and the set of RR 662 types present at the NSEC RR's owner name. (Quoted from Section 4 of 663 4034) 664 NSEC3 -- The NSEC3 resource record is quite different than the NSEC 665 resource record. Like the NSEC record, the NSEC3 record also 666 provides authenticated denial of existence; however, NSEC3 records 667 mitigates against zone enumeration and support Opt-Out. NSEC3 668 resource records are defined in [RFC5155]. 670 Opt-out -- The Opt-Out Flag indicates whether this NSEC3 RR may cover 671 unsigned delegations. (Quoted from Section 3.1.2.1 of [RFC5155]) 673 Zone enumeration -- The practice of discovering the full content of a 674 zone via successive queries. (Quoted from Section 1.3 of [RFC5155]) 675 This is also sometimes call "zone walking". Zone enumeration is 676 different from zone content guessing where the guesser uses a large 677 dictionary of possible labels and sends successive queries for them, 678 or matches the contents of NSEC3 records against such a dictionary. 680 DNSSEC Policy (DP) -- A statement that sets forth the security 681 requirements and standards to be implemented for a DNSSEC-signed 682 zone. (Quoted from [RFC6841], section 2) 684 DNSSEC Practice Statement (DPS) -- A practices disclosure document 685 that may support and be a supplemental document to the DNSSEC Policy 686 (if such exists), and it states how the management of a given zone 687 implements procedures and controls at a high level. (Quoted from 688 [RFC6841], section 2) 690 Key signing key (KSK) -- DNSSEC keys that only sign the apex DNSKEY 691 RRset in a zone. (Quoted from [RFC6781], Section 3.1) 693 Zone signing key (ZSK) -- DNSSEC keys that can be used to sign all 694 the RRsets in a zone that require signatures, other than the apex 695 DNSKEY RRset. (Quoted from [RFC6781], Section 3.1) Note that the 696 roles KSK and ZSK are not mutually exclusive: a single key can be 697 both KSK and ZSK at the same time. This is sometimes called a 698 "combined signing key" or CSK. It is operational practice, not 699 protocol, that determines whether a particular key is a ZSK, a KSK, 700 or a CSK. 702 9. DNSSEC States 704 A validating resolver can determine that a response is in one of four 705 states: secure, insecure, bogus, or indeterminate. These states are 706 defined in [RFC4033] and [RFC4035], although the two definitions 707 differ a bit. 709 Section 5 of [RFC4033] says: 711 A validating resolver can determine the following 4 states: 713 Secure: The validating resolver has a trust anchor, has a chain of 714 trust, and is able to verify all the signatures in the response. 716 Insecure: The validating resolver has a trust anchor, a chain of 717 trust, and, at some delegation point, signed proof of the 718 non-existence of a DS record. This indicates that subsequent 719 branches in the tree are provably insecure. A validating resolver 720 may have a local policy to mark parts of the domain space as 721 insecure. 723 Bogus: The validating resolver has a trust anchor and a secure 724 delegation indicating that subsidiary data is signed, but the 725 response fails to validate for some reason: missing signatures, 726 expired signatures, signatures with unsupported algorithms, data 727 missing that the relevant NSEC RR says should be present, and so 728 forth. 730 Indeterminate: There is no trust anchor that would indicate that a 731 specific portion of the tree is secure. This is the default 732 operation mode. 734 Section 4.3 of [RFC4035] says: 736 A security-aware resolver must be able to distinguish between four 737 cases: 739 Secure: An RRset for which the resolver is able to build a chain of 740 signed DNSKEY and DS RRs from a trusted security anchor to the 741 RRset. In this case, the RRset should be signed and is subject to 742 signature validation, as described above. 744 Insecure: An RRset for which the resolver knows that it has no chain 745 of signed DNSKEY and DS RRs from any trusted starting point to the 746 RRset. This can occur when the target RRset lies in an unsigned 747 zone or in a descendent of an unsigned zone. In this case, the 748 RRset may or may not be signed, but the resolver will not be able 749 to verify the signature. 751 Bogus: An RRset for which the resolver believes that it ought to be 752 able to establish a chain of trust but for which it is unable to 753 do so, either due to signatures that for some reason fail to 754 validate or due to missing data that the relevant DNSSEC RRs 755 indicate should be present. This case may indicate an attack but 756 may also indicate a configuration error or some form of data 757 corruption. 759 Indeterminate: An RRset for which the resolver is not able to 760 determine whether the RRset should be signed, as the resolver is 761 not able to obtain the necessary DNSSEC RRs. This can occur when 762 the security-aware resolver is not able to contact security-aware 763 name servers for the relevant zones. 765 10. IANA Considerations 767 This document has no effect on IANA registries. 769 11. Security Considerations 771 These definitions do not change any security considerations for the 772 DNS. 774 12. Acknowledgements 776 The authors gratefully acknowledge all of the authors of DNS-related 777 RFCs that proceed this one. Comments from Tony Finch, Stephane 778 Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John 779 Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, 780 David Lawrence, Matthijs Mekking, Casey Deccio, and many others in 781 the DNSOP Working Group have helped shape this document. 783 13. References 785 13.1. Normative References 787 [ISO3166] International Organization for Standardization (ISO), 788 "Country Codes - ISO 3166", February 2015, 789 . 791 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 792 RFC 882, November 1983. 794 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 795 STD 13, RFC 1034, November 1987. 797 [RFC1035] Mockapetris, P., "Domain names - implementation and 798 specification", STD 13, RFC 1035, November 1987. 800 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 801 and Support", STD 3, RFC 1123, October 1989. 803 [RFC1206] Malkin, G. and A. Marine, "FYI on Questions and Answers: 804 Answers to commonly asked "new Internet user" questions", 805 RFC 1206, February 1991. 807 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 808 Changes (DNS NOTIFY)", RFC 1996, August 1996. 810 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 811 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 812 RFC 2136, April 1997. 814 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 815 Specification", RFC 2181, July 1997. 817 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 818 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 819 July 1997. 821 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 822 NCACHE)", RFC 2308, March 1998. 824 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 825 Rose, "DNS Security Introduction and Requirements", RFC 826 4033, March 2005. 828 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 829 Rose, "Resource Records for the DNS Security Extensions", 830 RFC 4034, March 2005. 832 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 833 Rose, "Protocol Modifications for the DNS Security 834 Extensions", RFC 4035, March 2005. 836 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 837 System", RFC 4592, July 2006. 839 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 840 Security (DNSSEC) Hashed Authenticated Denial of 841 Existence", RFC 5155, March 2008. 843 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 844 STD 69, RFC 5730, August 2009. 846 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 847 (AXFR)", RFC 5936, June 2010. 849 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 850 Operational Practices, Version 2", RFC 6781, December 851 2012. 853 [RFC6840] Weiler, S. and D. Blacka, "Clarifications and 854 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 855 February 2013. 857 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 858 Framework for DNSSEC Policies and DNSSEC Practice 859 Statements", RFC 6841, January 2013. 861 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 862 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 864 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 865 DNSSEC Delegation Trust Maintenance", RFC 7344, September 866 2014. 868 13.2. Informative References 870 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 871 host table specification", RFC 952, October 1985. 873 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 874 152, RFC 5625, August 2009. 876 [RFC5890] Klensin, J., "Internationalized Domain Names for 877 Applications (IDNA): Definitions and Document Framework", 878 RFC 5890, August 2010. 880 [RFC5891] Klensin, J., "Internationalized Domain Names in 881 Applications (IDNA): Protocol", RFC 5891, August 2010. 883 [RFC5892] Faltstrom, P., "The Unicode Code Points and 884 Internationalized Domain Names for Applications (IDNA)", 885 RFC 5892, August 2010. 887 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 888 Internationalized Domain Names for Applications (IDNA)", 889 RFC 5893, August 2010. 891 [RFC5894] Klensin, J., "Internationalized Domain Names for 892 Applications (IDNA): Background, Explanation, and 893 Rationale", RFC 5894, August 2010. 895 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 896 April 2011. 898 Authors' Addresses 900 Paul Hoffman 901 VPN Consortium 902 127 Segre Place 903 Santa Cruz, CA 95060 904 USA 906 Email: paul.hoffman@vpnc.org 908 Andrew Sullivan 909 Dyn 910 150 Dow St, Tower 2 911 Manchester, NH 1604 912 USA 914 Email: asullivan@dyn.com 916 Kazunori Fujiwara 917 Japan Registry Services Co., Ltd. 918 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 919 Chiyoda-ku, Tokyo 101-0065 920 Japan 922 Phone: +81 3 5215 8451 923 Email: fujiwara@jprs.co.jp