idnits 2.17.1 draft-ietf-dnsop-dns-terminology-01.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 655: '... 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 29, 2015) is 3285 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 31, 2015 Dyn 6 K. Fujiwara 7 JPRS 8 April 29, 2015 10 DNS Terminology 11 draft-ietf-dnsop-dns-terminology-01 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 31, 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. There is no 175 indication in a domaine name whether or not it is a public suffix; 176 that can only be determined by outside means. The IETF DBOUND 177 Working Group [DBOUND] deals with issues with public suffixes. 179 For example, at the time this document is published, .com.au is 180 considered a public suffix, but .au is not. Note that this term is 181 controversial in the DNS community for many reasons, and may be 182 significantly changed in the future. One example of the difficulty 183 of calling a domain a public suffix is that designation can change 184 over time as the registration policy for the zone changes, such as 185 the case of the .uk zone around the time this document is published. 187 3. DNS Header and Response Codes 189 The header of a DNS message is first 12 octets. Many of the fields 190 and flags in the header diagram in section 4.1.1 of [RFC1035] are 191 referred to by their names in that diagram. For example, the 192 response codes are called "RCODEs", and the authoritative answer bit 193 is often called "the AA flag" or "the AA bit". 195 Some of response codes that are defined in [RFC1035] have gotten 196 their own shorthand names. Some common response code names that 197 appear without reference to the numeric value are "FORMERR", 198 "SERVFAIL", and "NXDOMAIN". All of the RCODEs are listed at 199 http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml, 200 although that site uses mixed-case capitalization, while most 201 documents use all-caps. 203 NODATA - This is not an actual response code, but is a particular 204 type of response from a server that indicates that the queried domain 205 name exists for the given class, but the resource record type being 206 queried for does not exist. A NODATA response is a combination of an 207 RCODE of 0 (NOERROR) and an Answer section that is empty. In 208 addition, NODATA responses from authoritative servers have the 209 authoritative answer (AA bit) set to 1 and include an SOA record. 210 Section 1 of [RFC2308] defines NODATA as "a pseudo RCODE which 211 indicates that the name is valid, for the given class, but are no 212 records of the given type". The term "NXRRSET" is becoming more 213 common as a synonym for NODATA. 215 Negative response -- A response whose RCODE indicates that a 216 particular RRset does not exist in the DNS or a failure of a 217 nameserver. Sections 2 and 7 of [RFC2308] describes the types of 218 negative responses in detail. 220 4. Resource Records 222 RR -- A short form for resource record. ([RFC1034], section 3.6.) 224 RRset -- A set of resource records with the same label, class and 225 type, but with different data. (Definition from [RFC2181]) Also 226 spelled RRSet in some documents. As a clarification, "same label" in 227 this definition means "same owner name". In addition, [RFC2181] 228 states that "the TTLs of all RRs in an RRSet must be the same". 230 EDNS -- Also commonly called "EDNS0", this is the extension 231 mechanisms for DNS. The extension mechanism, defined in [RFC6891], 232 allows DNS clients and servers to specify message sizes larger than 233 the original 512 octet limit, to expand the response code space, and 234 to potentially carry additional options that affect the handling of a 235 DNS query. 237 OPT -- A pseudo-RR (sometimes called a meta-RR) that is used only to 238 contain control information pertaining to the question-and-answer 239 sequence of a specific transaction. (Definition from [RFC6891], 240 section 6.1.1) It is used by EDNS. 242 Owner -- The domain name where a RR is found ([RFC1034], section 243 3.6). Often appears in the term "owner name". 245 SOA field names -- DNS documents, including the definitions here, 246 often refer to the fields in the RDATA an SOA resource record by 247 field name. Those fields are defined in Section 3.3.13 of [RFC1035]. 248 The names (in the order they appear in the SOA RDATA) are MNAME, 249 RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the 250 meaning of MINIMUM field is updated in Section 4 of [RFC2308]; the 251 new definition is that the MINIMUM field is only "the TTL to be used 252 for negative responses". 254 TTL -- The maximum "time to live" of a resource record. A TTL value 255 is an unsigned number, with a minimum value of 0, and a maximum value 256 of 2147483647. That is, a maximum of 2^31 - 1. When transmitted, 257 the TTL is encoded in the less significant 31 bits of the 32 bit TTL 258 field, with the most significant, or sign, bit set to zero. (Quoted 259 from [RFC2181], section 8) (Note that [RFC1035] erroneously stated 260 that this is a signed integer; it is fixed in an erratum.) 262 The TTL "specifies the time interval that the resource record may be 263 cached before the source of the information should again be 264 consulted". (Quoted from [RFC1035], section 3.2.1) Also: "the time 265 interval (in seconds) that the resource record may be cached before 266 it should be discarded". (Quoted from [RFC1035], section 4.1.3). 267 Despite being defined for a resource record, the TTL of every 268 resource record in an RRset is required to be the same (RFC2181, 269 section 5.2). 271 The reason that the TTL is the maximum time to live is that a cache 272 operator might decide to shorten the time to live for operational 273 purposes, such as if there is a policy to not allow TTL values over a 274 certain number. Also, if a value is flushed from the cache when its 275 value is still positive, the value effectively becomes zero. Some 276 servers do not honor the TTL on an RRset from the authoritative 277 servers, such as when when the authoritative data has a very short 278 TTL. 280 There is also the concept of a "default TTL" for a zone, which can be 281 a configuration parameter in the server software. This is often 282 expressed by a default for the entire server, and a default for a 283 zone using the $TTL directive in a zone file. The $TTL directive was 284 added to the master file format by [RFC2308]. 286 5. DNS Servers 288 This section defines the terms used for the systems that act as DNS 289 clients, DNS servers, or both. Some terms about servers describe 290 servers that do and do not use DNSSEC; see Section 8 for those 291 definitions. 293 [[ There is a request to "first describe the iterative and recursive 294 resolution processes, and mention the expected values of the RD,RA,AA 295 bits. Then you can describe the distinctions between recursive and 296 iterative clients, and between recursive and authoritative servers, 297 in terms of the roles they play in the different resolution 298 processes." This would require the section to be quite different 299 than the other sections in the document. ]] 301 Resolver -- A program that extracts information from name servers in 302 response to client requests. (Quoted from [RFC1034], section 2.4) It 303 is a program that interfaces user programs to domain name servers. 304 The resolver is located on the same machine as the program that 305 requests the resolver's services. (Quoted from [RFC1034], section 306 5.1) A resolver performs queries for a name, type, and class, and 307 receives answers. The logical function is called "resolution". In 308 practice, the term is usually referring to some specific type of 309 resolver (some of which are defined below), and understanding the use 310 of the term depends on understanding the context. 312 Stub resolver -- A resolver that cannot perform all resolution 313 itself. Stub resolvers generally depend on a recursive resolver to 314 undertake the actual resolution function. Stub resolvers are 315 discussed but never fully defined in Section 5.3.1 of [RFC1034]. 316 They are fully defined in Section 6.1.3.1 of [RFC1123]. 318 Iterative mode -- A resolution mode of a server that receives DNS 319 queries and responds with a referral to another server. Section 2.3 320 of [RFC1034] describes this as "The server refers the client to 321 another server and lets the client pursue the query". A resolver 322 that works in iterative mode is sometimes called an "iterative 323 resolver". 325 Recursive mode -- A resolution mode of a server that receives DNS 326 queries and either responds to those queries from a local cache or 327 sends queries to other servers in order to get the final answers to 328 the original queries. Section 2.3 of [RFC1034] describes this as 329 "The first server pursues the query for the client at another 330 server". A server operating in recursive mode may be thought of as 331 having a name server side (which is what answers the query) and a 332 resolver side (which performs the resolution function). Systems 333 operating in this mode are commonly called "recursive servers". 335 Sometimes they are called "recursive resolvers". While strictly the 336 difference between these is that one of them sends queries to another 337 recursive server and the other does not, in practice it is not 338 possible to know in advance whether the server that one is querying 339 will also perform recursion; both terms can be observed in use 340 interchangeably. Resolvers acting in recursive mode are also 341 sometimes called "caching servers". 343 Full resolver -- This term is used in [RFC1035], but it is not 344 defined there. RFC 1123 defines a "full-service resolver" that may 345 or may not be what was intended by "full resolver" in [RFC1035]. 347 Full-service resolver -- Section 6.1.3.1 of [RFC1123] defines this 348 term to mean a resolver that acts in recursive mode with a cache, as 349 well as other requirements. 351 Priming -- The mechanism used by a resolver to determine where to 352 send queries before there is anything in the resolver's cache. 353 Priming is most often done from a configuration setting that contains 354 a list of authoritative servers for the DNS root zone. 356 Negative caching -- The storage of knowledge that something does not 357 exist, cannot give an answer, or does not give an answer. (Quoted 358 from Section 1 of [RFC2308]) 360 Authoritative server -- A system that responds to DNS queries with 361 information about zones for which it has been configured to answer 362 with the AA flag in the response header set to 1. It is a server 363 that has authority over one or more DNS zones. Note that it is 364 possible for an authoritative server to respond to a query without 365 the parent zone delegating authority to that server. Authoritative 366 servers also provide "referrals", usually to child zones delegated 367 from them; these referrals have the AA bit set to 0 and come with 368 referral data in the Authority and (if needed) the Additional 369 sections. 371 Secondary server -- "An authoritative server which uses zone transfer 372 to retrieve the zone" (quoted from [RFC1996], section 2.1). 373 [RFC2182] describes secondary servers in detail. Although early DNS 374 RFCs such as [RFC1996] referred to this as a "slave", the current 375 common usage has shifted to calling it a "secondary". 377 Slave server -- See secondary server. 379 Primary server -- "Any authoritative server configured to be the 380 source of zone transfer for one or more [secondary] servers" (quoted 381 from [RFC1996], section 2.1) or, more specifically, "an authoritative 382 server configured to be the source of AXFR or IXFR data for one or 383 more [secondary] servers" (quoted from [RFC2136]). Although early 384 DNS RFCs such as [RFC1996] referred to this as a "master", the 385 current common usage has shifted to "primary". 387 Master server -- See primary server. 389 Primary master -- The primary master is named in the zone's SOA MNAME 390 field and optionally by an NS resource record. (Quoted from 391 [RFC1996], section 2.1) [RFC2136] defines "primary master" as "Master 392 server at the root of the AXFR/IXFR dependency graph. The primary 393 master is named in the zone's SOA MNAME field and optionally by an NS 394 RR. There is by definition only one primary master server per zone." 396 Stealth server -- This is the same as a slave server except that it 397 is not listed in an NS resource record for the zone. (Quoted from 398 [RFC1996], section 2.1) A stealth server is often actually a master 399 for zone transfers, and in that case is called a "hidden master". 401 Zone transfer -- The act of a client requesting a copy of a zone and 402 an authoritative server sending the needed information. There are 403 two common standard ways to do zone transfers: the AXFR 404 ("Authoritative Transfer") mechanism to copy the full zone, and the 405 IXFR ("Incremental Transfer") mechanism to copy only parts of the 406 zone that have changed. Many systems use non-standard methods for 407 zone transfer outside the DNS protocol. 409 Forwarding -- The process of one server sending a DNS query with the 410 RD bit set to 1 to another server to resolve that query. Forwarding 411 is a function of a DNS resolver; it is different than simply blindly 412 relaying queries. 414 [RFC5625] does not give a specific definition for forwarding, but 415 describes in detail what features a system that forwards need to 416 support. Systems that forward are sometimes called "DNS proxies", 417 but that term has not yet been defined (even in [RFC5625]). 419 Forwarder -- Section 1 of [RFC2308] describes a forwarder as "a 420 nameserver used to resolve queries instead of directly using the 421 authoritative nameserver chain". [RFC2308] further says "The 422 forwarder typically either has better access to the internet, or 423 maintains a bigger cache which may be shared amongst many resolvers." 424 That definition appears to suggest that forwarders normally only 425 query authoritative servers. In current use, however, forwarders 426 often stand between stub resolvers and recursive servers. [RFC2308] 427 is silent on whether a forwarder is iterative-only or can be a full 428 resolver. 430 Policy-implementing resolver -- A resolver acting in recursive mode 431 that changes some of the answers that it returns based on policy 432 criteria, such as to prevent access to malware sites or objectionable 433 content. In general, a stub resolver has no idea whether or not 434 upstream resolvers implement such policy or, if they do, the exact 435 policy about what changes will be made. In some cases, the user of 436 the stub resolver has selected the policy-implementing resolver with 437 the explicit intention of using it to implement the policies. In 438 other cases, policies are imposed without the user of the stub 439 resolver being informed. 441 Open resolver -- A full resolver that accepts and processes queries 442 from any (or nearly any) stub resolver. This is sometimes also 443 called a "public resolver". 445 View -- A configuration for a DNS server that allows it to provide 446 different answers depending on attributes of the query. Typically, 447 views differ by the source IP address of a query, but can also be 448 based on the destination IP address, the type of query (such as 449 AXFR), and so on. Views are often used to provide more names or 450 different addresses to queries from "inside" a protected network than 451 to those "outside" that network. Views are not a standardized part 452 of the DNS, but they are widely implemented in server software. 454 Passive DNS -- A mechanism to collect large amounts of DNS data by 455 storing DNS responses from servers. Some of these systems also 456 collect the DNS queries associated with the responses; this can raise 457 privacy issues. Passive DNS databases can be used to answer 458 historical questions about DNS zones such as which records were 459 available for them at what times in the past. Passive DNS databases 460 allow searching of the stored records on keys other than just the 461 name, such as "find all names which have A records of a particular 462 value". 464 Child-centric resolver -- A DNS resolver that, instead of serving the 465 NS RRset and glue records that it obtained from the parent of a zone, 466 serves data from the authoritative servers for that zone. The term 467 "child-centric" is meant as the opposite of "parent-centric", which 468 means a resolver that simply serves the NS RRset and glue records for 469 a zone that it obtained from the zone's parent, without checking the 470 authoritative servers for that zone. 472 6. Zones 474 This section defines terms that are used when discussing zones that 475 are being served or retrieved. 477 Zone -- A unit of organization of authoritative data. Zones can be 478 automatically distributed to the name servers which provide redundant 479 service for the data in a zone. (Quoted from [RFC1034], section 480 2.4). 482 Child -- The entity on record that has the delegation of the domain 483 from the Parent. (Quoted from [RFC7344], section 1.1) 485 Parent -- The domain in which the Child is registered. (Quoted from 486 [RFC7344], section 1.1) Earlier, "parent name server" was defined in 487 [RFC0882] as "the name server that has authority over the place in 488 the domain name space that will hold the new domain". 490 Origin -- 1. The domain name that appears at the top of a zone. 2. 491 The domain name within which a given relative domain name appears in 492 zone files. Generally seen in the context of "$ORIGIN", which is a 493 control entry defined in [RFC1035], section 5.1, as part of the 494 master file format. For example, if the $ORIGIN is set to 495 "example.org.", then a master file line for "www" is in fact an entry 496 for "www.example.org.". 498 Zone cut -- The delimitation point between two zones where the origin 499 of one of the zones is the child of the other zone. (Section 6 of 500 [RFC2181] uses this term extensively, although never actually defines 501 it.) Section 4.2 of [RFC1034] uses "cuts" as "zone cut". 503 Apex -- The point in the tree at an owner of an SOA and corresponding 504 authoritative NS RRset. This is also called the "zone apex". 505 [RFC4033] defines it as "the name at the child's side of a zone cut". 506 The "apex" can usefully be thought of as a data-theoretic description 507 of a tree structure, and "origin" is the name of the same concept 508 when it is implemented in zone files. The distinction is not always 509 maintained in use, however, and one can find uses that conflict 510 subtly with this definition. 512 Delegation -- The process by which a separate zone is created in the 513 name space beneath the apex of a given domain. Delegation happens 514 when an NS RRset is added in the parent zone for the child origin, 515 and a corresponding zone apex is created at the child origin. 516 Delegation inherently happens at a zone cut. 518 Referrals -- Data from the authority section of a non-authoritative 519 answer. [RFC1035] section 2.1 defines "authoritative" data. 520 However, referrals at zone cuts are not authoritative. Referrals may 521 be a zone cut NS resource records and their glue. NS records on the 522 parent side of a zone cut are an authoritative delegation, but are 523 normally not treated as authoritative data by the client. In 524 general, a referral is a way for a server to send an answer saying 525 that the server does not know the answer, but knows where the query 526 should be directed in order to get an answer. Historically, many 527 authoritative servers answered with a referral to the root zone when 528 queried for a name for which they were not authoritative, but this 529 practice has declined. 531 Glue records -- Resource records which are not part of the 532 authoritative data [for a zone], and are address resource records for 533 the servers [in a subzone]. These RRs are only necessary if the name 534 server's name is "below" the cut, and are only used as part of a 535 referral response. (Definition from [RFC1034], section 4.2.1) 537 A later definition is that glue "includes any record in a zone file 538 that is not properly part of that zone, including nameserver records 539 of delegated sub-zones (NS records), address records that accompany 540 those NS records (A, AAAA, etc), and any other stray data that might 541 appear". (Definition from [RFC2181], section 5.4.1) This definition 542 in [RFC2181] is wider than the one from [RFC1034], and bases the 543 definition on the contents of a zone file. Some implementers might 544 only be thinking about the earlier definition when they see rules 545 about glue records. 547 In-bailiwick - 1. An adjective to describe a name server the name of 548 which is either subordinate to or (rarely) the same as the zone 549 origin. In-bailiwick name servers require glue in their parent zone. 550 2. Data for which the server is either authoritative, or else 551 authoritative for an ancestor of the owner name. This sense of the 552 term normally is used when discussing the relevancy of glue records 553 in a response. For example, the server for the parent zone 554 example.com might reply with glue records for ns.child.example.com. 555 Because the child.example.com zone is a descendant of the example.com 556 zone, the glue records are in-bailiwick. 558 Out-of-bailiwick - The antonym of in-bailiwick. 560 Authoritative data -- All of the RRs attached to all of the nodes 561 from the top node of the zone down to leaf nodes or nodes above cuts 562 around the bottom edge of the zone. (Quoted from Section 4.2.1 of 563 [RFC1034]) It is noted that this definition might inadvertently also 564 include any NS records that appear in the zone, even those that might 565 not truly be authoritative because there are identical NS RRs below 566 the zone cut. This reveals the ambiguity in the notion of 567 authoritative data, because the parent-size NS records 568 authoritatively indicate the delegation, even though they are not 569 themselves authoritative data. 571 Root zone -- The zone whose origin is the zero-length label. Also 572 sometimes called "the DNS root". 574 Empty non-terminal -- A domain name that has no RRsets, but has 575 descendants that have RRsets. A typical example is in SRV records: 576 in the name "_sip._tcp.example.com", it is likely that 577 "_tcp.example.com" has no RRsets, but that "_sip._tcp.example.com" 578 has (at least) an SRV RRset. 580 Delegation-centric zone -- A zone which consists mostly of 581 delegations to child zones. This term is used in contrast to a zone 582 which might have some delegations to child zones, but also has many 583 data resource records for the zone itself and/or for child zones. 585 Wildcard -- [RFC1034] defined "wildcard", but in a way that turned 586 out to be confusing to implementers. For an extended discussion of 587 wildcards, including clearer definitions, see [RFC4592]. 589 Occluded name -- The addition of a delegation point via dynamic 590 update will render all subordinate domain names to be in a limbo, 591 still part of the zone but not available to the lookup process. The 592 addition of a DNAME resource record has the same impact. The 593 subordinate names are said to be "occluded". (Quoted from [RFC5936], 594 Section 3.5) 596 Fast flux DNS -- A mechanism where a large number of hosts rapidly 597 update the address records of a zone, often to deliver malware. 598 Because the addresses change so rapidly, it is difficult to 599 definitively find all the hosts. 601 7. Registration Model 603 Registry -- The administrative operation of a zone that allows 604 registration of names within that zone. 606 Registrant -- An individual or organization on whose behalf a name in 607 a zone is registered by the registry. In many zones, the registry 608 and the registrant may be the same entity, but in TLDs they often are 609 not. 611 Registrar -- A service provider that acts as a go-between for 612 registrants and registries. Not all registrations require a 613 registrar, though it is common to have registrars be involved in 614 registrations in TLDs. 616 EPP -- The Extensible Provisioning Protocol (EPP), which is commonly 617 used for communication of registration information between registries 618 and registrars. EPP is defined in [RFC5730]. 620 8. General DNSSEC 622 Most DNSSEC terms are defined in [RFC4033], [RFC4034], and [RFC4035]. 623 The terms that have caused confusion in the DNS community are 624 highlighted here. 626 DNSSEC-aware and DNSSEC-unaware -- Section 2 of [RFC4033] defines 627 many types of resolvers and validators. In specific, the terms "non- 628 validating security-aware stub resolver", "non-validating stub 629 resolver", "security-aware name server", "security-aware recursive 630 name server", "security-aware resolver", "security-aware stub 631 resolver", and "security-oblivious 'anything'" are all defined. 632 (Note that the term "validating resolver", which is used in some 633 places in those documents, is nevertheless not defined in that 634 section.) 636 Signed zone -- A zone whose RRsets are signed and that contains 637 properly constructed DNSKEY, Resource Record Signature (RRSIG), Next 638 Secure (NSEC), and (optionally) DS records. (Quoted from [RFC4033], 639 section 2) It has been noted in other contexts that the zone itself 640 is not really signed, but all the relevant RRsets in the zone are 641 signed. It should also be noted that, since the publication of 642 [RFC6840], NSEC records are no longer required for signed zones: a 643 signed zone might include NSEC3 records instead. 645 Unsigned zone -- Section 2 of [RFC4033] defines this as "a zone that 646 is not signed". Section 2 of [RFC4035] defines this as "A zone that 647 does not include these records [properly constructed DNSKEY, Resource 648 Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS 649 records] according to the rules in this section". There is an 650 important note at the end of Section 5.2 of [RFC4035] adding an 651 additional situation when a zone is considered unsigned: "If the 652 resolver does not support any of the algorithms listed in an 653 authenticated DS RRset, then the resolver will not be able to verify 654 the authentication path to the child zone. In this case, the 655 resolver SHOULD treat the child zone as if it were unsigned." 657 NSEC -- "The NSEC record allows a security-aware resolver to 658 authenticate a negative reply for either name or type non-existence 659 with the same mechanisms used to authenticate other DNS replies." 660 (Quoted from Section 3.2 of [RFC4033]) In short, an NSEC record 661 provides authenticated denial of existence. 663 The NSEC resource record lists two separate things: the next owner 664 name (in the canonical ordering of the zone) that contains 665 authoritative data or a delegation point NS RRset, and the set of RR 666 types present at the NSEC RR's owner name. (Quoted from Section 4 of 667 4034) 668 NSEC3 -- The NSEC3 resource record is quite different than the NSEC 669 resource record. Like the NSEC record, the NSEC3 record also 670 provides authenticated denial of existence; however, NSEC3 records 671 mitigates against zone enumeration and support Opt-Out. NSEC3 672 resource records are defined in [RFC5155]. 674 Opt-out -- The Opt-Out Flag indicates whether this NSEC3 RR may cover 675 unsigned delegations. (Quoted from Section 3.1.2.1 of [RFC5155]) 677 Zone enumeration -- The practice of discovering the full content of a 678 zone via successive queries. (Quoted from Section 1.3 of [RFC5155]) 679 This is also sometimes call "zone walking". Zone enumeration is 680 different from zone content guessing where the guesser uses a large 681 dictionary of possible labels and sends successive queries for them, 682 or matches the contents of NSEC3 records against such a dictionary. 684 DNSSEC Policy (DP) -- A statement that sets forth the security 685 requirements and standards to be implemented for a DNSSEC-signed 686 zone. (Quoted from [RFC6841], section 2) 688 DNSSEC Practice Statement (DPS) -- A practices disclosure document 689 that may support and be a supplemental document to the DNSSEC Policy 690 (if such exists), and it states how the management of a given zone 691 implements procedures and controls at a high level. (Quoted from 692 [RFC6841], section 2) 694 Key signing key (KSK) -- DNSSEC keys that only sign the apex DNSKEY 695 RRset in a zone. (Quoted from [RFC6781], Section 3.1) 697 Zone signing key (ZSK) -- DNSSEC keys that can be used to sign all 698 the RRsets in a zone that require signatures, other than the apex 699 DNSKEY RRset. (Quoted from [RFC6781], Section 3.1) Note that the 700 roles KSK and ZSK are not mutually exclusive: a single key can be 701 both KSK and ZSK at the same time. This is sometimes called a 702 "combined signing key" or CSK. It is operational practice, not 703 protocol, that determines whether a particular key is a ZSK, a KSK, 704 or a CSK. 706 9. DNSSEC States 708 A validating resolver can determine that a response is in one of four 709 states: secure, insecure, bogus, or indeterminate. These states are 710 defined in [RFC4033] and [RFC4035], although the two definitions 711 differ a bit. 713 Section 5 of [RFC4033] says: 715 A validating resolver can determine the following 4 states: 717 Secure: The validating resolver has a trust anchor, has a chain of 718 trust, and is able to verify all the signatures in the response. 720 Insecure: The validating resolver has a trust anchor, a chain of 721 trust, and, at some delegation point, signed proof of the 722 non-existence of a DS record. This indicates that subsequent 723 branches in the tree are provably insecure. A validating resolver 724 may have a local policy to mark parts of the domain space as 725 insecure. 727 Bogus: The validating resolver has a trust anchor and a secure 728 delegation indicating that subsidiary data is signed, but the 729 response fails to validate for some reason: missing signatures, 730 expired signatures, signatures with unsupported algorithms, data 731 missing that the relevant NSEC RR says should be present, and so 732 forth. 734 Indeterminate: There is no trust anchor that would indicate that a 735 specific portion of the tree is secure. This is the default 736 operation mode. 738 Section 4.3 of [RFC4035] says: 740 A security-aware resolver must be able to distinguish between four 741 cases: 743 Secure: An RRset for which the resolver is able to build a chain of 744 signed DNSKEY and DS RRs from a trusted security anchor to the 745 RRset. In this case, the RRset should be signed and is subject to 746 signature validation, as described above. 748 Insecure: An RRset for which the resolver knows that it has no chain 749 of signed DNSKEY and DS RRs from any trusted starting point to the 750 RRset. This can occur when the target RRset lies in an unsigned 751 zone or in a descendent of an unsigned zone. In this case, the 752 RRset may or may not be signed, but the resolver will not be able 753 to verify the signature. 755 Bogus: An RRset for which the resolver believes that it ought to be 756 able to establish a chain of trust but for which it is unable to 757 do so, either due to signatures that for some reason fail to 758 validate or due to missing data that the relevant DNSSEC RRs 759 indicate should be present. This case may indicate an attack but 760 may also indicate a configuration error or some form of data 761 corruption. 763 Indeterminate: An RRset for which the resolver is not able to 764 determine whether the RRset should be signed, as the resolver is 765 not able to obtain the necessary DNSSEC RRs. This can occur when 766 the security-aware resolver is not able to contact security-aware 767 name servers for the relevant zones. 769 10. IANA Considerations 771 This document has no effect on IANA registries. 773 11. Security Considerations 775 These definitions do not change any security considerations for the 776 DNS. 778 12. Acknowledgements 780 The authors gratefully acknowledge all of the authors of DNS-related 781 RFCs that proceed this one. Comments from Tony Finch, Stephane 782 Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John 783 Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, 784 David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, and many 785 others in the DNSOP Working Group have helped shape this document. 787 13. References 789 13.1. Normative References 791 [ISO3166] International Organization for Standardization (ISO), 792 "Country Codes - ISO 3166", February 2015, 793 . 795 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 796 RFC 882, November 1983. 798 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 799 STD 13, RFC 1034, November 1987. 801 [RFC1035] Mockapetris, P., "Domain names - implementation and 802 specification", STD 13, RFC 1035, November 1987. 804 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 805 and Support", STD 3, RFC 1123, October 1989. 807 [RFC1206] Malkin, G. and A. Marine, "FYI on Questions and Answers: 808 Answers to commonly asked "new Internet user" questions", 809 RFC 1206, February 1991. 811 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 812 Changes (DNS NOTIFY)", RFC 1996, August 1996. 814 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 815 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 816 RFC 2136, April 1997. 818 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 819 Specification", RFC 2181, July 1997. 821 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 822 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 823 July 1997. 825 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 826 NCACHE)", RFC 2308, March 1998. 828 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 829 Rose, "DNS Security Introduction and Requirements", RFC 830 4033, March 2005. 832 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 833 Rose, "Resource Records for the DNS Security Extensions", 834 RFC 4034, March 2005. 836 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 837 Rose, "Protocol Modifications for the DNS Security 838 Extensions", RFC 4035, March 2005. 840 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 841 System", RFC 4592, July 2006. 843 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 844 Security (DNSSEC) Hashed Authenticated Denial of 845 Existence", RFC 5155, March 2008. 847 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 848 STD 69, RFC 5730, August 2009. 850 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 851 (AXFR)", RFC 5936, June 2010. 853 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 854 Operational Practices, Version 2", RFC 6781, December 855 2012. 857 [RFC6840] Weiler, S. and D. Blacka, "Clarifications and 858 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 859 February 2013. 861 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A 862 Framework for DNSSEC Policies and DNSSEC Practice 863 Statements", RFC 6841, January 2013. 865 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 866 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 868 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 869 DNSSEC Delegation Trust Maintenance", RFC 7344, September 870 2014. 872 13.2. Informative References 874 [DBOUND] "DBOUND Working Group", 2015, 875 . 877 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 878 host table specification", RFC 952, October 1985. 880 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 881 152, RFC 5625, August 2009. 883 [RFC5890] Klensin, J., "Internationalized Domain Names for 884 Applications (IDNA): Definitions and Document Framework", 885 RFC 5890, August 2010. 887 [RFC5891] Klensin, J., "Internationalized Domain Names in 888 Applications (IDNA): Protocol", RFC 5891, August 2010. 890 [RFC5892] Faltstrom, P., "The Unicode Code Points and 891 Internationalized Domain Names for Applications (IDNA)", 892 RFC 5892, August 2010. 894 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 895 Internationalized Domain Names for Applications (IDNA)", 896 RFC 5893, August 2010. 898 [RFC5894] Klensin, J., "Internationalized Domain Names for 899 Applications (IDNA): Background, Explanation, and 900 Rationale", RFC 5894, August 2010. 902 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 903 April 2011. 905 Authors' Addresses 907 Paul Hoffman 908 VPN Consortium 909 127 Segre Place 910 Santa Cruz, CA 95060 911 USA 913 Email: paul.hoffman@vpnc.org 915 Andrew Sullivan 916 Dyn 917 150 Dow St, Tower 2 918 Manchester, NH 1604 919 USA 921 Email: asullivan@dyn.com 922 Kazunori Fujiwara 923 Japan Registry Services Co., Ltd. 924 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 925 Chiyoda-ku, Tokyo 101-0065 926 Japan 928 Phone: +81 3 5215 8451 929 Email: fujiwara@jprs.co.jp