idnits 2.17.1
draft-ietf-dnsop-rfc8499bis-03.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 :
----------------------------------------------------------------------------
== There are 5 instances of lines with non-RFC2606-compliant FQDNs in the
document.
** 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 603: '... An RRset MAY have multiple RRS...'
RFC 2119 keyword, line 1449: '...se, the resolver SHOULD treat the chil...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC2308, updated by this document, for
RFC5378 checks: 1997-01-17)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (28 September 2021) is 942 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC20' is mentioned on line 1280, but not defined
== Missing Reference: 'DNSSEC' is mentioned on line 1537, but not defined
** Obsolete normative reference: RFC 882 (Obsoleted by RFC 1034, RFC 1035)
** Downref: Normative reference to an Informational RFC: RFC 1912
** Downref: Normative reference to an Informational RFC: RFC 6561
** Downref: Normative reference to an Informational RFC: RFC 6781
** Downref: Normative reference to an Informational RFC: RFC 6841
** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499)
** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
== Outdated reference: A later version (-12) exists of
draft-ietf-dprive-dnsoquic-04
-- Obsolete informational reference (is this intentional?): RFC 3757
(Obsoleted by RFC 4033, RFC 4034, RFC 4035)
-- Obsolete informational reference (is this intentional?): RFC 4641
(Obsoleted by RFC 6781)
-- Obsolete informational reference (is this intentional?): RFC 7482
(Obsoleted by RFC 9082)
-- Obsolete informational reference (is this intentional?): RFC 7483
(Obsoleted by RFC 9083)
-- Obsolete informational reference (is this intentional?): RFC 7484
(Obsoleted by RFC 9224)
Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Hoffman
3 Internet-Draft ICANN
4 Obsoletes: 8499 (if approved) K. Fujiwara
5 Updates: 2308 (if approved) JPRS
6 Intended status: Best Current Practice 28 September 2021
7 Expires: 1 April 2022
9 DNS Terminology
10 draft-ietf-dnsop-rfc8499bis-03
12 Abstract
14 The Domain Name System (DNS) is defined in literally dozens of
15 different RFCs. The terminology used by implementers and developers
16 of DNS protocols, and by operators of DNS systems, has sometimes
17 changed in the decades since the DNS was first defined. This
18 document gives current definitions for many of the terms used in the
19 DNS in a single document.
21 This document obsoletes RFC 8499 and updates RFC 2308.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on 1 April 2022.
40 Copyright Notice
42 Copyright (c) 2021 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents (https://trustee.ietf.org/
47 license-info) in effect on the date of publication of this document.
48 Please review these documents carefully, as they describe your rights
49 and restrictions with respect to this document. Code Components
50 extracted from this document must include Simplified BSD License text
51 as described in Section 4.e of the Trust Legal Provisions and are
52 provided without warranty as described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 3. DNS Response Codes . . . . . . . . . . . . . . . . . . . . . 9
59 4. DNS Transactions . . . . . . . . . . . . . . . . . . . . . . 11
60 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . 13
61 6. DNS Servers and Clients . . . . . . . . . . . . . . . . . . . 16
62 7. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
63 8. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . 28
64 9. Registration Model . . . . . . . . . . . . . . . . . . . . . 29
65 10. General DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 31
66 11. DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . . 35
67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
69 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
70 14.1. Normative References . . . . . . . . . . . . . . . . . . 37
71 14.2. Informative References . . . . . . . . . . . . . . . . . 40
72 Appendix A. Definitions Updated by This Document . . . . . . . . 45
73 Appendix B. Definitions First Defined in This Document . . . . . 45
74 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
75 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
78 1. Introduction
80 The Domain Name System (DNS) is a simple query-response protocol
81 whose messages in both directions have the same format. (Section 2
82 gives a definition of "global DNS", which is often what people mean
83 when they say "the DNS".) The protocol and message format are
84 defined in [RFC1034] and [RFC1035]. These RFCs defined some terms,
85 and later documents defined others. Some of the terms from [RFC1034]
86 and [RFC1035] have somewhat different meanings now than they did in
87 1987.
89 This document contains a collection of a wide variety of DNS-related
90 terms, organized loosely by topic. Some of them have been precisely
91 defined in earlier RFCs, some have been loosely defined in earlier
92 RFCs, and some are not defined in an earlier RFC at all.
94 Other organizations sometimes define DNS-related terms their own way.
95 For example, the WHATWG defines "domain" at
96 . The Root Server System Advisory
97 Committee (RSSAC) has a good lexicon [RSSAC026].
99 Most of the definitions listed here represent the consensus
100 definition of the DNS community -- both protocol developers and
101 operators. Some of the definitions differ from earlier RFCs, and
102 those differences are noted. In this document, where the consensus
103 definition is the same as the one in an RFC, that RFC is quoted.
104 Where the consensus definition has changed somewhat, the RFC is
105 mentioned but the new stand-alone definition is given. See
106 Appendix A for a list of the definitions that this document updates.
108 It is important to note that, during the development of this
109 document, it became clear that some DNS-related terms are interpreted
110 quite differently by different DNS experts. Further, some terms that
111 are defined in early DNS RFCs now have definitions that are generally
112 agreed to, but that are different from the original definitions.
113 This document is a small revision to [RFC8499]; that document was a
114 substantial revision to [RFC7719].
116 Note that there is no single consistent definition of "the DNS". It
117 can be considered to be some combination of the following: a commonly
118 used naming scheme for objects on the Internet; a distributed
119 database representing the names and certain properties of these
120 objects; an architecture providing distributed maintenance,
121 resilience, and loose coherency for this database; and a simple
122 query-response protocol (as mentioned below) implementing this
123 architecture. Section 2 defines "global DNS" and "private DNS" as a
124 way to deal with these differing definitions.
126 Capitalization in DNS terms is often inconsistent among RFCs and
127 various DNS practitioners. The capitalization used in this document
128 is a best guess at current practices, and is not meant to indicate
129 that other capitalization styles are wrong or archaic. In some
130 cases, multiple styles of capitalization are used for the same term
131 due to quoting from different RFCs.
133 Readers should note that the terms in this document are grouped by
134 topic. Someone who is not already familiar with the DNS probably
135 cannot learn about the DNS from scratch by reading this document from
136 front to back. Instead, skipping around may be the only way to get
137 enough context to understand some of the definitions. This document
138 has an index that might be useful for readers who are attempting to
139 learn the DNS by reading this document.
141 2. Names
143 Naming system: A naming system associates names with data. Naming
144 systems have many significant facets that help differentiate them
145 from each other. Some commonly identified facets include:
147 * Composition of names
149 * Format of names
151 * Administration of names
153 * Types of data that can be associated with names
155 * Types of metadata for names
157 * Protocol for getting data from a name
159 * Context for resolving a name
161 Note that this list is a small subset of facets that people have
162 identified over time for naming systems, and the IETF has yet to
163 agree on a good set of facets that can be used to compare naming
164 systems. For example, other facets might include "protocol to
165 update data in a name", "privacy of names", and "privacy of data
166 associated with names", but those are not as well defined as the
167 ones listed above. The list here is chosen because it helps
168 describe the DNS and naming systems similar to the DNS.
170 Domain name: An ordered list of one or more labels.
172 Note that this is a definition independent of the DNS RFCs
173 ([RFC1034] and [RFC1035]), and the definition here also applies to
174 systems other than the DNS. [RFC1034] defines the "domain name
175 space" using mathematical trees and their nodes in graph theory,
176 and that definition has the same practical result as the
177 definition here. Any path of a directed acyclic graph can be
178 represented by a domain name consisting of the labels of its
179 nodes, ordered by decreasing distance from the root(s) (which is
180 the normal convention within the DNS, including this document). A
181 domain name whose last label identifies a root of the graph is
182 fully qualified; other domain names whose labels form a strict
183 prefix of a fully-qualified domain name are relative to its first
184 omitted node.
186 Also note that different IETF and non-IETF documents have used the
187 term "domain name" in many different ways. It is common for
188 earlier documents to use "domain name" to mean "names that match
189 the syntax in [RFC1035]", but possibly with additional rules such
190 as "and are, or will be, resolvable in the global DNS" or "but
191 only using the presentation format".
193 Label: An ordered list of zero or more octets that makes up a
194 portion of a domain name. Using graph theory, a label identifies
195 one node in a portion of the graph of all possible domain names.
197 Global DNS: Using the short set of facets listed in "Naming system",
198 the global DNS can be defined as follows. Most of the rules here
199 come from [RFC1034] and [RFC1035], although the term "global DNS"
200 has not been defined before now.
202 Composition of names: A name in the global DNS has one or more
203 labels. The length of each label is between 0 and 63 octets
204 inclusive. In a fully-qualified domain name, the last label in
205 the ordered list is 0 octets long; it is the only label whose
206 length may be 0 octets, and it is called the "root" or "root
207 label". A domain name in the global DNS has a maximum total
208 length of 255 octets in the wire format; the root represents one
209 octet for this calculation. (Multicast DNS [RFC6762] allows names
210 up to 255 bytes plus a terminating zero byte based on a different
211 interpretation of RFC 1035 and what is included in the 255
212 octets.)
214 Format of names: Names in the global DNS are domain names. There
215 are three formats: wire format, presentation format, and common
216 display.
218 The basic wire format for names in the global DNS is a list of
219 labels ordered by decreasing distance from the root, with the
220 root label last. Each label is preceded by a length octet.
221 [RFC1035] also defines a compression scheme that modifies this
222 format.
224 The presentation format for names in the global DNS is a list
225 of labels ordered by decreasing distance from the root, encoded
226 as ASCII, with a "." character between each label. In
227 presentation format, a fully-qualified domain name includes the
228 root label and the associated separator dot. For example, in
229 presentation format, a fully-qualified domain name with two
230 non-root labels is always shown as "example.tld." instead of
231 "example.tld". [RFC1035] defines a method for showing octets
232 that do not display in ASCII.
234 The common display format is used in applications and free
235 text. It is the same as the presentation format, but showing
236 the root label and the "." before it is optional and is rarely
237 done. For example, in common display format, a fully-qualified
238 domain name with two non-root labels is usually shown as
239 "example.tld" instead of "example.tld.". Names in the common
240 display format are normally written such that the
241 directionality of the writing system presents labels by
242 decreasing distance from the root (so, in both English and the
243 C programming language the root or Top-Level Domain (TLD) label
244 in the ordered list is rightmost; but in Arabic, it may be
245 leftmost, depending on local conventions).
247 Administration of names: Administration is specified by delegation
248 (see the definition of "delegation" in Section 7). Policies for
249 administration of the root zone in the global DNS are determined
250 by the names operational community, which convenes itself in the
251 Internet Corporation for Assigned Names and Numbers (ICANN). The
252 names operational community selects the IANA Functions Operator
253 for the global DNS root zone. The name servers that serve the
254 root zone are provided by independent root operators. Other zones
255 in the global DNS have their own policies for administration.
257 Types of data that can be associated with names: A name can have
258 zero or more resource records associated with it. There are
259 numerous types of resource records with unique data structures
260 defined in many different RFCs and in the IANA registry at
261 [IANA_Resource_Registry].
263 Types of metadata for names: Any name that is published in the DNS
264 appears as a set of resource records (see the definition of
265 "RRset" in Section 5). Some names do not, themselves, have data
266 associated with them in the DNS, but they "appear" in the DNS
267 anyway because they form part of a longer name that does have data
268 associated with it (see the definition of "empty non-terminals" in
269 Section 7).
271 Protocol for getting data from a name: The protocol described in
272 [RFC1035].
274 Context for resolving a name: The global DNS root zone distributed
275 by PTI.
277 Private DNS: Names that use the protocol described in [RFC1035] but
278 that do not rely on the global DNS root zone or names that are
279 otherwise not generally available on the Internet but are using
280 the protocol described in [RFC1035]. A system can use both the
281 global DNS and one or more private DNS systems; for example, see
282 "Split DNS" in Section 6.
284 Note that domain names that do not appear in the DNS, and that are
285 intended never to be looked up using the DNS protocol, are not
286 part of the global DNS or a private DNS even though they are
287 domain names.
289 Multicast DNS (mDNS): "Multicast DNS (mDNS) provides the ability to
290 perform DNS-like operations on the local link in the absence of
291 any conventional Unicast DNS server. In addition, Multicast DNS
292 designates a portion of the DNS namespace to be free for local
293 use, without the need to pay any annual fee, and without the need
294 to set up delegations or otherwise configure a conventional DNS
295 server to answer for those names." (Quoted from [RFC6762],
296 Abstract) Although it uses a compatible wire format, mDNS is,
297 strictly speaking, a different protocol than DNS. Also, where the
298 above quote says "a portion of the DNS namespace", it would be
299 clearer to say "a portion of the domain name space". The names in
300 mDNS are not intended to be looked up in the DNS.
302 Locally served DNS zone: A locally served DNS zone is a special case
303 of private DNS. Names are resolved using the DNS protocol in a
304 local context. [RFC6303] defines subdomains of IN-ADDR.ARPA that
305 are locally served zones. Resolution of names through locally
306 served zones may result in ambiguous results. For example, the
307 same name may resolve to different results in different locally
308 served DNS zone contexts. The context for a locally served DNS
309 zone may be explicit, such as those that are listed in [RFC6303]
310 and [RFC7793], or implicit, such as those defined by local DNS
311 administration and not known to the resolution client.
313 Fully-Qualified Domain Name (FQDN): This is often just a clear way
314 of saying the same thing as "domain name of a node", as outlined
315 above. However, the term is ambiguous. Strictly speaking, a
316 fully-qualified domain name would include every label, including
317 the zero-length label of the root: such a name would be written
318 "www.example.net." (note the terminating dot). But, because every
319 name eventually shares the common root, names are often written
320 relative to the root (such as "www.example.net") and are still
321 called "fully qualified". This term first appeared in [RFC0819].
322 In this document, names are often written relative to the root.
324 The need for the term "fully-qualified domain name" comes from the
325 existence of partially qualified domain names, which are names
326 where one or more of the last labels in the ordered list are
327 omitted (for example, a domain name of "www" relative to
328 "example.net" identifies "www.example.net"). Such relative names
329 are understood only by context.
331 Host name: This term and its equivalent, "hostname", have been
332 widely used but are not defined in [RFC1034], [RFC1035],
333 [RFC1123], or [RFC2181]. The DNS was originally deployed into the
334 Host Tables environment as outlined in [RFC0952], and it is likely
335 that the term followed informally from the definition there. Over
336 time, the definition seems to have shifted. "Host name" is often
337 meant to be a domain name that follows the rules in Section 3.5 of
338 [RFC1034], which is also called the "preferred name syntax". (In
339 that syntax, every character in each label is a letter, a digit,
340 or a hyphen). Note that any label in a domain name can contain
341 any octet value; hostnames are generally considered to be domain
342 names where every label follows the rules in the "preferred name
343 syntax", with the amendment that labels can start with ASCII
344 digits (this amendment comes from Section 2.1 of [RFC1123]).
346 People also sometimes use the term "hostname" to refer to just the
347 first label of an FQDN, such as "printer" in
348 "printer.admin.example.com". (Sometimes this is formalized in
349 configuration in operating systems.) In addition, people
350 sometimes use this term to describe any name that refers to a
351 machine, and those might include labels that do not conform to the
352 "preferred name syntax".
354 Top-Level Domain (TLD): A Top-Level Domain is a zone that is one
355 layer below the root, such as "com" or "jp". There is nothing
356 special, from the point of view of the DNS, about TLDs. Most of
357 them are also delegation-centric zones (defined in Section 7), and
358 there are significant policy issues around their operation. TLDs
359 are often divided into sub-groups such as Country Code Top-Level
360 Domains (ccTLDs), Generic Top-Level Domains (gTLDs), and others;
361 the division is a matter of policy and beyond the scope of this
362 document.
364 Internationalized Domain Name (IDN): The Internationalized Domain
365 Names for Applications (IDNA) protocol is the standard mechanism
366 for handling domain names with non-ASCII characters in
367 applications in the DNS. The current standard at the time of this
368 writing, normally called "IDNA2008", is defined in [RFC5890],
369 [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. These documents
370 define many IDN-specific terms such as "LDH label", "A-label", and
371 "U-label". [RFC6365] defines more terms that relate to
372 internationalization (some of which relate to IDNs); [RFC6055] has
373 a much more extensive discussion of IDNs, including some new
374 terminology.
376 Subdomain: "A domain is a subdomain of another domain if it is
377 contained within that domain. This relationship can be tested by
378 seeing if the subdomain's name ends with the containing domain's
379 name." (Quoted from [RFC1034], Section 3.1) For example, in the
380 host name "nnn.mmm.example.com", both "mmm.example.com" and
381 "nnn.mmm.example.com" are subdomains of "example.com". Note that
382 the comparisons here are done on whole labels; that is,
383 "ooo.example.com" is not a subdomain of "oo.example.com".
385 Alias: The owner of a CNAME resource record, or a subdomain of the
386 owner of a DNAME resource record (DNAME records are defined in
387 [RFC6672]). See also "canonical name".
389 Canonical name: A CNAME resource record "identifies its owner name
390 as an alias, and specifies the corresponding canonical name in the
391 RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2)
392 This usage of the word "canonical" is related to the mathematical
393 concept of "canonical form".
395 CNAME: "It has been traditional to refer to the [owner] of a CNAME
396 record as 'a CNAME'. This is unfortunate, as 'CNAME' is an
397 abbreviation of 'canonical name', and the [owner] of a CNAME
398 record is most certainly not a canonical name." (Quoted from
399 [RFC2181], Section 10.1.1. The quoted text has been changed from
400 "label" to "owner".)
402 3. DNS Response Codes
404 Some of the response codes (RCODEs) that are defined in [RFC1035]
405 have acquired their own shorthand names. All of the RCODEs are
406 listed at [IANA_Resource_Registry], although that list uses mixed-
407 case capitalization, while most documents use all caps. Some of the
408 common names for values defined in [RFC1035] are described in this
409 section. This section also includes an additional RCODE and a
410 general definition. The official list of all RCODEs is in the IANA
411 registry.
413 NOERROR: This RCODE appears as "No error condition" in Section 4.1.1
414 of [RFC1035].
416 FORMERR: This RCODE appears as "Format error - The name server was
417 unable to interpret the query" in Section 4.1.1 of [RFC1035].
419 SERVFAIL: This RCODE appears as "Server failure - The name server
420 was unable to process this query due to a problem with the name
421 server" in Section 4.1.1 of [RFC1035].
423 NXDOMAIN: This RCODE appears as "Name Error [...] this code
424 signifies that the domain name referenced in the query does not
425 exist." in Section 4.1.1 of [RFC1035]. [RFC2308] established
426 NXDOMAIN as a synonym for Name Error.
428 NOTIMP: This RCODE appears as "Not Implemented - The name server
429 does not support the requested kind of query" in Section 4.1.1 of
430 [RFC1035].
432 REFUSED: This RCODE appears as "Refused - The name server refuses to
433 perform the specified operation for policy reasons. For example,
434 a name server may not wish to provide the information to the
435 particular requester, or a name server may not wish to perform a
436 particular operation (e.g., zone transfer) for particular data."
437 in Section 4.1.1 of [RFC1035].
439 NODATA: "A pseudo RCODE which indicates that the name is valid, for
440 the given class, but [there] are no records of the given type. A
441 NODATA response has to be inferred from the answer." (Quoted from
442 [RFC2308], Section 1) "NODATA is indicated by an answer with the
443 RCODE set to NOERROR and no relevant answers in the Answer
444 section. The authority section will contain an SOA record, or
445 there will be no NS records there." (Quoted from [RFC2308],
446 Section 2.2) Note that referrals have a similar format to NODATA
447 replies; [RFC2308] explains how to distinguish them.
449 The term "NXRRSET" is sometimes used as a synonym for NODATA.
450 However, this is a mistake, given that NXRRSET is a specific error
451 code defined in [RFC2136].
453 Negative response: A response that indicates that a particular RRset
454 does not exist or whose RCODE indicates that the nameserver cannot
455 answer. Sections 2 and 7 of [RFC2308] describe the types of
456 negative responses in detail.
458 4. DNS Transactions
460 The header of a DNS message is its first 12 octets. Many of the
461 fields and flags in the diagrams in Sections 4.1.1 through 4.1.3 of
462 [RFC1035] are referred to by their names in each diagram. For
463 example, the response codes are called "RCODEs", the data for a
464 record is called the "RDATA", and the authoritative answer bit is
465 often called "the AA flag" or "the AA bit".
467 Class: A class "identifies a protocol family or instance of a
468 protocol". (Quoted from [RFC1034], Section 3.6) "The DNS tags all
469 data with a class as well as the type, so that we can allow
470 parallel use of different formats for data of type address."
471 (Quoted from [RFC1034], Section 2.2) In practice, the class for
472 nearly every query is "IN" (the Internet). There are some queries
473 for "CH" (the Chaos class), but they are usually for the purposes
474 of information about the server itself rather than for a different
475 type of address.
477 QNAME: The most commonly used rough definition is that the QNAME is
478 a field in the Question section of a query. "A standard query
479 specifies a target domain name (QNAME), query type (QTYPE), and
480 query class (QCLASS) and asks for RRs which match." (Quoted from
481 [RFC1034], Section 3.7.1) Strictly speaking, the definition comes
482 from [RFC1035], Section 4.1.2, where the QNAME is defined in
483 respect of the Question section. This definition appears to be
484 applied consistently: the discussion of inverse queries in
485 Section 6.4.1 refers to the "owner name of the query RR and its
486 TTL", because inverse queries populate the Answer section and
487 leave the Question section empty. (Inverse queries are deprecated
488 in [RFC3425]; thus, relevant definitions do not appear in this
489 document.)
491 However, [RFC2308] has an alternate definition that puts the QNAME
492 in the answer (or series of answers) instead of the query. It
493 defines QNAME as "...the name in the query section of an answer,
494 or where this resolves to a CNAME, or CNAME chain, the data field
495 of the last CNAME. The last CNAME in this sense is that which
496 contains a value which does not resolve to another CNAME." This
497 definition has a certain internal logic, because of the way CNAME
498 substitution works and the definition of CNAME. If a name server
499 does not find an RRset that matches a query, but does find the
500 same name in the same class with a CNAME record, then the name
501 server "includes the CNAME record in the response and restarts the
502 query at the domain name specified in the data field of the CNAME
503 record." (Quoted from [RFC1034], Section 3.6.2) This is made
504 explicit in the resolution algorithm outlined in Section 4.3.2 of
505 [RFC1034], which says to "change QNAME to the canonical name in
506 the CNAME RR, and go back to step 1" in the case of a CNAME RR.
507 Since a CNAME record explicitly declares that the owner name is
508 canonically named what is in the RDATA, then there is a way to
509 view the new name (i.e., the name that was in the RDATA of the
510 CNAME RR) as also being the QNAME.
512 However, this creates a kind of confusion because the response to
513 a query that results in CNAME processing contains in the echoed
514 Question section one QNAME (the name in the original query) and a
515 second QNAME that is in the data field of the last CNAME. The
516 confusion comes from the iterative/recursive mode of resolution,
517 which finally returns an answer that need not actually have the
518 same owner name as the QNAME contained in the original query.
520 To address this potential confusion, it is helpful to distinguish
521 between three meanings:
523 * QNAME (original): The name actually sent in the Question
524 section in the original query, which is always echoed in the
525 (final) reply in the Question section when the QR bit is set to
526 1.
528 * QNAME (effective): A name actually resolved, which is either
529 the name originally queried or a name received in a CNAME chain
530 response.
532 * QNAME (final): The name actually resolved, which is either the
533 name actually queried or else the last name in a CNAME chain
534 response.
536 Note that, because the definition in [RFC2308] is actually for a
537 different concept than what was in [RFC1034], it would have been
538 better if [RFC2308] had used a different name for that concept.
539 In general use today, QNAME almost always means what is defined
540 above as "QNAME (original)".
542 Referrals: A type of response in which a server, signaling that it
543 is not (completely) authoritative for an answer, provides the
544 querying resolver with an alternative place to send its query.
545 Referrals can be partial.
547 A referral arises when a server is not performing recursive
548 service while answering a query. It appears in step 3(b) of the
549 algorithm in [RFC1034], Section 4.3.2.
551 There are two types of referral response. The first is a downward
552 referral (sometimes described as "delegation response"), where the
553 server is authoritative for some portion of the QNAME. The
554 authority section RRset's RDATA contains the name servers
555 specified at the referred-to zone cut. In normal DNS operation,
556 this kind of response is required in order to find names beneath a
557 delegation. The bare use of "referral" means this kind of
558 referral, and many people believe that this is the only legitimate
559 kind of referral in the DNS.
561 The second is an upward referral (sometimes described as "root
562 referral"), where the server is not authoritative for any portion
563 of the QNAME. When this happens, the referred-to zone in the
564 authority section is usually the root zone ("."). In normal DNS
565 operation, this kind of response is not required for resolution or
566 for correctly answering any query. There is no requirement that
567 any server send upward referrals. Some people regard upward
568 referrals as a sign of a misconfiguration or error. Upward
569 referrals always need some sort of qualifier (such as "upward" or
570 "root") and are never identified simply by the word "referral".
572 A response that has only a referral contains an empty answer
573 section. It contains the NS RRset for the referred-to zone in the
574 Authority section. It may contain RRs that provide addresses in
575 the additional section. The AA bit is clear.
577 In the case where the query matches an alias, and the server is
578 not authoritative for the target of the alias but is authoritative
579 for some name above the target of the alias, the resolution
580 algorithm will produce a response that contains both the
581 authoritative answer for the alias and a referral. Such a partial
582 answer and referral response has data in the Answer section. It
583 has the NS RRset for the referred-to zone in the Authority
584 section. It may contain RRs that provide addresses in the
585 additional section. The AA bit is set, because the first name in
586 the Answer section matches the QNAME and the server is
587 authoritative for that answer (see [RFC1035], Section 4.1.1).
589 5. Resource Records
591 RR: An acronym for resource record. (See [RFC1034], Section 3.6.)
593 RRset: A set of resource records "with the same label, class and
594 type, but with different data" (according to [RFC2181],
595 Section 5). Also written as "RRSet" in some documents. As a
596 clarification, "same label" in this definition means "same owner
597 name". In addition, [RFC2181] states that "the TTLs of all RRs in
598 an RRSet must be the same".
600 Note that RRSIG resource records do not match this definition.
601 [RFC4035] says:
603 An RRset MAY have multiple RRSIG RRs associated with it. Note
604 that as RRSIG RRs are closely tied to the RRsets whose
605 signatures they contain, RRSIG RRs, unlike all other DNS RR
606 types, do not form RRsets. In particular, the TTL values among
607 RRSIG RRs with a common owner name do not follow the RRset
608 rules described in [RFC2181].
610 Master file: "Master files are text files that contain RRs in text
611 form. Since the contents of a zone can be expressed in the form
612 of a list of RRs a master file is most often used to define a
613 zone, though it can be used to list a cache's contents." (Quoted
614 from [RFC1035], Section 5) Master files are sometimes called "zone
615 files".
617 Presentation format: The text format used in master files. This
618 format is shown but not formally defined in [RFC1034] or
619 [RFC1035]. The term "presentation format" first appears in
620 [RFC4034].
622 EDNS: The extension mechanisms for DNS, defined in [RFC6891].
623 Sometimes called "EDNS0" or "EDNS(0)" to indicate the version
624 number. EDNS allows DNS clients and servers to specify message
625 sizes larger than the original 512 octet limit, to expand the
626 response code space and to carry additional options that affect
627 the handling of a DNS query.
629 OPT: A pseudo-RR (sometimes called a "meta-RR") that is used only to
630 contain control information pertaining to the question-and-answer
631 sequence of a specific transaction. (Definition paraphrased from
632 [RFC6891], Section 6.1.1.) It is used by EDNS.
634 Owner: "The domain name where the RR is found." (Quoted from
635 [RFC1034], Section 3.6) Often appears in the term "owner name".
637 SOA field names: DNS documents, including the definitions here,
638 often refer to the fields in the RDATA of an SOA resource record
639 by field name. "SOA" stands for "start of a zone of authority".
640 Those fields are defined in Section 3.3.13 of [RFC1035]. The
641 names (in the order they appear in the SOA RDATA) are MNAME,
642 RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Note that the
643 meaning of the MINIMUM field is updated in Section 4 of [RFC2308];
644 the new definition is that the MINIMUM field is only "the TTL to
645 be used for negative responses". This document tends to use field
646 names instead of terms that describe the fields.
648 TTL: The maximum "time to live" of a resource record. "A TTL value
649 is an unsigned number, with a minimum value of 0, and a maximum
650 value of 2147483647. That is, a maximum of 2^31 - 1. When
651 transmitted, this value shall be encoded in the less significant
652 31 bits of the 32 bit TTL field, with the most significant, or
653 sign, bit set to zero." (Quoted from [RFC2181], Section 8) (Note
654 that [RFC1035] erroneously stated that this is a signed integer;
655 that was fixed by [RFC2181].)
657 The TTL "specifies the time interval that the resource record may
658 be cached before the source of the information should again be
659 consulted." (Quoted from [RFC1035], Section 3.2.1) Section 4.1.3
660 of the same document states: "the time interval (in seconds) that
661 the resource record may be cached before it should be discarded".
662 Despite being defined for a resource record, the TTL of every
663 resource record in an RRset is required to be the same ([RFC2181],
664 Section 5.2).
666 The reason that the TTL is the maximum time to live is that a
667 cache operator might decide to shorten the time to live for
668 operational purposes, such as if there is a policy to disallow TTL
669 values over a certain number. Some servers are known to ignore
670 the TTL on some RRsets (such as when the authoritative data has a
671 very short TTL) even though this is against the advice in RFC
672 1035. An RRset can be flushed from the cache before the end of
673 the TTL interval, at which point, the value of the TTL becomes
674 unknown because the RRset with which it was associated no longer
675 exists.
677 There is also the concept of a "default TTL" for a zone, which can
678 be a configuration parameter in the server software. This is
679 often expressed by a default for the entire server, and a default
680 for a zone using the $TTL directive in a zone file. The $TTL
681 directive was added to the master file format by [RFC2308].
683 Class independent: A resource record type whose syntax and semantics
684 are the same for every DNS class. A resource record type that is
685 not class independent has different meanings depending on the DNS
686 class of the record, or the meaning is undefined for some class.
687 Most resource record types are defined for class 1 (IN, the
688 Internet), but many are undefined for other classes.
690 Address records: Records whose type is A or AAAA. [RFC2181]
691 informally defines these as "(A, AAAA, etc)". Note that new types
692 of address records could be defined in the future.
694 6. DNS Servers and Clients
696 This section defines the terms used for the systems that act as DNS
697 clients, DNS servers, or both. In past RFCs, DNS servers are
698 sometimes called "name servers", "nameservers", or just "servers".
699 There is no formal definition of "DNS server", but RFCs generally
700 assume that it is an Internet server that listens for queries and
701 sends responses using the DNS protocol defined in [RFC1035] and its
702 successors.
704 It is important to note that the terms "DNS server" and "name server"
705 require context in order to understand the services being provided.
706 Both authoritative servers and recursive resolvers are often called
707 "DNS servers" and "name servers" even though they serve different
708 roles (but may be part of the same software package).
710 For terminology specific to the global DNS root server system, see
711 [RSSAC026]. That document defines terms such as "root server", "root
712 server operator", and terms that are specific to the way that the
713 root zone of the global DNS is served.
715 Resolver: A program "that extract[s] information from name servers
716 in response to client requests." (Quoted from [RFC1034],
717 Section 2.4) A resolver performs queries for a name, type, and
718 class, and receives responses. The logical function is called
719 "resolution". In practice, the term is usually referring to some
720 specific type of resolver (some of which are defined below), and
721 understanding the use of the term depends on understanding the
722 context.
724 A related term is "resolve", which is not formally defined in
725 [RFC1034] or [RFC1035]. An imputed definition might be "asking a
726 question that consists of a domain name, class, and type, and
727 receiving some sort of response". Similarly, an imputed
728 definition of "resolution" might be "the response received from
729 resolving".
731 Stub resolver: A resolver that cannot perform all resolution itself.
732 Stub resolvers generally depend on a recursive resolver to
733 undertake the actual resolution function. Stub resolvers are
734 discussed but never fully defined in Section 5.3.1 of [RFC1034].
735 They are fully defined in Section 6.1.3.1 of [RFC1123].
737 Iterative mode: A resolution mode of a server that receives DNS
738 queries and responds with a referral to another server.
739 Section 2.3 of [RFC1034] describes this as "The server refers the
740 client to another server and lets the client pursue the query." A
741 resolver that works in iterative mode is sometimes called an
742 "iterative resolver". See also "iterative resolution" later in
743 this section.
745 Recursive mode: A resolution mode of a server that receives DNS
746 queries and either responds to those queries from a local cache or
747 sends queries to other servers in order to get the final answers
748 to the original queries. Section 2.3 of [RFC1034] describes this
749 as "the first server pursues the query for the client at another
750 server". Section 4.3.1 of [RFC1034] says: "in [recursive] mode
751 the name server acts in the role of a resolver and returns either
752 an error or the answer, but never referrals." That same section
753 also says:
755 The recursive mode occurs when a query with RD set arrives at a
756 server which is willing to provide recursive service; the
757 client can verify that recursive mode was used by checking that
758 both RA and RD are set in the reply.
760 A server operating in recursive mode may be thought of as having a
761 name server side (which is what answers the query) and a resolver
762 side (which performs the resolution function). Systems operating
763 in this mode are commonly called "recursive servers". Sometimes
764 they are called "recursive resolvers". In practice, it is not
765 possible to know in advance whether the server that one is
766 querying will also perform recursion; both terms can be observed
767 in use interchangeably.
769 Recursive resolver: A resolver that acts in recursive mode. In
770 general, a recursive resolver is expected to cache the answers it
771 receives (which would make it a full-service resolver), but some
772 recursive resolvers might not cache.
774 [RFC4697] tried to differentiate between a recursive resolver and
775 an iterative resolver.
777 Recursive query: A query with the Recursion Desired (RD) bit set to
778 1 in the header. (See Section 4.1.1 of [RFC1035].) If recursive
779 service is available and is requested by the RD bit in the query,
780 the server uses its resolver to answer the query. (See
781 Section 4.3.2 of [RFC1034].)
783 Non-recursive query: A query with the Recursion Desired (RD) bit set
784 to 0 in the header. A server can answer non-recursive queries
785 using only local information: the response contains either an
786 error, the answer, or a referral to some other server "closer" to
787 the answer. (See Section 4.3.1 of [RFC1034].)
789 Iterative resolution: A name server may be presented with a query
790 that can only be answered by some other server. The two general
791 approaches to dealing with this problem are "recursive", in which
792 the first server pursues the query on behalf of the client at
793 another server, and "iterative", in which the server refers the
794 client to another server and lets the client pursue the query
795 there. (See Section 2.3 of [RFC1034].)
797 In iterative resolution, the client repeatedly makes non-recursive
798 queries and follows referrals and/or aliases. The iterative
799 resolution algorithm is described in Section 5.3.3 of [RFC1034].
801 Full resolver: This term is used in [RFC1035], but it is not defined
802 there. RFC 1123 defines a "full-service resolver" that may or may
803 not be what was intended by "full resolver" in [RFC1035]. This
804 term is not properly defined in any RFC.
806 Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this
807 term to mean a resolver that acts in recursive mode with a cache
808 (and meets other requirements).
810 Priming: "The act of finding the list of root servers from a
811 configuration that lists some or all of the purported IP addresses
812 of some or all of those root servers." (Quoted from [RFC8109],
813 Section 2) In order to operate in recursive mode, a resolver needs
814 to know the address of at least one root server. Priming is most
815 often done from a configuration setting that contains a list of
816 authoritative servers for the root zone.
818 Root hints: "Operators who manage a DNS recursive resolver typically
819 need to configure a 'root hints file'. This file contains the
820 names and IP addresses of the authoritative name servers for the
821 root zone, so the software can bootstrap the DNS resolution
822 process. For many pieces of software, this list comes built into
823 the software." (Quoted from [IANA_RootFiles]) This file is often
824 used in priming.
826 Negative caching: "The storage of knowledge that something does not
827 exist, cannot or does not give an answer." (Quoted from
828 [RFC2308], Section 1)
830 Authoritative server: "A server that knows the content of a DNS zone
831 from local knowledge, and thus can answer queries about that zone
832 without needing to query other servers." (Quoted from [RFC2182],
833 Section 2) An authoritative server is named in the NS ("name
834 server") record in a zone. It is a system that responds to DNS
835 queries with information about zones for which it has been
836 configured to answer with the AA flag in the response header set
837 to 1. It is a server that has authority over one or more DNS
838 zones. Note that it is possible for an authoritative server to
839 respond to a query without the parent zone delegating authority to
840 that server. Authoritative servers also provide "referrals",
841 usually to child zones delegated from them; these referrals have
842 the AA bit set to 0 and come with referral data in the Authority
843 and (if needed) the Additional sections.
845 Authoritative-only server: A name server that only serves
846 authoritative data and ignores requests for recursion. It will
847 "not normally generate any queries of its own. Instead it answers
848 non-recursive queries from iterative resolvers looking for
849 information in zones it serves." (Quoted from [RFC4697],
850 Section 2.4) In this case, "ignores requests for recursion" means
851 "responds to requests for recursion with responses indicating that
852 recursion was not performed".
854 Zone transfer: The act of a client requesting a copy of a zone and
855 an authoritative server sending the needed information. (See
856 Section 7 for a description of zones.) There are two common
857 standard ways to do zone transfers: the AXFR ("Authoritative
858 Transfer") mechanism to copy the full zone (described in
859 [RFC5936], and the IXFR ("Incremental Transfer") mechanism to copy
860 only parts of the zone that have changed (described in [RFC1995]).
861 Many systems use non-standard methods for zone transfer outside
862 the DNS protocol.
864 Slave server: See "Secondary server".
866 Secondary server: "An authoritative server which uses zone transfer
867 to retrieve the zone." (Quoted from [RFC1996], Section 2.1)
868 Secondary servers are also discussed in [RFC1034]. [RFC2182]
869 describes secondary servers in more detail. Although early DNS
870 RFCs such as [RFC1996] referred to this as a "slave", the current
871 common usage has shifted to calling it a "secondary".
873 Master server: See "Primary server".
875 Primary server: "Any authoritative server configured to be the
876 source of zone transfer for one or more [secondary] servers."
877 (Quoted from [RFC1996], Section 2.1) Or, more specifically,
878 [RFC2136] calls it "an authoritative server configured to be the
879 source of AXFR or IXFR data for one or more [secondary] servers".
880 Primary servers are also discussed in [RFC1034]. Although early
881 DNS RFCs such as [RFC1996] referred to this as a "master", the
882 current common usage has shifted to "primary".
884 Primary master: "The primary master is named in the zone's SOA MNAME
885 field and optionally by an NS RR." (Quoted from [RFC1996],
886 Section 2.1) [RFC2136] defines "primary master" as "Master server
887 at the root of the AXFR/IXFR dependency graph. The primary master
888 is named in the zone's SOA MNAME field and optionally by an NS RR.
889 There is by definition only one primary master server per zone."
891 The idea of a primary master is only used in [RFC1996] and
892 [RFC2136]. A modern interpretation of the term "primary master"
893 is a server that is both authoritative for a zone and that gets
894 its updates to the zone from configuration (such as a master file)
895 or from UPDATE transactions.
897 Stealth server: This is "like a slave server except not listed in an
898 NS RR for the zone." (Quoted from [RFC1996], Section 2.1)
900 Hidden master: A stealth server that is a primary server for zone
901 transfers. "In this arrangement, the master name server that
902 processes the updates is unavailable to general hosts on the
903 Internet; it is not listed in the NS RRset." (Quoted from
904 [RFC6781], Section 3.4.3) An earlier RFC, [RFC4641], said that the
905 hidden master's name "appears in the SOA RRs MNAME field",
906 although, in some setups, the name does not appear at all in the
907 global DNS. A hidden master can also be a secondary server for
908 the zone itself.
910 Forwarding: The process of one server sending a DNS query with the
911 RD bit set to 1 to another server to resolve that query.
912 Forwarding is a function of a DNS resolver; it is different than
913 simply blindly relaying queries.
915 [RFC5625] does not give a specific definition for forwarding, but
916 describes in detail what features a system that forwards needs to
917 support. Systems that forward are sometimes called "DNS proxies",
918 but that term has not yet been defined (even in [RFC5625]).
920 Forwarder: Section 1 of [RFC2308] describes a forwarder as "a
921 nameserver used to resolve queries instead of directly using the
922 authoritative nameserver chain". [RFC2308] further says "The
923 forwarder typically either has better access to the internet, or
924 maintains a bigger cache which may be shared amongst many
925 resolvers." That definition appears to suggest that forwarders
926 normally only query authoritative servers. In current use,
927 however, forwarders often stand between stub resolvers and
928 recursive servers. [RFC2308] is silent on whether a forwarder is
929 iterative-only or can be a full-service resolver.
931 Policy-implementing resolver: A resolver acting in recursive mode
932 that changes some of the answers that it returns based on policy
933 criteria, such as to prevent access to malware sites or
934 objectionable content. In general, a stub resolver has no idea
935 whether upstream resolvers implement such policy or, if they do,
936 the exact policy about what changes will be made. In some cases,
937 the user of the stub resolver has selected the policy-implementing
938 resolver with the explicit intention of using it to implement the
939 policies. In other cases, policies are imposed without the user
940 of the stub resolver being informed.
942 Open resolver: A full-service resolver that accepts and processes
943 queries from any (or nearly any) client. This is sometimes also
944 called a "public resolver", although the term "public resolver" is
945 used more with open resolvers that are meant to be open, as
946 compared to the vast majority of open resolvers that are probably
947 misconfigured to be open. Open resolvers are discussed in
948 [RFC5358].
950 Split DNS: The terms "split DNS" and "split-horizon DNS" have long
951 been used in the DNS community without formal definition. In
952 general, they refer to situations in which DNS servers that are
953 authoritative for a particular set of domains provide partly or
954 completely different answers in those domains depending on the
955 source of the query. The effect of this is that a domain name
956 that is notionally globally unique nevertheless has different
957 meanings for different network users. This can sometimes be the
958 result of a "view" configuration, described below.
960 Section 3.8 of [RFC2775] gives a related definition that is too
961 specific to be generally useful.
963 View: A configuration for a DNS server that allows it to provide
964 different responses depending on attributes of the query, such as
965 for "split DNS". Typically, views differ by the source IP address
966 of a query, but can also be based on the destination IP address,
967 the type of query (such as AXFR), whether it is recursive, and so
968 on. Views are often used to provide more names or different
969 addresses to queries from "inside" a protected network than to
970 those "outside" that network. Views are not a standardized part
971 of the DNS, but they are widely implemented in server software.
973 Passive DNS: A mechanism to collect DNS data by storing DNS
974 responses from name servers. Some of these systems also collect
975 the DNS queries associated with the responses, although doing so
976 raises some privacy concerns. Passive DNS databases can be used
977 to answer historical questions about DNS zones such as which
978 values were present at a given time in the past, or when a name
979 was spotted first. Passive DNS databases allow searching of the
980 stored records on keys other than just the name and type, such as
981 "find all names which have A records of a particular value".
983 Anycast: "The practice of making a particular service address
984 available in multiple, discrete, autonomous locations, such that
985 datagrams sent are routed to one of several available locations."
986 (Quoted from [RFC4786], Section 2) See [RFC4786] for more detail
987 on Anycast and other terms that are specific to its use.
989 Instance: "When anycast routing is used to allow more than one
990 server to have the same IP address, each one of those servers is
991 commonly referred to as an 'instance'." It goes on to say: "An
992 instance of a server, such as a root server, is often referred to
993 as an 'Anycast instance'." (Quoted from [RSSAC026])
995 Privacy-enabling DNS server: "A DNS server that implements DNS over
996 TLS [RFC7858] and may optionally implement DNS over DTLS
997 [RFC8094]." (Quoted from [RFC8310], Section 2) Other types of DNS
998 servers might also be considered privacy-enabling, such as those
999 running DNS over HTTPS [RFC8484].
1001 DNS-over-TLS (DoT): DNS over TLS as defined in [RFC7858] and its
1002 successors.
1004 DNS-over-HTTPS (DoH): DNS over HTTPS as defined in [RFC8484] and its
1005 successors.
1007 DNS-over-QUIC (DoQ): DNS over QUIC as defined in
1008 [I-D.ietf-dprive-dnsoquic]
1010 Classic DNS: DNS over UDP or TCP as defined in [RFC1035] and its
1011 successors. Classic DNS applies to DNS communication between stub
1012 resolvers and recursive resolvers, and between recursive resolvers
1013 and authoritative servers. This has sometimes been called "Do53".
1014 Classic DNS is not encrypted.
1016 Recursive DoT (RDoT): RDoT specifically means DNS-over-TLS for
1017 transport between a stub resolver and a recursive resolver, or
1018 between a recursive resolver and another recursive resolver. This
1019 term is necessary because it is expected that DNS-over-TLS will
1020 later be defined as a transport between recursive resolvers and
1021 authoritative servers,
1023 Authoritative DoT (ADoT): If DNS-over-TLS is later defined as a
1024 transport between recursive resolvers and authoritative servers,
1025 ADoT specifically means DNS-over-TLS for transport between
1026 recursive resolvers and authoritative servers.
1028 XFR-over-TLS (XoT): DNS zone transfer over TLS, as specified in
1029 [RFC9103]. This term applies to both AXFR over TLS (AXoT) and
1030 IXFR over TLS (IXoT).
1032 7. Zones
1034 This section defines terms that are used when discussing zones that
1035 are being served or retrieved.
1037 Zone: "Authoritative information is organized into units called
1038 ZONEs, and these zones can be automatically distributed to the
1039 name servers which provide redundant service for the data in a
1040 zone." (Quoted from [RFC1034], Section 2.4)
1042 Child: "The entity on record that has the delegation of the domain
1043 from the Parent." (Quoted from [RFC7344], Section 1.1)
1045 Parent: "The domain in which the Child is registered." (Quoted from
1046 [RFC7344], Section 1.1) Earlier, "parent name server" was defined
1047 in [RFC0882] as "the name server that has authority over the place
1048 in the domain name space that will hold the new domain". (Note
1049 that [RFC0882] was obsoleted by [RFC1034] and [RFC1035].)
1050 [RFC0819] also has some description of the relationship between
1051 parents and children.
1053 Origin:
1055 There are two different uses for this term:
1057 (a) "The domain name that appears at the top of a zone (just
1058 below the cut that separates the zone from its parent)... The
1059 name of the zone is the same as the name of the domain at the
1060 zone's origin." (Quoted from [RFC2181], Section 6) These
1061 days, this sense of "origin" and "apex" (defined below) are
1062 often used interchangeably.
1064 (b) The domain name within which a given relative domain name
1065 appears in zone files. Generally seen in the context of
1066 "$ORIGIN", which is a control entry defined in [RFC1035],
1067 Section 5.1, as part of the master file format. For example,
1068 if the $ORIGIN is set to "example.org.", then a master file
1069 line for "www" is in fact an entry for "www.example.org.".
1071 Apex: The point in the tree at an owner of an SOA and corresponding
1072 authoritative NS RRset. This is also called the "zone apex".
1073 [RFC4033] defines it as "the name at the child's side of a zone
1074 cut". The "apex" can usefully be thought of as a data-theoretic
1075 description of a tree structure, and "origin" is the name of the
1076 same concept when it is implemented in zone files. The
1077 distinction is not always maintained in use, however, and one can
1078 find uses that conflict subtly with this definition. [RFC1034]
1079 uses the term "top node of the zone" as a synonym of "apex", but
1080 that term is not widely used. These days, the first sense of
1081 "origin" (above) and "apex" are often used interchangeably.
1083 Zone cut: The delimitation point between two zones where the origin
1084 of one of the zones is the child of the other zone.
1086 "Zones are delimited by 'zone cuts'. Each zone cut separates a
1087 'child' zone (below the cut) from a 'parent' zone (above the
1088 cut)." (Quoted from [RFC2181], Section 6; note that this is
1089 barely an ostensive definition.) Section 4.2 of [RFC1034] uses
1090 "cuts" instead of "zone cut".
1092 Delegation: The process by which a separate zone is created in the
1093 name space beneath the apex of a given domain. Delegation happens
1094 when an NS RRset is added in the parent zone for the child origin.
1095 Delegation inherently happens at a zone cut. The term is also
1096 commonly a noun: the new zone that is created by the act of
1097 delegating.
1099 Authoritative data: "All of the RRs attached to all of the nodes
1100 from the top node of the zone down to leaf nodes or nodes above
1101 cuts around the bottom edge of the zone." (Quoted from [RFC1034],
1102 Section 4.2.1) Note that this definition might inadvertently also
1103 cause any NS records that appear in the zone to be included, even
1104 those that might not truly be authoritative because there are
1105 identical NS RRs below the zone cut. This reveals the ambiguity
1106 in the notion of authoritative data, because the parent-side NS
1107 records authoritatively indicate the delegation, even though they
1108 are not themselves authoritative data.
1110 [RFC4033], Section 2, defines "Authoritative RRset", which is
1111 related to authoritative data but has a more precise definition.
1113 Lame delegation: "A lame delegations exists [sic] when a nameserver
1114 is delegated responsibility for providing nameservice for a zone
1115 (via NS records) but is not performing nameservice for that zone
1116 (usually because it is not set up as a primary or secondary for
1117 the zone)." (Quoted from [RFC1912], Section 2.8) Another
1118 definition is that a lame delegation "...happens when a name
1119 server is listed in the NS records for some domain and in fact it
1120 is not a server for that domain. Queries are thus sent to the
1121 wrong servers, who don't know nothing [sic] (at least not as
1122 expected) about the queried domain. Furthermore, sometimes these
1123 hosts (if they exist!) don't even run name servers." (Quoted from
1124 [RFC1713], Section 2.3)
1126 Glue records: "...[Resource records] which are not part of the
1127 authoritative data [of the zone], and are address RRs for the
1128 [name] servers [in subzones]. These RRs are only necessary if the
1129 name server's name is 'below' the cut, and are only used as part
1130 of a referral response." Without glue "we could be faced with the
1131 situation where the NS RRs tell us that in order to learn a name
1132 server's address, we should contact the server using the address
1133 we wish to learn." (Quoted from [RFC1034], Section 4.2.1)
1135 A later definition is that glue "includes any record in a zone
1136 file that is not properly part of that zone, including nameserver
1137 records of delegated sub-zones (NS records), address records that
1138 accompany those NS records (A, AAAA, etc), and any other stray
1139 data that might appear." (Quoted from [RFC2181], Section 5.4.1)
1140 Although glue is sometimes used today with this wider definition
1141 in mind, the context surrounding the definition in [RFC2181]
1142 suggests it is intended to apply to the use of glue within the
1143 document itself and not necessarily beyond.
1145 Bailiwick: "In-bailiwick" is a modifier to describe a name server
1146 whose name is either a subdomain of or (rarely) the same as the
1147 origin of the zone that contains the delegation to the name
1148 server. In-bailiwick name servers may have glue records in their
1149 parent zone (using the first of the definitions of "glue records"
1150 in the definition above). (The word "bailiwick" means the
1151 district or territory where a bailiff or policeman has
1152 jurisdiction.)
1154 "In-bailiwick" names are divided into two types of names for name
1155 servers: "in-domain" names and "sibling domain" names.
1157 * In-domain: a modifier to describe a name server whose name is
1158 either subordinate to or (rarely) the same as the owner name of
1159 the NS resource records. An in-domain name server name needs
1160 to have glue records or name resolution fails. For example, a
1161 delegation for "child.example.com" may have "in-domain" name
1162 server name "ns.child.example.com".
1164 * Sibling domain: a name server's name that is either subordinate
1165 to or (rarely) the same as the zone origin and not subordinate
1166 to or the same as the owner name of the NS resource records.
1168 Glue records for sibling domains are allowed, but not
1169 necessary. For example, a delegation for "child.example.com"
1170 in "example.com" zone may have "sibling" name server name
1171 "ns.another.example.com".
1173 "Out-of-bailiwick" is the antonym of "in-bailiwick". It is a
1174 modifier to describe a name server whose name is not subordinate
1175 to or the same as the zone origin. Glue records for out-of-
1176 bailiwick name servers are useless.
1178 The following table shows examples of delegation types.
1180 +=============+========+====================+==================+
1181 | Delegation | Parent | Name Server Name | Type |
1182 +=============+========+====================+==================+
1183 | com | . | a.gtld-servers.net | in-bailiwick / |
1184 | | | | sibling domain |
1185 +-------------+--------+--------------------+------------------+
1186 | net | . | a.gtld-servers.net | in-bailiwick / |
1187 | | | | in-domain |
1188 +-------------+--------+--------------------+------------------+
1189 | example.org | org | ns.example.org | in-bailiwick / |
1190 | | | | in-domain |
1191 +-------------+--------+--------------------+------------------+
1192 | example.org | org | ns.ietf.org | in-bailiwick / |
1193 | | | | sibling domain |
1194 +-------------+--------+--------------------+------------------+
1195 | example.org | org | ns.example.com | out-of-bailiwick |
1196 +-------------+--------+--------------------+------------------+
1197 | example.jp | jp | ns.example.jp | in-bailiwick / |
1198 | | | | in-domain |
1199 +-------------+--------+--------------------+------------------+
1200 | example.jp | jp | ns.example.ne.jp | in-bailiwick / |
1201 | | | | sibling domain |
1202 +-------------+--------+--------------------+------------------+
1203 | example.jp | jp | ns.example.com | out-of-bailiwick |
1204 +-------------+--------+--------------------+------------------+
1206 Table 1
1208 Root zone: The zone of a DNS-based tree whose apex is the zero-
1209 length label. Also sometimes called "the DNS root".
1211 Empty non-terminals (ENT): "Domain names that own no resource
1212 records but have subdomains that do." (Quoted from [RFC4592],
1213 Section 2.2.2) A typical example is in SRV records: in the name
1214 "_sip._tcp.example.com", it is likely that "_tcp.example.com" has
1215 no RRsets, but that "_sip._tcp.example.com" has (at least) an SRV
1216 RRset.
1218 Delegation-centric zone: A zone that consists mostly of delegations
1219 to child zones. This term is used in contrast to a zone that
1220 might have some delegations to child zones but also has many data
1221 resource records for the zone itself and/or for child zones. The
1222 term is used in [RFC4956] and [RFC5155], but it is not defined in
1223 either document.
1225 Occluded name: "The addition of a delegation point via dynamic
1226 update will render all subordinate domain names to be in a limbo,
1227 still part of the zone but not available to the lookup process.
1228 The addition of a DNAME resource record has the same impact. The
1229 subordinate names are said to be 'occluded'." (Quoted from
1230 [RFC5936], Section 3.5)
1232 Fast flux DNS: This "occurs when a domain is [found] in DNS using A
1233 records to multiple IP addresses, each of which has a very short
1234 Time-to-Live (TTL) value associated with it. This means that the
1235 domain resolves to varying IP addresses over a short period of
1236 time." (Quoted from [RFC6561], Section 1.1.5, with a typo
1237 corrected) In addition to having legitimate uses, fast flux DNS
1238 can used to deliver malware. Because the addresses change so
1239 rapidly, it is difficult to ascertain all the hosts. It should be
1240 noted that the technique also works with AAAA records, but such
1241 use is not frequently observed on the Internet as of this writing.
1243 Reverse DNS, reverse lookup: "The process of mapping an address to a
1244 name is generally known as a 'reverse lookup', and the IN-
1245 ADDR.ARPA and IP6.ARPA zones are said to support the 'reverse
1246 DNS'." (Quoted from [RFC5855], Section 1)
1248 Forward lookup: "Hostname-to-address translation". (Quoted from
1249 [RFC3493], Section 6)
1251 arpa: Address and Routing Parameter Area Domain: "The 'arpa' domain
1252 was originally established as part of the initial deployment of
1253 the DNS, to provide a transition mechanism from the Host Tables
1254 that were common in the ARPANET, as well as a home for the IPv4
1255 reverse mapping domain. During 2000, the abbreviation was
1256 redesignated to 'Address and Routing Parameter Area' in the hope
1257 of reducing confusion with the earlier network name." (Quoted
1258 from [RFC3172], Section 2) .arpa is an "infrastructure domain", a
1259 domain whose "role is to support the operating infrastructure of
1260 the Internet". (Quoted from [RFC3172], Section 2) See [RFC3172]
1261 for more history of this name.
1263 Service name: "Service names are the unique key in the Service Name
1264 and Transport Protocol Port Number registry. This unique symbolic
1265 name for a service may also be used for other purposes, such as in
1266 DNS SRV records." (Quoted from [RFC6335], Section 5)
1268 8. Wildcards
1270 Wildcard: [RFC1034] defined "wildcard", but in a way that turned out
1271 to be confusing to implementers. For an extended discussion of
1272 wildcards, including clearer definitions, see [RFC4592]. Special
1273 treatment is given to RRs with owner names starting with the label
1274 "*". "Such RRs are called 'wildcards'. Wildcard RRs can be
1275 thought of as instructions for synthesizing RRs." (Quoted from
1276 [RFC1034], Section 4.3.3)
1278 Asterisk label: "The first octet is the normal label type and length
1279 for a 1-octet-long label, and the second octet is the ASCII
1280 representation [RFC20] for the '*' character. A descriptive name
1281 of a label equaling that value is an 'asterisk label'." (Quoted
1282 from [RFC4592], Section 2.1.1)
1284 Wildcard domain name: "A 'wildcard domain name' is defined by having
1285 its initial (i.e., leftmost or least significant) label, in binary
1286 format: 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)".
1287 (Quoted from [RFC4592], Section 2.1.1) The second octet in this
1288 label is the ASCII representation for the "*" character.
1290 Closest encloser: "The longest existing ancestor of a name."
1291 (Quoted from [RFC5155], Section 1.3) An earlier definition is "The
1292 node in the zone's tree of existing domain names that has the most
1293 labels matching the query name (consecutively, counting from the
1294 root label downward). Each match is a 'label match' and the order
1295 of the labels is the same." (Quoted from [RFC4592],
1296 Section 3.3.1)
1298 Closest provable encloser: "The longest ancestor of a name that can
1299 be proven to exist. Note that this is only different from the
1300 closest encloser in an Opt-Out zone." (Quoted from [RFC5155],
1301 Section 1.3) See Section 10 for more on "opt-out".
1303 Next closer name: "The name one label longer than the closest
1304 provable encloser of a name." (Quoted from [RFC5155],
1305 Section 1.3)
1307 Source of Synthesis: "The source of synthesis is defined in the
1308 context of a query process as that wildcard domain name
1309 immediately descending from the closest encloser, provided that
1310 this wildcard domain name exists. 'Immediately descending' means
1311 that the source of synthesis has a name of the form:
1313 .."
1315 (Quoted from [RFC4592], Section 3.3.1)
1317 9. Registration Model
1319 Registry: The administrative operation of a zone that allows
1320 registration of names within that zone. People often use this
1321 term to refer only to those organizations that perform
1322 registration in large delegation-centric zones (such as TLDs); but
1323 formally, whoever decides what data goes into a zone is the
1324 registry for that zone. This definition of "registry" is from a
1325 DNS point of view; for some zones, the policies that determine
1326 what can go in the zone are decided by zones that are
1327 superordinate and not the registry operator.
1329 Registrant: An individual or organization on whose behalf a name in
1330 a zone is registered by the registry. In many zones, the registry
1331 and the registrant may be the same entity, but in TLDs they often
1332 are not.
1334 Registrar: A service provider that acts as a go-between for
1335 registrants and registries. Not all registrations require a
1336 registrar, though it is common to have registrars involved in
1337 registrations in TLDs.
1339 EPP: The Extensible Provisioning Protocol (EPP), which is commonly
1340 used for communication of registration information between
1341 registries and registrars. EPP is defined in [RFC5730].
1343 WHOIS: A protocol specified in [RFC3912], often used for querying
1344 registry databases. WHOIS data is frequently used to associate
1345 registration data (such as zone management contacts) with domain
1346 names. The term "WHOIS data" is often used as a synonym for the
1347 registry database, even though that database may be served by
1348 different protocols, particularly RDAP. The WHOIS protocol is
1349 also used with IP address registry data.
1351 RDAP: The Registration Data Access Protocol, defined in [RFC7480],
1352 [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The
1353 RDAP protocol and data format are meant as a replacement for
1354 WHOIS.
1356 DNS operator: An entity responsible for running DNS servers. For a
1357 zone's authoritative servers, the registrant may act as their own
1358 DNS operator, their registrar may do it on their behalf, or they
1359 may use a third-party operator. For some zones, the registry
1360 function is performed by the DNS operator plus other entities who
1361 decide about the allowed contents of the zone.
1363 Public suffix: "A domain that is controlled by a public registry."
1364 (Quoted from [RFC6265], Section 5.3) A common definition for this
1365 term is a domain under which subdomains can be registered by third
1366 parties and on which HTTP cookies (which are described in detail
1367 in [RFC6265]) should not be set. There is no indication in a
1368 domain name whether it is a public suffix; that can only be
1369 determined by outside means. In fact, both a domain and a
1370 subdomain of that domain can be public suffixes.
1372 There is nothing inherent in a domain name to indicate whether it
1373 is a public suffix. One resource for identifying public suffixes
1374 is the Public Suffix List (PSL) maintained by Mozilla
1375 (https://publicsuffix.org/).
1377 For example, at the time this document is published, the "com.au"
1378 domain is listed as a public suffix in the PSL. (Note that this
1379 example might change in the future.)
1381 Note that the term "public suffix" is controversial in the DNS
1382 community for many reasons, and it may be significantly changed in
1383 the future. One example of the difficulty of calling a domain a
1384 public suffix is that designation can change over time as the
1385 registration policy for the zone changes, such as was the case
1386 with the "uk" TLD in 2014.
1388 Subordinate and Superordinate: These terms are introduced in
1389 [RFC5731] for use in the registration model, but not defined
1390 there. Instead, they are given in examples. "For example, domain
1391 name 'example.com' has a superordinate relationship to host name
1392 ns1.example.com'... For example, host ns1.example1.com is a
1393 subordinate host of domain example1.com, but it is a not a
1394 subordinate host of domain example2.com." (Quoted from [RFC5731],
1395 Section 1.1) These terms are strictly ways of referring to the
1396 relationship standing of two domains where one is a subdomain of
1397 the other.
1399 10. General DNSSEC
1401 Most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and
1402 [RFC5155]. The terms that have caused confusion in the DNS community
1403 are highlighted here.
1405 DNSSEC-aware and DNSSEC-unaware: These two terms, which are used in
1406 some RFCs, have not been formally defined. However, Section 2 of
1407 [RFC4033] defines many types of resolvers and validators,
1408 including "non-validating security-aware stub resolver", "non-
1409 validating stub resolver", "security-aware name server",
1410 "security-aware recursive name server", "security-aware resolver",
1411 "security-aware stub resolver", and "security-oblivious
1412 'anything'". (Note that the term "validating resolver", which is
1413 used in some places in DNSSEC-related documents, is also not
1414 defined in those RFCs, but is defined below.)
1416 Signed zone: "A zone whose RRsets are signed and that contains
1417 properly constructed DNSKEY, Resource Record Signature (RRSIG),
1418 Next Secure (NSEC), and (optionally) DS records." (Quoted from
1419 [RFC4033], Section 2) It has been noted in other contexts that the
1420 zone itself is not really signed, but all the relevant RRsets in
1421 the zone are signed. Nevertheless, if a zone that should be
1422 signed contains any RRsets that are not signed (or opted out),
1423 those RRsets will be treated as bogus, so the whole zone needs to
1424 be handled in some way.
1426 It should also be noted that, since the publication of [RFC6840],
1427 NSEC records are no longer required for signed zones: a signed
1428 zone might include NSEC3 records instead. [RFC7129] provides
1429 additional background commentary and some context for the NSEC and
1430 NSEC3 mechanisms used by DNSSEC to provide authenticated denial-
1431 of-existence responses. NSEC and NSEC3 are described below.
1433 Online signing: [RFC4470] defines "on-line signing" (note the
1434 hyphen) as "generating and signing these records on demand", where
1435 "these" was defined as NSEC records. The current definition
1436 expands that to generating and signing RRSIG, NSEC, and NSEC3
1437 records on demand.
1439 Unsigned zone: Section 2 of [RFC4033] defines this as "a zone that
1440 is not signed". Section 2 of [RFC4035] defines this as a "zone
1441 that does not include these records [properly constructed DNSKEY,
1442 Resource Record Signature (RRSIG), Next Secure (NSEC), and
1443 (optionally) DS records] according to the rules in this
1444 section..." There is an important note at the end of Section 5.2
1445 of [RFC4035] that defines an additional situation in which a zone
1446 is considered unsigned: "If the resolver does not support any of
1447 the algorithms listed in an authenticated DS RRset, then the
1448 resolver will not be able to verify the authentication path to the
1449 child zone. In this case, the resolver SHOULD treat the child
1450 zone as if it were unsigned."
1452 NSEC: "The NSEC record allows a security-aware resolver to
1453 authenticate a negative reply for either name or type non-
1454 existence with the same mechanisms used to authenticate other DNS
1455 replies." (Quoted from [RFC4033], Section 3.2) In short, an NSEC
1456 record provides authenticated denial of existence.
1458 "The NSEC resource record lists two separate things: the next
1459 owner name (in the canonical ordering of the zone) that contains
1460 authoritative data or a delegation point NS RRset, and the set of
1461 RR types present at the NSEC RR's owner name." (Quoted from
1462 Section 4 of RFC 4034)
1464 NSEC3: Like the NSEC record, the NSEC3 record also provides
1465 authenticated denial of existence; however, NSEC3 records mitigate
1466 zone enumeration and support Opt-Out. NSEC3 resource records
1467 require associated NSEC3PARAM resource records. NSEC3 and
1468 NSEC3PARAM resource records are defined in [RFC5155].
1470 Note that [RFC6840] says that [RFC5155] "is now considered part of
1471 the DNS Security Document Family as described by Section 10 of
1472 [RFC4033]". This means that some of the definitions from earlier
1473 RFCs that only talk about NSEC records should probably be
1474 considered to be talking about both NSEC and NSEC3.
1476 Opt-out: "The Opt-Out Flag indicates whether this NSEC3 RR may cover
1477 unsigned delegations." (Quoted from [RFC5155], Section 3.1.2.1)
1478 Opt-out tackles the high costs of securing a delegation to an
1479 insecure zone. When using Opt-Out, names that are an insecure
1480 delegation (and empty non-terminals that are only derived from
1481 insecure delegations) don't require an NSEC3 record or its
1482 corresponding RRSIG records. Opt-Out NSEC3 records are not able
1483 to prove or deny the existence of the insecure delegations.
1484 (Adapted from [RFC7129], Section 5.1)
1486 Insecure delegation: "A signed name containing a delegation (NS
1487 RRset), but lacking a DS RRset, signifying a delegation to an
1488 unsigned subzone." (Quoted from [RFC4956], Section 2)
1490 Zone enumeration: "The practice of discovering the full content of a
1491 zone via successive queries." (Quoted from [RFC5155],
1492 Section 1.3) This is also sometimes called "zone walking". Zone
1493 enumeration is different from zone content guessing where the
1494 guesser uses a large dictionary of possible labels and sends
1495 successive queries for them, or matches the contents of NSEC3
1496 records against such a dictionary.
1498 Validation: Validation, in the context of DNSSEC, refers to one of
1499 the following:
1501 * Checking the validity of DNSSEC signatures,
1503 * Checking the validity of DNS responses, such as those including
1504 authenticated denial of existence, or
1506 * Building an authentication chain from a trust anchor to a DNS
1507 response or individual DNS RRsets in a response
1509 The first two definitions above consider only the validity of
1510 individual DNSSEC components such as the RRSIG validity or NSEC
1511 proof validity. The third definition considers the components of
1512 the entire DNSSEC authentication chain; thus, it requires
1513 "configured knowledge of at least one authenticated DNSKEY or DS
1514 RR" (as described in [RFC4035], Section 5).
1516 [RFC4033], Section 2, says that a "Validating Security-Aware Stub
1517 Resolver... performs signature validation" and uses a trust anchor
1518 "as a starting point for building the authentication chain to a
1519 signed DNS response"; thus, it uses the first and third
1520 definitions above. The process of validating an RRSIG resource
1521 record is described in [RFC4035], Section 5.3.
1523 [RFC5155] refers to validating responses throughout the document,
1524 in the context of hashed authenticated denial of existence; this
1525 uses the second definition above.
1527 The term "authentication" is used interchangeably with
1528 "validation", in the sense of the third definition above.
1529 [RFC4033], Section 2, describes the chain linking trust anchor to
1530 DNS data as the "authentication chain". A response is considered
1531 to be authentic if "all RRsets in the Answer and Authority
1532 sections of the response [are considered] to be authentic" (Quoted
1533 from [RFC4035]) DNS data or responses deemed to be authentic or
1534 validated have a security status of "secure" ([RFC4035],
1535 Section 4.3; [RFC4033], Section 5). "Authenticating both DNS keys
1536 and data is a matter of local policy, which may extend or even
1537 override the [DNSSEC] protocol extensions..." (Quoted from
1538 [RFC4033], Section 3.1)
1539 The term "verification", when used, is usually a synonym for
1540 "validation".
1542 Validating resolver: A security-aware recursive name server,
1543 security-aware resolver, or security-aware stub resolver that is
1544 applying at least one of the definitions of validation (above), as
1545 appropriate to the resolution context. For the same reason that
1546 the generic term "resolver" is sometimes ambiguous and needs to be
1547 evaluated in context (see Section 6), "validating resolver" is a
1548 context-sensitive term.
1550 Key signing key (KSK): DNSSEC keys that "only sign the apex DNSKEY
1551 RRset in a zone." (Quoted from [RFC6781], Section 3.1)
1553 Zone signing key (ZSK): "DNSSEC keys that can be used to sign all
1554 the RRsets in a zone that require signatures, other than the apex
1555 DNSKEY RRset." (Quoted from [RFC6781], Section 3.1) Also note
1556 that a ZSK is sometimes used to sign the apex DNSKEY RRset.
1558 Combined signing key (CSK): "In cases where the differentiation
1559 between the KSK and ZSK is not made, i.e., where keys have the
1560 role of both KSK and ZSK, we talk about a Single-Type Signing
1561 Scheme." (Quoted from [RFC6781], Section 3.1) This is sometimes
1562 called a "combined signing key" or "CSK". It is operational
1563 practice, not protocol, that determines whether a particular key
1564 is a ZSK, a KSK, or a CSK.
1566 Secure Entry Point (SEP): A flag in the DNSKEY RDATA that "can be
1567 used to distinguish between keys that are intended to be used as
1568 the secure entry point into the zone when building chains of
1569 trust, i.e., they are (to be) pointed to by parental DS RRs or
1570 configured as a trust anchor.... Therefore, it is suggested that
1571 the SEP flag be set on keys that are used as KSKs and not on keys
1572 that are used as ZSKs, while in those cases where a distinction
1573 between a KSK and ZSK is not made (i.e., for a Single-Type Signing
1574 Scheme), it is suggested that the SEP flag be set on all keys."
1575 (Quoted from [RFC6781], Section 3.2.3) Note that the SEP flag is
1576 only a hint, and its presence or absence may not be used to
1577 disqualify a given DNSKEY RR from use as a KSK or ZSK during
1578 validation.
1580 The original definition of SEPs was in [RFC3757]. That definition
1581 clearly indicated that the SEP was a key, not just a bit in the
1582 key. The abstract of [RFC3757] says: "With the Delegation Signer
1583 (DS) resource record (RR), the concept of a public key acting as a
1584 secure entry point (SEP) has been introduced. During exchanges of
1585 public keys with the parent there is a need to differentiate SEP
1586 keys from other public keys in the Domain Name System KEY (DNSKEY)
1587 resource record set. A flag bit in the DNSKEY RR is defined to
1588 indicate that DNSKEY is to be used as a SEP." That definition of
1589 the SEP as a key was made obsolete by [RFC4034], and the
1590 definition from [RFC6781] is consistent with [RFC4034].
1592 Trust anchor: "A configured DNSKEY RR or DS RR hash of a DNSKEY RR.
1593 A validating security-aware resolver uses this public key or hash
1594 as a starting point for building the authentication chain to a
1595 signed DNS response. In general, a validating resolver will have
1596 to obtain the initial values of its trust anchors via some secure
1597 or trusted means outside the DNS protocol." (Quoted from
1598 [RFC4033], Section 2)
1600 DNSSEC Policy (DP): A statement that "sets forth the security
1601 requirements and standards to be implemented for a DNSSEC-signed
1602 zone." (Quoted from [RFC6841], Section 2)
1604 DNSSEC Practice Statement (DPS): "A practices disclosure document
1605 that may support and be a supplemental document to the DNSSEC
1606 Policy (if such exists), and it states how the management of a
1607 given zone implements procedures and controls at a high level."
1608 (Quoted from [RFC6841], Section 2)
1610 Hardware security module (HSM): A specialized piece of hardware that
1611 is used to create keys for signatures and to sign messages without
1612 ever disclosing the private key. In DNSSEC, HSMs are often used
1613 to hold the private keys for KSKs and ZSKs and to create the
1614 signatures used in RRSIG records at periodic intervals.
1616 Signing software: Authoritative DNS servers that support DNSSEC
1617 often contain software that facilitates the creation and
1618 maintenance of DNSSEC signatures in zones. There is also stand-
1619 alone software that can be used to sign a zone regardless of
1620 whether the authoritative server itself supports signing.
1621 Sometimes signing software can support particular HSMs as part of
1622 the signing process.
1624 11. DNSSEC States
1626 A validating resolver can determine that a response is in one of four
1627 states: secure, insecure, bogus, or indeterminate. These states are
1628 defined in [RFC4033] and [RFC4035], although the definitions in the
1629 two documents differ a bit. This document makes no effort to
1630 reconcile the definitions in the two documents, and takes no position
1631 as to whether they need to be reconciled.
1633 Section 5 of [RFC4033] says:
1635 A validating resolver can determine the following 4 states:
1637 Secure: The validating resolver has a trust anchor, has a chain
1638 of trust, and is able to verify all the signatures in the
1639 response.
1641 Insecure: The validating resolver has a trust anchor, a chain
1642 of trust, and, at some delegation point, signed proof of the
1643 non-existence of a DS record. This indicates that subsequent
1644 branches in the tree are provably insecure. A validating
1645 resolver may have a local policy to mark parts of the domain
1646 space as insecure.
1648 Bogus: The validating resolver has a trust anchor and a secure
1649 delegation indicating that subsidiary data is signed, but
1650 the response fails to validate for some reason: missing
1651 signatures, expired signatures, signatures with unsupported
1652 algorithms, data missing that the relevant NSEC RR says
1653 should be present, and so forth.
1655 Indeterminate: There is no trust anchor that would indicate that a
1656 specific portion of the tree is secure. This is the default
1657 operation mode.
1659 Section 4.3 of [RFC4035] says:
1661 A security-aware resolver must be able to distinguish between four
1662 cases:
1664 Secure: An RRset for which the resolver is able to build a chain
1665 of signed DNSKEY and DS RRs from a trusted security anchor to
1666 the RRset. In this case, the RRset should be signed and is
1667 subject to signature validation, as described above.
1669 Insecure: An RRset for which the resolver knows that it has no
1670 chain of signed DNSKEY and DS RRs from any trusted starting
1671 point to the RRset. This can occur when the target RRset lies
1672 in an unsigned zone or in a descendent [sic] of an unsigned
1673 zone. In this case, the RRset may or may not be signed, but
1674 the resolver will not be able to verify the signature.
1676 Bogus: An RRset for which the resolver believes that it ought to
1677 be able to establish a chain of trust but for which it is
1678 unable to do so, either due to signatures that for some reason
1679 fail to validate or due to missing data that the relevant
1680 DNSSEC RRs indicate should be present. This case may indicate
1681 an attack but may also indicate a configuration error or some
1682 form of data corruption.
1684 Indeterminate: An RRset for which the resolver is not able to
1685 determine whether the RRset should be signed, as the resolver
1686 is not able to obtain the necessary DNSSEC RRs. This can occur
1687 when the security-aware resolver is not able to contact
1688 security-aware name servers for the relevant zones.
1690 12. Security Considerations
1692 These definitions do not change any security considerations for the
1693 DNS.
1695 13. IANA Considerations
1697 This document has no IANA actions.
1699 14. References
1701 14.1. Normative References
1703 [IANA_RootFiles]
1704 IANA, "Root Files",
1705 .
1707 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
1708 RFC 882, DOI 10.17487/RFC0882, November 1983,
1709 .
1711 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1712 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1713 .
1715 [RFC1035] Mockapetris, P., "Domain names - implementation and
1716 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1717 November 1987, .
1719 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
1720 Application and Support", STD 3, RFC 1123,
1721 DOI 10.17487/RFC1123, October 1989,
1722 .
1724 [RFC1912] Barr, D., "Common DNS Operational and Configuration
1725 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
1726 .
1728 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
1729 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
1730 August 1996, .
1732 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
1733 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
1734 RFC 2136, DOI 10.17487/RFC2136, April 1997,
1735 .
1737 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
1738 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
1739 .
1741 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
1742 and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
1743 DOI 10.17487/RFC2182, July 1997,
1744 .
1746 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1747 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
1748 .
1750 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1751 Rose, "DNS Security Introduction and Requirements",
1752 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1753 .
1755 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1756 Rose, "Resource Records for the DNS Security Extensions",
1757 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1758 .
1760 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1761 Rose, "Protocol Modifications for the DNS Security
1762 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1763 .
1765 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
1766 System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
1767 .
1769 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
1770 Security (DNSSEC) Hashed Authenticated Denial of
1771 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
1772 .
1774 [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
1775 Nameservers in Reflector Attacks", BCP 140, RFC 5358,
1776 DOI 10.17487/RFC5358, October 2008,
1777 .
1779 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
1780 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
1781 .
1783 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1784 Domain Name Mapping", STD 69, RFC 5731,
1785 DOI 10.17487/RFC5731, August 2009,
1786 .
1788 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
1789 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
1790 May 2010, .
1792 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
1793 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
1794 .
1796 [RFC6561] Livingood, J., Mody, N., and M. O'Reirdan,
1797 "Recommendations for the Remediation of Bots in ISP
1798 Networks", RFC 6561, DOI 10.17487/RFC6561, March 2012,
1799 .
1801 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
1802 Operational Practices, Version 2", RFC 6781,
1803 DOI 10.17487/RFC6781, December 2012,
1804 .
1806 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
1807 Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
1808 DOI 10.17487/RFC6840, February 2013,
1809 .
1811 [RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
1812 Framework for DNSSEC Policies and DNSSEC Practice
1813 Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
1814 .
1816 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1817 for DNS (EDNS(0))", STD 75, RFC 6891,
1818 DOI 10.17487/RFC6891, April 2013,
1819 .
1821 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
1822 DNSSEC Delegation Trust Maintenance", RFC 7344,
1823 DOI 10.17487/RFC7344, September 2014,
1824 .
1826 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1827 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
1828 2015, .
1830 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles
1831 for DNS over TLS and DNS over DTLS", RFC 8310,
1832 DOI 10.17487/RFC8310, March 2018,
1833 .
1835 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1836 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1837 January 2019, .
1839 14.2. Informative References
1841 [I-D.ietf-dprive-dnsoquic]
1842 Huitema, C., Dickinson, S., and A. Mankin, "Specification
1843 of DNS over Dedicated QUIC Connections", Work in Progress,
1844 Internet-Draft, draft-ietf-dprive-dnsoquic-04, 3 September
1845 2021, .
1848 [IANA_Resource_Registry]
1849 IANA, "Resource Record (RR) TYPEs",
1850 .
1852 [RFC0819] Su, Z. and J. Postel, "The Domain Naming Convention for
1853 Internet User Applications", RFC 819,
1854 DOI 10.17487/RFC0819, August 1982,
1855 .
1857 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
1858 host table specification", RFC 952, DOI 10.17487/RFC0952,
1859 October 1985, .
1861 [RFC1713] Romao, A., "Tools for DNS debugging", FYI 27, RFC 1713,
1862 DOI 10.17487/RFC1713, November 1994,
1863 .
1865 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1866 DOI 10.17487/RFC1995, August 1996,
1867 .
1869 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
1870 DOI 10.17487/RFC2775, February 2000,
1871 .
1873 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
1874 Requirements for the Address and Routing Parameter Area
1875 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
1876 September 2001, .
1878 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
1879 DOI 10.17487/RFC3425, November 2002,
1880 .
1882 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
1883 Stevens, "Basic Socket Interface Extensions for IPv6",
1884 RFC 3493, DOI 10.17487/RFC3493, February 2003,
1885 .
1887 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
1888 System KEY (DNSKEY) Resource Record (RR) Secure Entry
1889 Point (SEP) Flag", RFC 3757, DOI 10.17487/RFC3757, April
1890 2004, .
1892 [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
1893 DOI 10.17487/RFC3912, September 2004,
1894 .
1896 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records
1897 and DNSSEC On-line Signing", RFC 4470,
1898 DOI 10.17487/RFC4470, April 2006,
1899 .
1901 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
1902 RFC 4641, DOI 10.17487/RFC4641, September 2006,
1903 .
1905 [RFC4697] Larson, M. and P. Barber, "Observed DNS Resolution
1906 Misbehavior", BCP 123, RFC 4697, DOI 10.17487/RFC4697,
1907 October 2006, .
1909 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
1910 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
1911 December 2006, .
1913 [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security
1914 (DNSSEC) Opt-In", RFC 4956, DOI 10.17487/RFC4956, July
1915 2007, .
1917 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
1918 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
1919 .
1921 [RFC5890] Klensin, J., "Internationalized Domain Names for
1922 Applications (IDNA): Definitions and Document Framework",
1923 RFC 5890, DOI 10.17487/RFC5890, August 2010,
1924 .
1926 [RFC5891] Klensin, J., "Internationalized Domain Names in
1927 Applications (IDNA): Protocol", RFC 5891,
1928 DOI 10.17487/RFC5891, August 2010,
1929 .
1931 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and
1932 Internationalized Domain Names for Applications (IDNA)",
1933 RFC 5892, DOI 10.17487/RFC5892, August 2010,
1934 .
1936 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts
1937 for Internationalized Domain Names for Applications
1938 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,
1939 .
1941 [RFC5894] Klensin, J., "Internationalized Domain Names for
1942 Applications (IDNA): Background, Explanation, and
1943 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,
1944 .
1946 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on
1947 Encodings for Internationalized Domain Names", RFC 6055,
1948 DOI 10.17487/RFC6055, February 2011,
1949 .
1951 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
1952 DOI 10.17487/RFC6265, April 2011,
1953 .
1955 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
1956 RFC 6303, DOI 10.17487/RFC6303, July 2011,
1957 .
1959 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
1960 Cheshire, "Internet Assigned Numbers Authority (IANA)
1961 Procedures for the Management of the Service Name and
1962 Transport Protocol Port Number Registry", BCP 165,
1963 RFC 6335, DOI 10.17487/RFC6335, August 2011,
1964 .
1966 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
1967 Internationalization in the IETF", BCP 166, RFC 6365,
1968 DOI 10.17487/RFC6365, September 2011,
1969 .
1971 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
1972 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
1973 .
1975 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
1976 DOI 10.17487/RFC6762, February 2013,
1977 .
1979 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
1980 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
1981 February 2014, .
1983 [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
1984 Registration Data Access Protocol (RDAP)", STD 95,
1985 RFC 7480, DOI 10.17487/RFC7480, March 2015,
1986 .
1988 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
1989 Registration Data Access Protocol (RDAP)", STD 95,
1990 RFC 7481, DOI 10.17487/RFC7481, March 2015,
1991 .
1993 [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
1994 Protocol (RDAP) Query Format", RFC 7482,
1995 DOI 10.17487/RFC7482, March 2015,
1996 .
1998 [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the
1999 Registration Data Access Protocol (RDAP)", RFC 7483,
2000 DOI 10.17487/RFC7483, March 2015,
2001 .
2003 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data
2004 (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
2005 2015, .
2007 [RFC7485] Zhou, L., Kong, N., Shen, S., Sheng, S., and A. Servin,
2008 "Inventory and Analysis of WHOIS Registration Objects",
2009 RFC 7485, DOI 10.17487/RFC7485, March 2015,
2010 .
2012 [RFC7793] Andrews, M., "Adding 100.64.0.0/10 Prefixes to the IPv4
2013 Locally-Served DNS Zones Registry", BCP 163, RFC 7793,
2014 DOI 10.17487/RFC7793, May 2016,
2015 .
2017 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
2018 and P. Hoffman, "Specification for DNS over Transport
2019 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2020 2016, .
2022 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
2023 Transport Layer Security (DTLS)", RFC 8094,
2024 DOI 10.17487/RFC8094, February 2017,
2025 .
2027 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS
2028 Resolver with Priming Queries", BCP 209, RFC 8109,
2029 DOI 10.17487/RFC8109, March 2017,
2030 .
2032 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
2033 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
2034 .
2036 [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A.
2037 Mankin, "DNS Zone Transfer over TLS", RFC 9103,
2038 DOI 10.17487/RFC9103, August 2021,
2039 .
2041 [RSSAC026] Root Server System Advisory Committee (RSSAC), "RSSAC
2042 Lexicon", 2017,
2043 .
2046 Appendix A. Definitions Updated by This Document
2048 The following definitions from RFCs are updated by this document:
2050 * Forwarder in [RFC2308]
2052 * QNAME in [RFC2308]
2054 * Secure Entry Point (SEP) in [RFC3757]; note, however, that this
2055 RFC is already obsolete (see [RFC4033], [RFC4034], [RFC4035]).
2057 Appendix B. Definitions First Defined in This Document
2059 The following definitions are first defined in this document:
2061 * "Alias" in Section 2
2063 * "Apex" in Section 7
2065 * "arpa" in Section 7
2067 * "Authoritative DoT (ADot)" in Section 6
2069 * "Bailiwick" in Section 7
2071 * "Class independent" in Section 5
2073 * "Classic DNS" in Section 6
2075 * "Delegation-centric zone" in Section 7
2077 * "Delegation" in Section 7
2079 * "DNS operator" in Section 9
2081 * "DNSSEC-aware" in Section 10
2083 * "DNSSEC-unaware" in Section 10
2084 * "Forwarding" in Section 6
2086 * "Full resolver" in Section 6
2088 * "Fully-qualified domain name" in Section 2
2090 * "Global DNS" in Section 2
2092 * "Hardware Security Module (HSM)" in Section 10
2094 * "Host name" in Section 2
2096 * "IDN" in Section 2
2098 * "In-bailiwick" in Section 7
2100 * "Iterative resolution" in Section 6
2102 * "Label" in Section 2
2104 * "Locally served DNS zone" in Section 2
2106 * "Naming system" in Section 2
2108 * "Negative response" in Section 3
2110 * "Non-recursive query" in Section 6
2112 * "Open resolver" in Section 6
2114 * "Out-of-bailiwick" in Section 7
2116 * "Passive DNS" in Section 6
2118 * "Policy-implementing resolver" in Section 6
2120 * "Presentation format" in Section 5
2122 * "Priming" in Section 6
2124 * "Private DNS" in Section 2
2126 * "Recrusive DoT (RDot)" in Section 6
2128 * "Recursive resolver" in Section 6
2130 * "Referrals" in Section 4
2131 * "Registrant" in Section 9
2133 * "Registrar" in Section 9
2135 * "Registry" in Section 9
2137 * "Root zone" in Section 7
2139 * "Secure Entry Point (SEP)" in Section 10
2141 * "Signing software" in Section 10
2143 * "Split DNS" in Section 6
2145 * "Stub resolver" in Section 6
2147 * "Subordinate" in Section 8
2149 * "Superordinate" in Section 8
2151 * "TLD" in Section 2
2153 * "Validating resolver" in Section 10
2155 * "Validation" in Section 10
2157 * "View" in Section 6
2159 * "Zone transfer" in Section 6
2161 Acknowledgements
2163 RFC 8499 and its predecessor, RFC 7719, were co-authored by Andrew
2164 Sullivan. The current document, which is a small update to RFC 8499,
2165 has just two authors. Andrew's work on the earlier documents is
2166 greatly appreciated.
2168 Numerous people made significant contributions to RFC 8499 and RFC
2169 7719. Please see the acknowledgements sections in those two
2170 documents for the extensive list of contributors.
2172 Index
2174 A C D E F G H I K L M N O P Q R S T U V W X Z
2176 A
2178 ADoT
2179 Section 6
2180 AXoT
2181 Section 6
2182 Address records
2183 Section 5
2184 Alias
2185 Section 2
2186 Anycast
2187 Section 6
2188 Apex
2189 Section 7
2190 Asterisk label
2191 Section 8
2192 Authoritative data
2193 Section 7
2194 Authoritative server
2195 Section 6
2196 Authoritative-only server
2197 Section 6
2198 arpa: Address and Routing Parameter Area Domain
2199 Section 7
2201 C
2203 CNAME
2204 Section 2
2205 Canonical name
2206 Section 2
2207 Child
2208 Section 7
2209 Class
2210 Section 4
2211 Class independent
2212 Section 5
2213 Classic DNS
2214 Section 6
2215 Closest encloser
2216 Section 8
2217 Closest provable encloser
2218 Section 8
2219 Combined signing key (CSK)
2220 Section 10
2222 D
2224 DNS operator
2225 Section 9
2226 DNS-over-HTTPS
2227 Section 6
2228 DNS-over-QUIC
2229 Section 6
2230 DNS-over-TLS
2231 Section 6
2232 DNSSEC Policy (DP)
2233 Section 10
2234 DNSSEC Practice Statement (DPS)
2235 Section 10
2236 DNSSEC-aware and DNSSEC-unaware
2237 Section 10
2238 Delegation
2239 Section 7
2240 Delegation-centric zone
2241 Section 7
2242 DoH
2243 Section 6
2244 DoQ
2245 Section 6
2246 DoT
2247 Section 6
2248 Domain name
2249 Section 2
2251 E
2253 EDNS
2254 Section 5
2255 EPP
2256 Section 9
2257 Empty non-terminals (ENT)
2258 Section 7
2260 F
2262 FORMERR
2263 Section 3
2264 Fast flux DNS
2265 Section 7
2266 Forward lookup
2267 Section 7
2268 Forwarder
2269 Section 6
2270 Forwarding
2271 Section 6
2272 Full resolver
2273 Section 6
2274 Full-service resolver
2275 Section 6
2276 Fully-qualified domain name (FQDN)
2277 Section 2
2279 G
2281 Global DNS
2282 Section 2
2283 Glue records
2284 Section 7
2286 H
2288 Hardware security module (HSM)
2289 Section 10
2290 Hidden master
2291 Section 6
2292 Host name
2293 Section 2
2295 I
2297 IDN
2298 Section 2
2299 IXoT
2300 Section 6
2301 In-bailiwick
2302 Section 7
2303 Insecure delegation
2304 Section 10
2305 Instance
2306 Section 6
2307 Internationalized Domain Name
2308 Section 2
2309 Iterative mode
2310 Section 6
2311 Iterative resolution
2312 Section 6
2314 K
2316 Key signing key (KSK)
2317 Section 10
2319 L
2321 Label
2322 Section 2
2324 Lame delegation
2325 Section 7
2326 Locally served DNS zone
2327 Section 2
2329 M
2331 Master file
2332 Section 5
2333 Master server
2334 Section 6
2335 Multicast DNS
2336 Section 2
2337 mDNS
2338 Section 2
2340 N
2342 NODATA
2343 Section 3
2344 NOERROR
2345 Section 3
2346 NOTIMP
2347 Section 3
2348 NS
2349 Section 6
2350 NSEC
2351 Section 10
2352 NSEC3
2353 Section 10
2354 NXDOMAIN
2355 Section 3
2356 Naming system
2357 Section 2, Paragraph 1.2.1
2358 Negative caching
2359 Section 6
2360 Negative response
2361 Section 3
2362 Next closer name
2363 Section 8
2364 Non-recursive query
2365 Section 6
2367 O
2369 OPT
2370 Section 5
2371 Occluded name
2372 Section 7
2373 Open resolver
2374 Section 6
2375 Opt-out
2376 Section 10
2377 Origin
2378 Section 7
2379 Out-of-bailiwick
2380 Section 7
2381 Owner
2382 Section 5
2383 on-line signing
2384 Section 10
2385 online signing
2386 Section 10
2388 P
2390 Parent
2391 Section 7
2392 Passive DNS
2393 Section 6
2394 Policy-implementing resolver
2395 Section 6
2396 Presentation format
2397 Section 5
2398 Primary master
2399 Section 6
2400 Primary server
2401 Section 6
2402 Priming
2403 Section 6
2404 Privacy-enabling DNS server
2405 Section 6
2406 Private DNS
2407 Section 2
2408 Public suffix
2409 Section 9
2411 Q
2413 QNAME
2414 Section 4
2416 R
2418 RDAP
2419 Section 9
2421 RDoT
2422 Section 6
2423 REFUSED
2424 Section 3
2425 RR
2426 Section 5
2427 RRset
2428 Section 5
2429 Recursive DoT
2430 Section 6
2431 Recursive mode
2432 Section 6, Paragraph 4.10.1
2433 Recursive query
2434 Section 6
2435 Recursive resolver
2436 Section 6
2437 Referrals
2438 Section 4
2439 Registrant
2440 Section 9
2441 Registrar
2442 Section 9
2443 Registry
2444 Section 9
2445 Resolver
2446 Section 6
2447 Reverse DNS, reverse lookup
2448 Section 7
2449 Root hints
2450 Section 6
2451 Root zone
2452 Section 7
2454 S
2456 SERVFAIL
2457 Section 3
2458 SOA
2459 Section 5
2460 SOA field names
2461 Section 5
2462 Secondary server
2463 Section 6
2464 Secure Entry Point (SEP)
2465 Section 10
2466 Service name
2467 Section 7
2468 Signed zone
2469 Section 10
2470 Signing software
2471 Section 10
2472 Slave server
2473 Section 6
2474 Source of Synthesis
2475 Section 8, Paragraph 1.14.1
2476 Split DNS
2477 Section 6
2478 Split-horizon DNS
2479 Section 6
2480 Stealth server
2481 Section 6
2482 Stub resolver
2483 Section 6
2484 Subdomain
2485 Section 2
2486 Subordinate
2487 Section 9
2488 Superordinate
2489 Section 9
2491 T
2493 TLD
2494 Section 2
2495 TTL
2496 Section 5
2497 Trust anchor
2498 Section 10
2500 U
2502 Unsigned zone
2503 Section 10
2505 V
2507 Validating resolver
2508 Section 10
2509 Validation
2510 Section 10, Paragraph 2.26.1
2511 View
2512 Section 6
2514 W
2516 WHOIS
2517 Section 9
2518 Wildcard
2519 Section 8
2520 Wildcard domain name
2521 Section 8
2523 X
2525 XoT
2526 Section 6
2528 Z
2530 Zone
2531 Section 7
2532 Zone cut
2533 Section 7
2534 Zone enumeration
2535 Section 10
2536 Zone signing key (ZSK)
2537 Section 10
2538 Zone transfer
2539 Section 6
2541 Authors' Addresses
2543 Paul Hoffman
2544 ICANN
2546 Email: paul.hoffman@icann.org
2548 Kazunori Fujiwara
2549 Japan Registry Services Co., Ltd.
2551 Email: fujiwara@jprs.co.jp