idnits 2.17.1 draft-hoffman-dns-terminology-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 565: '... 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 (March 06, 2015) is 3337 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: September 7, 2015 Dyn 6 K. Fujiwara 7 JPRS 8 March 06, 2015 10 DNS Terminology 11 draft-hoffman-dns-terminology-02 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 September 7, 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 Message Format . . . . . . . . . . . . . . . . . . . . . 4 59 4. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 6 61 6. DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. Registration Model . . . . . . . . . . . . . . . . . . . . . 11 64 9. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 12 65 10. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 13 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 71 14.2. Informative References . . . . . . . . . . . . . . . . . 17 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 74 1. Introduction 76 The domain name system (DNS) is a simple query-response protocol 77 whose messages in both directions have the same format. The protocol 78 and message format are defined in [RFC1034] and [RFC1035]. These 79 RFCs defined some terms, but later documents defined others. Some of 80 the terms from RFCs 1034 and 1035 now have somewhat different 81 meanings than they did in 1987. 83 This document collects a wide variety of DNS-related terms. Some of 84 them have been precisely defined in earlier RFCs, some have been 85 loosely defined in earlier RFCs, and some are not defined in any 86 earlier RFC at all. 88 The definitions here are believed to be the consensus definition of 89 the DNS community, both protocol developers and operators. Some of 90 the definitions differ from earlier RFCs, and those differences are 91 noted. The terms are organized loosely by topic. Some definitions 92 are for new terms for things that are commonly talked about in the 93 DNS community but that never had terms defined for them. 95 In this document, where the consensus definition is the same as the 96 one in an RFC, that RFC is quoted. Where the consensus definition 97 has changed somewhat, the RFC is mentioned but the new stand-alone 98 definition is given. 100 Other organizations sometimes define DNS-related terms their own way. 101 For example, the W3C defines "domain" at 102 https://specs.webplatform.org/url/webspecs/develop/. 104 Note that there is no single consistent definition of "the DNS". It 105 can be considered to be some combination of the following: a 106 commonly-used naming scheme for objects on the Internet; a database 107 representing the names and certain properties of these objects; an 108 architecture providing distributed maintenance, resilience, and loose 109 coherency for this database; and a simple query-response protocol (as 110 mentioned in the current draft) implementing this architecture. 112 Capitalization in DNS terms is often inconsistent between RFCs and 113 between DNS practitioners. The capitalization used in this document 114 is a best guess at current practices, and is not meant to indicate 115 that other capitalization styles are wrong or archaic. 117 2. Names 119 Domain name -- Section 3.1 of RFC 1034 talks of "the domain name 120 space" as a tree structure. "Each node has a label, which is zero to 121 63 octets in length. ... The domain name of a node is the list of the 122 labels on the path from the node to the root of the tree. ... To 123 simplify implementations, the total number of octets that represent a 124 domain name (i.e., the sum of all label octets and label lengths) is 125 limited to 255." 127 Fully-qualified domain name (FQDN) -- This is often just a clear way 128 of saying the same thing as "domain name of a node", as outlined 129 above. However, the term is ambiguous. Strictly speaking, a fully- 130 qualified name would include every label, including the final, zero- 131 length label of the root zone: such a name would be written 132 "www.example.net." (note the terminating dot). But because every 133 name eventually shares the common root, names are often written 134 relative to the root (such as "www.example.net") and are still called 135 "fully qualified". 136 This term first appeared in [RFC1206]. 138 Host name -- This term and its equivalent, "hostname", have been 139 widely used but are not defined in RFC 1034, 1035, 1123, or 2181. 140 The DNS was originally deployed into the Host Tables environment as 141 outlined in [RFC0952], and it is likely that the term followed 142 informally from the definition there. Over time, the definition 143 seems to have shifted. "Host name" is often meant to be a domain 144 name that follows the rules in Section 3.5 of RFC 1034, the 145 "preferred name syntax". Note that any label in any domain name can 146 contain any octet value; hostnames are generally considered to be 147 domain names where every label follows the rules in the "preferred 148 name syntax", with the amendment that labels can start with ASCII 149 digits (this amendment comes from Section 2.1 of [RFC1123]). 151 People also sometimes use the term hostname to refer to just the 152 first label of an FQDN. In addition, people sometimes use this term 153 to describe any name that refers to a machine, and those might 154 include labels that do not conform to the "preferred name syntax". 156 TLD -- A Top-Level Domain, meaning a zone that is one layer below the 157 root, such as .com or .jp. There is nothing special, from the point 158 of view of the DNS, about TLDs. Most of them are also delegation- 159 centric zones, and there are significant policy issues around their 160 operation. 162 ccTLD -- A TLD that is allocated to a country. Historically, these 163 were two-letter TLDs, and were allocated to countries using the two- 164 letter code from the ISO 3166-1 alpha-2 standard [ISO3166]. In 165 recent years, there have been allocations of TLDs that conform to 166 IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]); 167 these are still treated as ccTLDs for policy purposes. 169 gTLD -- A "generic" TLD is a TLD that is not a ccTLD, and is not one 170 of the small number of historical TLDs such as .int and .arpa. There 171 is no precise definition for which TLDs that are not ccTLDs are 172 gTLDs. 174 3. DNS Message Format 176 Header -- The first 12 octets of a DNS message. Many of the fields 177 and flags in the header diagram in section 4.1.1 of RFC 1035 are 178 referred to by their names in that diagram. For example, the 179 response codes are called "RCODEs", and the authoritative answer bit 180 is often called "the AA flag" or "the AA bit". RCODEs are covered in 181 Section 4. 183 TTL -- The maximum "time to live" of a resource record. A TTL value 184 is an unsigned number, with a minimum value of 0, and a maximum value 185 of 2147483647. That is, a maximum of 2^31 - 1. When transmitted, 186 the TTL is encoded in the less significant 31 bits of the 32 bit TTL 187 field, with the most significant, or sign, bit set to zero. (Quoted 188 from [RFC2181], section 8) (Note that RFC 1035 erroneously stated 189 that this is a signed integer; it is fixed in an erratum.) 191 The TTL "specifies the time interval that the resource record may be 192 cached before the source of the information should again be 193 consulted". (Quoted from RFC 1035, section 3.2.1) Also: "the time 194 interval (in seconds) that the resource record may be cached before 195 it should be discarded". (Quoted from RFC 1035, section 4.1.3). 196 Despite being defined for a resource record, the TTL of every 197 resource record in an RRset is required to be the same (RFC2181, 198 section 5.2). 200 The reason that the TTL is the maximum time to live is that a cache 201 operator might decide to shorten the time to live for operational 202 purposes, such as if there is a policy to not allow TTL values over a 203 certain number. Also, if a value is flushed from the cache when its 204 value is still positive, the value effectively becomes zero. 206 There is also the concept of a "default TTL" for a zone, which can be 207 a configuration parameter in the server software. This is often 208 expressed by a default for the entire server, and an default override 209 for a zone using the $TTL directive in a zone file. The $TTL 210 directive was added to the master file format by [RFC2308]. 212 Glue records -- Resource records which are not part of the 213 authoritative data, and are address resource records for the servers 214 listed in the message. They contain data that allows access to name 215 servers for subzones. (Definition from RFC 1034, section 4.2.1) 217 Referrals -- Data from the authority section of a non-authoritative 218 answer. RFC 1035 section 2.1 defines "authoritative" data. However, 219 referrals at zone cuts are not authoritative. Referrals may be a 220 zone cut NS resource records and their glue. NS records on the 221 parent side of a zone cut are an authoritative delegation, but are 222 not treated as authoritative data by the client. [[ A more complete 223 and precise definition will be needed here. ]] 225 4. Response Codes 227 Some of response codes that are defined in RFC 1035 have gotten their 228 own shorthand names. Some common response code (RCODE) names that 229 appear without reference to the numeric value are "FORMERR", 230 "SERVFAIL", and "NXDOMAIN". All of the RCODEs are listed at 231 http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml, 232 although that site uses mixed-case capitalization, while most 233 documents use all-caps. 235 NODATA -- This is not an actual response code, but instead is the 236 combination of an RCODE of 0 (NOERROR) and an Answer section that is 237 empty. That is, it indicates that the response is no answer, but 238 that there was not supposed to be one. Section 1 of RFC 2308 defines 239 it as "a pseudo RCODE which indicates that the name is valid, for the 240 given class, but are no records of the given type." 242 5. Resource Records 244 RR -- A short form for resource record. (RFC 1034, section 3.6.) 246 RRset -- A set of resource records with the same label, class and 247 type, but with different data. (Definition from RFC 2181) Also 248 spelled RRSet in some documents. As a clarification, "same label" in 249 this definition means "same owner name". 251 OPT -- A pseudo-RR (sometimes called a meta-RR) that is used only to 252 contain control information pertaining to the question-and-answer 253 sequence of a specific transaction. (Definition from [RFC6891], 254 section 6.1.1) 256 Owner -- The domain name where a RR is found (RFC 1034, section 3.6). 257 Often appears in the term "owner name". 259 SOA field names -- DNS documents, including the definitions here, 260 often refer to the fields in the RDATA an SOA resource record by 261 field name. Those fields are defined in Section 3.3.13 of RFC 1035. 262 The names (in the order they appear in the SOA RDATA) are MNAME, 263 RNAME, SERIAL, REFRESH, RETRY, and EXPIRE, MINIMUM. Note that the 264 meaning of MINIMUM field is updated in Section 4 of RFC 2308; the new 265 definition is that the MINIMUM field is only "the TTL to be used for 266 negative responses". 268 6. DNS Servers 270 This section defines the terms used for the systems that act as DNS 271 clients, DNS servers, or both. Some terms about servers describe 272 servers that do and do not use DNSSEC; see Section 9 for those 273 definitions. 275 [[ There is a request to "first describe the iterative and recursive 276 resolution processes, and mention the expected values of the RD,RA,AA 277 bits. Then you can describe the distinctions between recursive and 278 iterative clients, and between recursive and authoritative servers, 279 in terms of the roles they play in the different resolution 280 processes." This would require the section to be quite different 281 than the other sections in the document. ]] 283 Resolver -- A program that extracts information from name servers in 284 response to client requests. (Quoted from RFC 1034, section 2.4) It 285 is a program that interfaces user programs to domain name servers. 286 The resolver is located on the same machine as the program that 287 requests the resolver's services. (Quoted from RFC 1034, section 288 5.1) A resolver performs queries for a name, type, and class, and 289 receives answers. The logical function is called "resolution". In 290 practice, the term is usually referring to some specific type of 291 resolver (some of which are defined below), and understanding the use 292 of the term depends on understanding the context. 294 Stub resolver -- A resolver that cannot perform all resolution 295 itself. Stub resolvers generally depend on a recursive resolver to 296 undertake the actual resolution function. Stub resolvers are 297 discussed but never fully defined in RFC 1034, section 5.3.1. 299 Iterative mode -- A resolution mode of a server that receives DNS 300 queries and responds with a referral to another server. Section 2.3 301 of RFC 1034 describes this as "The server refers the client to 302 another server and lets the client pursue the query". A resolver 303 that works in iterative mode is sometimes called an "iterative 304 resolver". 306 Recursive mode -- A resolution mode of a server that receives DNS 307 queries and either responds to those queries from a local cache or 308 sends queries to other servers in order to get the final answers to 309 the original queries. Section 2.3 of RFC 1034 describes this as "The 310 first server pursues the query for the client at another server". A 311 server operating in recursive mode may be thought of as having a name 312 server side (which is what answers the query) and a resolver side 313 (which performs the resolution function). Systems operating in this 314 mode are commonly called "recursive servers". Sometimes they are 315 called "recursive resolvers". While strictly the difference between 316 these is that one of them sends queries to another recursive server 317 and the other does not, in practice it is not possible to know in 318 advance whether the server that one is querying will also perform 319 recursion; both terms can be observed in use interchangeably. 321 Priming -- The mechanism used by a resolvrer to determine where to 322 send queries before there is anything in the resolver's cache. 323 Priming is most often done from a configuration setting that contains 324 a list of authoritative servers for the DNS root zone. 326 Negative caching -- The storage of knowledge that something does not 327 exist, cannot give an answer, or does not give an answer. (Quoted 328 from Section 1 of RFC 2308) 330 Authoritative server -- A system that responds to DNS queries with 331 information about zones for which it has been configured to answer 332 with the AA flag in the response header set to 1. It is a server 333 that has authority over one or more DNS zones. Note that it is 334 possible for an authoritative server to respond to a query without 335 the parent zone delegating authority to that server. 337 Slave -- An authoritative server which uses zone transfer to retrieve 338 the zone. (Quoted from [RFC1996], section 2.1) 340 Master -- Any authoritative server configured to be the source of 341 zone transfer for one or more slave servers. (Quoted from RFC 1996, 342 section 2.1) 344 Primary master -- The primary master is named in the zone's SOA MNAME 345 field and optionally by an NS resource record. (Quoted from RFC 346 1996, section 2.1) 348 Stealth server -- This is the same as a slave server except that it 349 is not listed in an NS resource record for the zone. (Quoted from 350 RFC 1996, section 2.1) A stealth server is often actually a master 351 for zone transfers, and in that case is called a "hidden master". 353 Zone transfer -- The act of a client requesting a copy of a zone and 354 an authoritative server sending the needed information. There are 355 two common standard ways to do zone transfers: the AXFR 356 ("Authoritative Transfer") mechanism to copy the full zone, and the 357 IXFR ("Incremental Transfer") mechanism to copy only parts of the 358 zone that have changed. Many systems use non-standard methods for 359 zone transfer outside the DNS protocol. 361 DNS forwarder -- A system that receives a DNS query, possibly changes 362 the query, sends the resulting query to a recursive resolver, 363 receives the response from a resolver, possibly changes the response, 364 and sends the resulting response to the stub resolver. Section 1 of 365 RFC 2308 describes a forwarder as "a nameserver used to resolve 366 queries instead of directly using the authoritative nameserver 367 chain". RFC further says "The forwarder typically either has better 368 access to the internet, or maintains a bigger cache which may be 369 shared amongst many resolvers." 371 [RFC5625] does not give a specific definition for DNS forwarder, but 372 describes in detail what features they need to support. The protocol 373 interfaces for DNS forwarders are exactly the same as those for 374 recursive resolvers (for interactions with DNS stubs) and as those 375 for stub resolvers (for interactions with recursive resolvers). 377 Full resolver -- This term is used in RFC 1035, but it is not defined 378 there. RFC 1123 defines a "full-service resolver" that may or may 379 not be what was intended by "full resolver" in RFC 1035. In the 380 vernacular, a full-service resolver is usually one that would be 381 suitable for use by a stub resolver. 383 Consensual policy-implementing resolver -- A resolver that changes 384 some answers it returns based on policy criteria, such as to prevent 385 access to malware sites. These policy criteria are agreed to by 386 systems that query this resolver through some out of band mechanism 387 (such as finding out about the resolver from a web site and reading 388 the policy). 390 Non-consensual policy-implementing resolver -- A resolver that is not 391 a consensual policy-implementing resolver that changes the answers it 392 returns. The difference between this and a consensual policy- 393 implementing resolver is that users of this resolver are not expected 394 to know that there is a policy to change the answers it returns. 396 Open resolver -- A full resolver that accepts and processes queries 397 from any (or nearly any) stub resolver. This is sometimes also 398 called a "public resolver". 400 Open forwarder -- A DNS forwarder that accepts and forwards queries 401 from any (or nearly any) stub resolver to a full resolver. 403 Views -- A view is a configuration for a server that allows it to 404 provide different answers depending on the address on the query. 405 Views are often used to provide more names or different addresses to 406 queries from "inside" a protected network than to those "outside" 407 that network. Views are not a standardized part of the DNS, but they 408 are widely implemented in server software. 410 Passive DNS -- A mechanism to collect large amounts of DNS data by 411 storing queries and responses from many recursive resolvers. Passive 412 DNS databases can be used to answer historical questions about DNS 413 zones such as which records were available for them at what times in 414 the past. 416 Child-centric resolver -- A DNS resolver that, instead of serving the 417 NS RRset and glue records that it obtained from the parent of a zone, 418 serves data from the authoritative servers for that zone. The term 419 "child-centric" is meant as the opposite of "parent-centric", which 420 means a resolver that simply serves the NS RRset and glue records for 421 a zone that it obtained from the zone's parent, without checking the 422 authoritative servers for that zone. 424 7. Zones 426 This section defines terms that are used when discussing zones that 427 are being served or retrieved. 429 Zone -- A unit of organization of authoritative data. Zones can be 430 automatically distributed to the name servers which provide redundant 431 service for the data in a zone. (Quoted from RFC 1034, section 2.4). 433 Child -- The entity on record that has the delegation of the domain 434 from the Parent. (Quoted from [RFC7344], section 1.1) 436 Parent -- The domain in which the Child is registered. (Quoted from 437 RFC 7344, section 1.1) Earlier, "parent name server" was defined in 438 [RFC0882] as "the name server that has authority over the place in 439 the domain name space that will hold the new domain". 441 Origin -- 1. The domain name that appears at the top of a zone. 2. 442 The domain name within which a given relative domain name appears in 443 zone files. Generally seen in the context of "$ORIGIN", which is a 444 control entry defined in RFC 1035, section 5.1, as part of the master 445 file format. For example, if the $ORIGIN is set to "example.org.", 446 then a master file line for "www" is in fact an entry for 447 "www.example.org.". 449 Zone cut -- The delimitation point between two zones where the origin 450 of one of the zones is the child of the other zone. (Section 6 of 451 RFC 2181 uses this term extensively, although never actually defines 452 it.) Section 4.2 of RFC 1034 uses "cuts" as "zone cut". 454 Apex -- The point in the tree at an owner of an SOA and corresponding 455 authoritative NS RRset. This is also called the "zone apex". The 456 "apex" is a data-theoretic description of a tree structure, and 457 "origin" is the name of the same concept when it is implemented in 458 zone files. 460 Delegation -- The process by which a separate zone is created in the 461 name space beneath the apex of a given domain. Delegation happens 462 when an NS RRset is added in the parent zone for the child origin, 463 and a corresponding zone apex is created at the child origin. 464 Delegation inherently happens at a zone cut. 466 In-bailiwick response -- A response in which the name server 467 answering is authoritative for an ancestor of the owner name in the 468 response. The term normally is used when discussing the relevancy of 469 glue records. For example, the parent zone example.com might reply 470 with glue records for ns.child.example.com. Because the 471 child.example.com zone is a descendant of the example.com zone, the 472 glue is in-bailiwick. 474 Out-of-bailiwick response -- A response in which the name server 475 answering is not authoritative for an ancestor of the owner name in 476 the response. 478 Authoritative data -- All of the RRs attached to all of the nodes 479 from the top node of the zone down to leaf nodes or nodes above cuts 480 around the bottom edge of the zone. (Quoted from Section 4.2.1 of 481 RFC 1034) It is noted that this definition might inadvertently also 482 include any NS records that appear in the zone, even those that might 483 not truly be authoritative because there are identical NS RRs below 484 the zone cut. This reveals the ambiguity in the notion of 485 authoritative data, because the parent-size NS records 486 authoritatively indicate the delegation, even though they are not 487 themselves authoritative data. 489 Root zone -- The zone whose origin is the zero-length label. Also 490 sometimes called "the DNS root". 492 Empty non-terminal -- A domain name that has no RRsets, but has 493 descendants that have RRsets. A typical example is in SRV records: 494 in the name "_sip._tcp.example.com", it is likely that 495 "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com" 496 has (at least) an SRV RRset. 498 Delegation-centric zone -- A zone which consists mostly of 499 delegations to child zones. This term is used in contrast to a zone 500 which might have some delegations to child zones, but also has many 501 data resource records for the zone itself and/or for child zones. 503 Wildcard -- RFC 1034 defined "wildcard", but in a way that turned out 504 to be confusing to implementers. For an extended discussion of 505 wildcards, including clearer definitions, see [RFC4592]. 507 Occluded name -- The addition of a delegation point via dynamic 508 update will render all subordinate domain names to be in a limbo, 509 still part of the zone but not available to the lookup process. The 510 addition of a DNAME resource record has the same impact. The 511 subordinate names are said to be "occluded". (Quoted from [RFC5936], 512 Section 3.5) 514 8. Registration Model 516 Registry -- The administrative operation of a zone that allows 517 registration of names within that zone. 519 Registrant -- An individual or organization on whose behalf a name in 520 a zone is registered by the registry. In many zones, the registry 521 and the registrant may be the same entity, but in TLDs they often are 522 not. 524 Registrar -- A service provider that acts as a go-between for 525 registrants and registries. Not all registrations require a 526 registrar, though it is common to have registrars be involved in 527 registrations in TLDs. 529 EPP -- The Extensible Provisioning Protocol (EPP), which is commonly 530 used for communication of registration information between registries 531 and registrars. EPP is defined in [RFC5730]. 533 9. General DNSSEC 535 Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035]. 536 The terms that have caused confusion in the DNS community are 537 highlighted here. 539 DNSSEC-aware and DNSSEC-unaware -- Section 2 of RFC 4033 defines many 540 types of resolvers and validators. In specific, the terms "non- 541 validating security-aware stub resolver", "non-validating stub 542 resolver", "security-aware name server", "security-aware recursive 543 name server", "security-aware resolver", "security-aware stub 544 resolver", and "security-oblivious 'anything'" are all defined. 546 Signed zone -- A zone whose RRsets are signed and that contains 547 properly constructed DNSKEY, Resource Record Signature (RRSIG), Next 548 Secure (NSEC), and (optionally) DS records. (Quoted from RFC 4033, 549 section 2) It has been noted in other contexts that the zone itself 550 is not really signed, but all the relevant RRsets in the zone are 551 signed. It should also be noted that, since the publication of 552 [RFC6840], NSEC records are no longer required for signed zones: a 553 signed zone might include NSEC3 records instead. 555 Unsigned zone -- Section 2 of RFC 4033 defines this as "a zone that 556 is not signed". Section 2 of RFC 4035 defines this as "A zone that 557 does not include these records [properly constructed DNSKEY, Resource 558 Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS 559 records] according to the rules in this section". There is an 560 important note at the end of Section 5.2 of RFC 4035 adding an 561 additional situation when a zone is considered unsigned: "If the 562 resolver does not support any of the algorithms listed in an 563 authenticated DS RRset, then the resolver will not be able to verify 564 the authentication path to the child zone. In this case, the 565 resolver SHOULD treat the child zone as if it were unsigned." 567 NSEC -- The NSEC resource record lists two separate things: the next 568 owner name (in the canonical ordering of the zone) that contains 569 authoritative data or a delegation point NS RRset, and the set of RR 570 types present at the NSEC RR's owner name. (Quoted from Section 4 of 571 4034) 573 NSEC3 -- The NSEC3 resource record is quite different than the NSEC 574 resource record. NSEC3 resource records are defined in [RFC5155]. 576 Opt-out -- The Opt-Out Flag indicates whether this NSEC3 RR may cover 577 unsigned delegations. (Quoted from Section 3.1.2.1 of RFC 5155) 579 DNSSEC Policy (DP) -- A statement that sets forth the security 580 requirements and standards to be implemented for a DNSSEC-signed 581 zone. (Quoted from [RFC6841], section 2) 583 DNSSEC Practice Statement (DPS) -- A practices disclosure document 584 that may support and be a supplemental document to the DNSSEC Policy 585 (if such exists), and it states how the management of a given zone 586 implements procedures and controls at a high level. (Quoted from RFC 587 6841, section 2) 589 Key signing key (KSK) -- DNSSEC keys that only sign the apex DNSKEY 590 RRset in a zone. (Quoted from [RFC6781], Section 3.1) 592 Zone signing key (ZSK) -- DNSSEC keys that can be used to sign all 593 the RRsets in a zone that require signatures, other than the apex 594 DNSKEY RRset. (Quoted from RFC 6781, Section 3.1) 596 10. DNSSEC States 598 A validating resolver can determine that a response is in one of four 599 states: secure, insecure, bogus, or indeterminate. These states are 600 defined in RFC 4033 and 4035, although the two definitions differ a 601 bit. 603 Section 5 of RFC 4033 says: 605 A validating resolver can determine the following 4 states: 607 Secure: The validating resolver has a trust anchor, has a chain of 608 trust, and is able to verify all the signatures in the response. 610 Insecure: The validating resolver has a trust anchor, a chain of 611 trust, and, at some delegation point, signed proof of the 612 non-existence of a DS record. This indicates that subsequent 613 branches in the tree are provably insecure. A validating resolver 614 may have a local policy to mark parts of the domain space as 615 insecure. 617 Bogus: The validating resolver has a trust anchor and a secure 618 delegation indicating that subsidiary data is signed, but the 619 response fails to validate for some reason: missing signatures, 620 expired signatures, signatures with unsupported algorithms, data 621 missing that the relevant NSEC RR says should be present, and so 622 forth. 624 Indeterminate: There is no trust anchor that would indicate that a 625 specific portion of the tree is secure. This is the default 626 operation mode. 628 Section 4.3 of RFC 4035 says: 630 A security-aware resolver must be able to distinguish between four 631 cases: 633 Secure: An RRset for which the resolver is able to build a chain of 634 signed DNSKEY and DS RRs from a trusted security anchor to the 635 RRset. In this case, the RRset should be signed and is subject to 636 signature validation, as described above. 638 Insecure: An RRset for which the resolver knows that it has no chain 639 of signed DNSKEY and DS RRs from any trusted starting point to the 640 RRset. This can occur when the target RRset lies in an unsigned 641 zone or in a descendent of an unsigned zone. In this case, the 642 RRset may or may not be signed, but the resolver will not be able 643 to verify the signature. 645 Bogus: An RRset for which the resolver believes that it ought to be 646 able to establish a chain of trust but for which it is unable to 647 do so, either due to signatures that for some reason fail to 648 validate or due to missing data that the relevant DNSSEC RRs 649 indicate should be present. This case may indicate an attack but 650 may also indicate a configuration error or some form of data 651 corruption. 653 Indeterminate: An RRset for which the resolver is not able to 654 determine whether the RRset should be signed, as the resolver is 655 not able to obtain the necessary DNSSEC RRs. This can occur when 656 the security-aware resolver is not able to contact security-aware 657 name servers for the relevant zones. 659 11. IANA Considerations 661 This document has no effect on IANA registries. 663 12. Security Considerations 665 These definitions do not change any security considerations for the 666 DNS. 668 13. Acknowledgements 670 The authors gratefully acknowledge all of the authors of DNS-related 671 RFCs that proceed this one. Comments from Tony Finch, Stephane 672 Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John 673 Kristoff, and others have helped shape this document. [[ More acks 674 will go here as people point out new terms to add and changes to the 675 ones we have listed here. ]] 677 14. References 679 14.1. Normative References 681 [ISO3166] International Organization for Standardization (ISO), 682 "Country Codes - ISO 3166", February 2015, 683 . 685 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 686 RFC 882, November 1983. 688 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 689 STD 13, RFC 1034, November 1987. 691 [RFC1035] Mockapetris, P., "Domain names - implementation and 692 specification", STD 13, RFC 1035, November 1987. 694 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 695 and Support", STD 3, RFC 1123, October 1989. 697 [RFC1206] Malkin, G. and A. Marine, "FYI on Questions and Answers: 698 Answers to commonly asked "new Internet user" questions", 699 RFC 1206, February 1991. 701 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 702 Changes (DNS NOTIFY)", RFC 1996, August 1996. 704 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 705 Specification", RFC 2181, July 1997. 707 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 708 NCACHE)", RFC 2308, March 1998. 710 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 711 Rose, "DNS Security Introduction and Requirements", RFC 712 4033, March 2005. 714 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 715 Rose, "Resource Records for the DNS Security Extensions", 716 RFC 4034, March 2005. 718 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 719 Rose, "Protocol Modifications for the DNS Security 720 Extensions", RFC 4035, March 2005. 722 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 723 System", RFC 4592, July 2006. 725 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 726 Security (DNSSEC) Hashed Authenticated Denial of 727 Existence", RFC 5155, March 2008. 729 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 730 STD 69, RFC 5730, August 2009. 732 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 733 (AXFR)", RFC 5936, June 2010. 735 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 736 Operational Practices, Version 2", RFC 6781, December 737 2012. 739 [RFC6840] Weiler, S. and D. Blacka, "Clarifications and 740 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 741 February 2013. 743 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 744 Framework for DNSSEC Policies and DNSSEC Practice 745 Statements", RFC 6841, January 2013. 747 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 748 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 750 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 751 DNSSEC Delegation Trust Maintenance", RFC 7344, September 752 2014. 754 14.2. Informative References 756 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 757 host table specification", RFC 952, October 1985. 759 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 760 152, RFC 5625, August 2009. 762 [RFC5890] Klensin, J., "Internationalized Domain Names for 763 Applications (IDNA): Definitions and Document Framework", 764 RFC 5890, August 2010. 766 [RFC5891] Klensin, J., "Internationalized Domain Names in 767 Applications (IDNA): Protocol", RFC 5891, August 2010. 769 [RFC5892] Faltstrom, P., "The Unicode Code Points and 770 Internationalized Domain Names for Applications (IDNA)", 771 RFC 5892, August 2010. 773 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 774 Internationalized Domain Names for Applications (IDNA)", 775 RFC 5893, August 2010. 777 [RFC5894] Klensin, J., "Internationalized Domain Names for 778 Applications (IDNA): Background, Explanation, and 779 Rationale", RFC 5894, August 2010. 781 Authors' Addresses 783 Paul Hoffman 784 VPN Consortium 785 127 Segre Place 786 Santa Cruz, CA 95060 787 USA 789 Email: paul.hoffman@vpnc.org 791 Andrew Sullivan 792 Dyn 793 150 Dow St, Tower 2 794 Manchester, NH 1604 795 USA 797 Email: asullivan@dyn.com 799 Kazunori Fujiwara 800 Japan Registry Services Co., Ltd. 801 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 802 Chiyoda-ku, Tokyo 101-0065 803 Japan 805 Phone: +81 3 5215 8451 806 Email: fujiwara@jprs.co.jp