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