RFC 7719

DNS Terminology

📅 published December 2015, from ietf

RFC 7719: DNS Terminology 💖

Okay, title-block tea ☕: this is RFC 7719, called DNS Terminology, and it was published in December 2015. It's an Informational doc, so it's here to inform, not a Standards Track spec 🙈. Three people wrote it: P. Hoffman (ICANN), A. Sullivan (Dyn), and K. Fujiwara (JPRS). The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates ✨.

Abstract 🌸

The DNS is defined in literally dozens of different RFCs 💀. The words that implementers, developers, and operators use for it have shifted over the decades since it was first defined. This doc gives current definitions for a bunch of DNS terms, all in one spot 🎀.

Status of This Memo 🦋

This document is not an Internet Standards Track specification, so it's published for informational purposes. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check out Section 2 of RFC 5741 if you're curious 🧐.

Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7719 💜.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. They also come without warranty, as described in the Simplified BSD License 🫶.

Table of Contents 💜

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Names . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  DNS Header and Response Codes . . . . . . . . . . . . . . . .   6
4.  Resource Records  . . . . . . . . . . . . . . . . . . . . . .   7
5.  DNS Servers and Clients . . . . . . . . . . . . . . . . . . .   9
6.  Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
7.  Registration Model  . . . . . . . . . . . . . . . . . . . . .  17
8.  General DNSSEC  . . . . . . . . . . . . . . . . . . . . . . .  18
9.  DNSSEC States . . . . . . . . . . . . . . . . . . . . . . . .  20
10. Security Considerations . . . . . . . . . . . . . . . . . . .  22
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
  11.1.  Normative References . . . . . . . . . . . . . . . . . .  22
  11.2.  Informative References . . . . . . . . . . . . . . . . .  24
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  27
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  27

1. Introduction ✨

Okay so the Domain Name System (DNS) is a simple query-response protocol 🫶. Messages going in both directions have the same format, which is honestly iconic. The protocol and message format are defined in [RFC1034] and [RFC1035]. Those RFCs defined some terms, and later documents added others 🌈. Plot twist: some terms from RFCs 1034 and 1035 now mean something a little different than they did back in 1987 💀.

This document collects a wide variety of DNS-related terms 🍓. Some were precisely defined in earlier RFCs, some were loosely defined, and some were never defined in any earlier RFC at all.

Most of the definitions here are the consensus definition of the DNS community, meaning protocol developers and operators both 💅. Some differ from earlier RFCs, and those differences get noted. When the consensus definition matches an RFC, that RFC is quoted. When the consensus has shifted a bit, the RFC gets mentioned, but the new stand-alone definition is given instead 🧚.

It's important to note that, while writing this, it became clear some DNS terms get interpreted super differently by different DNS experts 😭. Some terms defined in early DNS RFCs now have generally agreed definitions that are different from the originals. So the authors plan to follow this doc with a substantial revision in the not-distant future 👑. That revision will probably dig deeper into some terms and add new ones, and it will also update some of the RFCs with new definitions.

The terms are organized loosely by topic ⭐. Some definitions are brand-new terms for things the DNS community talks about all the time but never had official names for.

Other organizations sometimes define DNS-related terms their own way 🦋. For example, the W3C defines "domain" at https://specs.webplatform.org/url/webspecs/develop/.

Note that there is no single consistent definition of "the DNS" 🙈. It can be considered some combination of the following:

  • a commonly used naming scheme for objects on the Internet;
  • a distributed database representing the names and certain properties of these objects;
  • an architecture providing distributed maintenance, resilience, and loose coherency for this database; and
  • a simple query-response protocol (as mentioned below) implementing this architecture.

Capitalization in DNS terms is honestly all over the place among RFCs and DNS practitioners 🌸. The capitalization used in this document is a best guess at current practices. It's not meant to say that other capitalization styles are wrong or archaic, so no drama 💖. Sometimes multiple styles show up for the same term because the doc is quoting different RFCs.

2. Names ✨

okay so names are where things get lowkey chaotic, bestie, so let's go term by term 🫶

Domain name: Section 3.1 of [RFC1034] describes "the domain name space" as a tree 🌳 "Each node has a label, which is zero to 63 octets in length. ... The domain name of a node is the list of the labels on the path from the node to the root of the tree. ... To simplify implementations, the total number of octets that represent a domain name (i.e., the sum of all label octets and label lengths) is limited to 255." 💅 And any label in a domain name can contain any octet value, so it's wild out here.

Fully qualified domain name (FQDN): This one gets used as a fancy way of saying "domain name of a node," but it's kinda ambiguous 🙈 Strictly speaking, an FQDN includes every label, even the final zero-length label of the root, so it would be written www.example.net. (see that terminating dot? iconic). Since every name eventually shares the common root, people usually drop the dot and write www.example.net and still call it "fully qualified" 💖 The term first showed up in [RFC819]. In this document, names are often written relative to the root.

The need for the term comes from partially qualified domain names, where some of the right-most names are left off and only context tells you what they mean 🧩

Label: The identifier of one node in the sequence of nodes that a fully qualified domain name points to 🎀

Host name: This term, and its equivalent "hostname," gets used everywhere but isn't defined in [RFC1034], [RFC1035], [RFC1123], or [RFC2181] 😭 The DNS was first deployed into the Host Tables environment described in [RFC952], and the term probably came along informally from there. Over time the meaning seems to have drifted. "Host name" often means a domain name that follows the rules in Section 3.5 of [RFC1034], the "preferred name syntax." Remember that any label can contain any octet value, so hostnames are generally considered to be domain names where every label follows the "preferred name syntax," with one amendment: labels can start with ASCII digits (this amendment comes from Section 2.1 of [RFC1123]) 🌸

People also use "hostname" for just the first label of an FQDN, like "printer" in printer.admin.example.com (sometimes operating systems even formalize this in configuration ⚙️). And people sometimes use it for any name that refers to a machine, even if those names include labels that don't follow the "preferred name syntax." Messy but valid 🦋

TLD: A Top-Level Domain is a zone that sits one layer below the root, like com or jp 👑 From the point of view of the DNS, there is nothing special about TLDs. Most of them are also delegation-centric zones, and there are significant policy issues around how they operate. TLDs are often split into sub-groups like Country Code Top-Level Domains (ccTLDs), Generic Top-Level Domains (gTLDs), and others. That division is a matter of policy and beyond the scope of this document, so we're not going there 🙅‍♀️

IDN: Short for "Internationalized Domain Name" 🌈 The IDNA protocol is the standard mechanism for handling domain names with non-ASCII characters in applications in the DNS. The current standard, normally called "IDNA2008," is defined in [RFC5890], [RFC5891], [RFC5892], [RFC5893], and [RFC5894]. Those documents define lots of IDN-specific terms, like "LDH label," "A-label," and "U-label." [RFC6365] defines more internationalization terms (some of which relate to IDNs), and [RFC6055] has a much more extensive discussion of IDNs, including some new terminology 📚

Subdomain: "A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name." (Quoted from [RFC1034], Section 3.1). For example, in the host name nnn.mmm.example.com, both mmm.example.com and nnn.mmm.example.com are subdomains of example.com 🧚

Alias: The owner of a CNAME resource record, or a subdomain of the owner of a DNAME resource record [RFC6672]. See also "canonical name" 🦋

Canonical name: A CNAME resource record "identifies its owner name as an alias, and specifies the corresponding canonical name in the RDATA section of the RR." (Quoted from [RFC1034], Section 3.6.2) This use of "canonical" is related to the mathematical concept of "canonical form," which is a very nerdy and very cute connection 🤓

CNAME: "It is traditional to refer to the owner of a CNAME record as 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 'canonical name', and the owner of a CNAME record is an alias, not a canonical name." (Quoted from [RFC2181], Section 10.1.1) 😭 Yes, the naming is a whole mood.

Public suffix: "A domain that is controlled by a public registry." (Quoted from [RFC6265], Section 5.3) A common definition is a domain under which subdomains can be registered, and on which HTTP cookies ([RFC6265]) should not be set 🍪 Nothing in a domain name tells you whether it's a public suffix. That can only be figured out by outside means. In fact, both a domain and a subdomain of that domain can be public suffixes 🤯 When this document was published, the IETF DBOUND Working Group [DBOUND] was dealing with issues around public suffixes.

One resource for identifying public suffixes is the Public Suffix List (PSL) maintained by Mozilla at http://publicsuffix.org/ 💜 For example, when this document was published, the com.au domain was listed as a public suffix in the PSL. (This example might change in the future, so don't lock it in forever 🙃)

Also, the term "public suffix" is controversial in the DNS community for many reasons, and it may be significantly changed in the future 💀 One example of how hard it is to call a domain a public suffix is that the designation can change over time as the registration policy for the zone changes. The uk TLD around the time this document was published is a good example of that 🇬🇧

3. DNS Header and Response Codes 🎀

The header of a DNS message is its first 12 octets 📦 Many of the fields and flags in the header diagram in Sections 4.1.1 through 4.1.3 of [RFC1035] get referred to by their names in that diagram. For example, the response codes are called "RCODEs," the data for a record is called the "RDATA," and the authoritative answer bit is often called "the AA flag" or "the AA bit" ✨

Some response codes defined in [RFC1035] have gotten their own shorthand names. Common response code names that show up without the numeric value are "FORMERR," "SERVFAIL," and "NXDOMAIN" (the latter of which is also called "Name Error") 🙈 All of the RCODEs are listed at http://www.iana.org/assignments/dns-parameters, although that site uses mixed-case capitalization, while most documents use all-caps. Mixed case vs all-caps, the eternal struggle 💅

NODATA: "A pseudo RCODE which indicates that the name is valid for the given class, but there are no records of the given type. A NODATA response has to be inferred from the answer." (Quoted from [RFC2308], Section 1.) "NODATA is indicated by an answer with the RCODE set to NOERROR and no relevant answers in the answer section. The authority section will contain an SOA record, or there will be no NS records there." (Quoted from [RFC2308], Section 2.2.) Referrals have a similar format to NODATA replies, and [RFC2308] explains how to tell them apart 🧐

The term "NXRRSET" is sometimes used as a synonym for NODATA. That's a mistake, though, because NXRRSET is a specific error code defined in [RFC2136] 🙅‍♀️ Not the same vibe at all.

Negative response: A response that indicates that a particular RRset does not exist, or whose RCODE indicates the nameserver cannot answer. Sections 2 and 7 of [RFC2308] describe the types of negative responses in detail 🌧️

Referrals: Data from the authority section of a non-authoritative answer. [RFC1035] Section 2.1 defines "authoritative" data. However, referrals at zone cuts (defined in Section 6) are not authoritative. Referrals may be zone cut NS resource records and their glue records. NS records on the parent side of a zone cut are an authoritative delegation, but they're normally not treated as authoritative data. Basically, a referral is how a server says "I don't know the answer, but I know where to send you to get it" 🗺️ Historically, many authoritative servers answered with a referral to the root zone when queried for a name they weren't authoritative for, but this practice has declined 📉

4. Resource Records ✨

Okay bestie, this section is the dictionary for all the DNS vocab we've been throwing around 📖💅 Let's go through it term by term!

RR: 💖 Short for resource record! ([RFC1034], Section 3.6.)

RRset: 🎀 A set of resource records with the same label, class and type, but with different data. (Definition from [RFC2181].) Some docs spell it RRSet, same thing 🦋 Quick clarification: "same label" here means "same owner name" 🫶 [RFC2181] also says "the TTLs of all RRs in an RRSet must be the same". Lowkey important! 😭 And no, this is definitely NOT the same as "the response one gets to a query for QTYPE=ANY" 🙈 That's an unfortunate misunderstanding, not what RRset means.

EDNS: 🌈 The extension mechanisms for DNS, defined in [RFC6891]. You'll also see it called "EDNS0" or "EDNS(0)" to show the version number 🔥 EDNS lets DNS clients and servers specify message sizes bigger than the original 512 octet limit, expand the response code space, and potentially carry extra options that affect how a DNS query gets handled. Main character energy 👑

OPT: 🧚 A pseudo-RR (sometimes called a "meta-RR") that is used only to contain control information pertaining to the question-and-answer sequence of a specific transaction. (Definition from [RFC6891], Section 6.1.1.) It's used by EDNS 💜

Owner: 🍓 The domain name where a RR is found ([RFC1034], Section 3.6). You'll often see it in the term "owner name" ✨

SOA field names: 🌸 DNS docs, including this one, often refer to the fields in the RDATA of an SOA resource record by field name 💅 Those fields are defined in Section 3.3.13 of [RFC1035]. In the order they appear in the SOA RDATA, they're MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, and MINIMUM. Plot twist: the meaning of the MINIMUM field got updated in Section 4 of [RFC2308] 😭 The new deal is that MINIMUM is only "the TTL to be used for negative responses". This document tends to use field names instead of terms that describe the fields, so keep that in mind 🫶

TTL: 🦋 The maximum "time to live" of a resource record. Quoting [RFC2181], Section 8: "A TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1. When transmitted, the TTL is encoded in the less significant 31 bits of the 32 bit TTL field, with the most significant, or sign, bit set to zero." 🙈 Also, [RFC1035] erroneously said this was a signed integer, but [RFC2181] fixed that 💀

The TTL "specifies the time interval that the resource record may be cached before the source of the information should again be consulted". (Quoted from [RFC1035], Section 3.2.1.) Also: "the time interval (in seconds) that the resource record may be cached before it should be discarded". (Quoted from [RFC1035], Section 4.1.3.) Even though the TTL is defined for a single resource record, the TTL of every resource record in an RRset is required to be the same ([RFC2181], Section 5.2). Bestie, that's a rule 🔥

So why is it the maximum time to live? 🌈 A cache operator might decide to shorten it for operational purposes, like if there's a policy to disallow TTL values over a certain number. Also, if a value is flushed from the cache while its value is still positive, the value effectively becomes zero 💅 Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL), even though this goes against the advice in RFC 1035. Not it 💀

There's also the concept of a "default TTL" for a zone 🧁 It can be a configuration parameter in the server software, and it's often expressed as a default for the entire server plus a default for a zone using the $TTL directive in a zone file. The $TTL directive was added to the master file format by [RFC2308] ✨

Class independent: 🎀 A resource record type whose syntax and semantics are the same for every DNS class. A resource record type that is not class independent has different meanings depending on the DNS class of the record, or the meaning is undefined for classes other than IN (class 1, the Internet). Ngl, IN is the main one we care about 🌸

5. DNS Servers and Clients ✨

okay so this section sorts out who's who in DNS: the systems that act as DNS clients, DNS servers, or both 🎀 let's get into the glossary bestie 💅

Resolver: a program "that extract[s] information from name servers in response to client requests." (Quoted from [RFC1034], Section 2.4) "The resolver is located on the same machine as the program that requests the resolver's services, but it may need to consult name servers on other hosts." (Quoted from [RFC1034], Section 5.1) so a resolver performs queries for a name, type, and class, and receives answers 🦋 the logical function is called "resolution". in practice the term usually refers to some specific type of resolver (some are defined below), so you need the context to know which one is meant 🫶

Stub resolver: a resolver that cannot perform all resolution itself 🧚 stub resolvers generally depend on a recursive resolver to do the actual resolution function. they get discussed but never fully defined in Section 5.3.1 of [RFC1034]. the full definition lives in Section 6.1.3.1 of [RFC1123] 💖

Iterative mode: a resolution mode of a server that receives DNS queries and responds with a referral to another server. Section 2.3 of [RFC1034] describes this as "The server refers the client to another server and lets the client pursue the query". a resolver that works in iterative mode is sometimes called an "iterative resolver" ✨

Recursive mode: a resolution mode of a server that receives DNS queries and either responds to them from a local cache, or sends queries to other servers to get the final answers to the original queries 🌈 Section 2.3 of [RFC1034] describes this as "The first server pursues the query for the client at another server". a server in recursive mode can be thought of as having a name server side (which answers the query) and a resolver side (which performs the resolution function) 🍓 systems in this mode are commonly called "recursive servers", and sometimes "recursive resolvers". strictly speaking, the difference is that one of them sends queries to another recursive server and the other doesn't. but in practice you can't know in advance whether the server you're querying will also do recursion, so both terms get used interchangeably 🙈

Full resolver: this term is used in [RFC1035], but it isn't defined there 💀 RFC 1123 defines a "full-service resolver" that may or may not be what [RFC1035] meant by "full resolver". this term isn't properly defined in any RFC, so it's a bit of a vibe check 🌸

Full-service resolver: Section 6.1.3.1 of [RFC1123] defines this term to mean a resolver that acts in recursive mode with a cache (and meets other requirements) 👑

Priming: the mechanism a resolver uses to figure out where to send queries before there's anything in its cache 🧚 priming is most often done from a configuration setting that holds a list of authoritative servers for the root zone 🫶

Negative caching: "The storage of knowledge that something does not exist, cannot give an answer, or does not give an answer." (Quoted from [RFC2308], Section 1) storing the fact that an answer doesn't exist, so you don't keep asking for it 💅

Authoritative server: "A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers." (Quoted from [RFC2182], Section 2.) it's a system that responds to DNS queries with information about zones it has been configured to answer for, with the AA flag in the response header set to 1 🦋 it's a server that has authority over one or more DNS zones. it's possible for an authoritative server to respond to a query without the parent zone having delegated authority to that server, so keep that in mind 🌈 authoritative servers also give out "referrals", usually to child zones delegated from them. these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections ✨

Authoritative-only server: a name server that only serves authoritative data and ignores requests for recursion 🎀 it will "not normally generate any queries of its own. Instead, it answers non-recursive queries from iterative resolvers looking for information in zones it serves." (Quoted from [RFC4697], Section 2.4) main character energy, no recursion needed 👑

Zone transfer: the act of a client requesting a copy of a zone and an authoritative server sending the needed information. (See Section 6 for a description of zones.) there are two common standard ways to do zone transfers 🍓 the AXFR ("Authoritative Transfer") mechanism copies the full zone (described in [RFC5936]), and the IXFR ("Incremental Transfer") mechanism copies only the parts of the zone that have changed (described in [RFC1995]). lots of systems use non-standard methods for zone transfer outside the DNS protocol too 🫶

Secondary server: "An authoritative server which uses zone transfer to retrieve the zone" (Quoted from [RFC1996], Section 2.1). [RFC2182] describes secondary servers in detail 🌸 early DNS RFCs such as [RFC1996] called this a "slave", but the current common usage has shifted to "secondary". secondary servers are also discussed in [RFC1034] 💖

Slave server: see secondary server 🙈

Primary server: "Any authoritative server configured to be the source of zone transfer for one or more [secondary] servers" (Quoted from [RFC1996], Section 2.1) or, more specifically, "an authoritative server configured to be the source of AXFR or IXFR data for one or more [secondary] servers" (Quoted from [RFC2136]). early DNS RFCs such as [RFC1996] called this a "master", but the current common usage has shifted to "primary" 🦋 primary servers are also discussed in [RFC1034] ✨

Master server: see primary server 💀

Primary master: "The primary master is named in the zone's SOA MNAME field and optionally by an NS RR". (Quoted from [RFC1996], Section 2.1). [RFC2136] defines "primary master" as "Master server at the root of the AXFR/IXFR dependency graph. The primary master is named in the zone's SOA MNAME field and optionally by an NS RR. There is by definition only one primary master server per zone." 🌈 the idea of a primary master is only used by [RFC2136], and it's considered archaic in other parts of the DNS 🎀

Stealth server: this is "like a slave server except not listed in an NS RR for the zone." (Quoted from [RFC1996], Section 2.1) 🧚 sneaky, but make it make sense 🙈

Hidden master: a stealth server that is a master for zone transfers 🌸 "In this arrangement, the master name server that processes the updates is unavailable to general hosts on the Internet; it is not listed in the NS RRset." (Quoted from [RFC6781], Section 3.4.3.) an earlier RFC, [RFC4641], said that the hidden master's name appears in the SOA RRs MNAME field, although in some setups the name doesn't appear at all in the public DNS 💜 a hidden master can be either a secondary or a primary master 👑

Forwarding: the process of one server sending a DNS query with the RD bit set to 1 to another server to resolve that query 🍓 forwarding is a function of a DNS resolver, and it's different from simply blindly relaying queries 💅

[RFC5625] doesn't give a specific definition for forwarding, but it describes in detail what features a system that forwards needs to support 🫶 systems that forward are sometimes called "DNS proxies", but that term hasn't been defined yet (not even in [RFC5625]) 🙈

Forwarder: Section 1 of [RFC2308] describes a forwarder as "a nameserver used to resolve queries instead of directly using the authoritative nameserver chain". [RFC2308] further says "The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers." 🦋 that definition seems to suggest forwarders normally only query authoritative servers. in current use, though, forwarders often stand between stub resolvers and recursive servers ✨ [RFC2308] is silent on whether a forwarder is iterative-only or can be a full-service resolver 🌈

Policy-implementing resolver: a resolver acting in recursive mode that changes some of the answers it returns based on policy criteria, such as to prevent access to malware sites or objectionable content 🎀 in general, a stub resolver has no idea whether upstream resolvers implement such policy or, if they do, the exact policy about what changes will be made 🧚 in some cases, the user of the stub resolver picked the policy-implementing resolver on purpose to implement those policies. in other cases, policies are imposed without the user of the stub resolver being informed 😭

Open resolver: a full-service resolver that accepts and processes queries from any (or nearly any) stub resolver 🌸 this is sometimes also called a "public resolver", although "public resolver" is used more for open resolvers that are meant to be open, as opposed to the vast majority of open resolvers that are probably misconfigured to be open 💀

View: a configuration for a DNS server that lets it give different answers depending on attributes of the query 🍓 typically views differ by the source IP address of a query, but they can also be based on the destination IP address, the type of query (such as AXFR), whether it's recursive, and so on 💖 views are often used to provide more names or different addresses to queries from "inside" a protected network than to those "outside" that network. views aren't a standardized part of the DNS, but they're widely implemented in server software 👑

Passive DNS: a mechanism to collect large amounts of DNS data by storing DNS responses from servers 🫶 some of these systems also collect the DNS queries associated with the responses, and this can raise privacy issues 😭 passive DNS databases can answer historical questions about DNS zones, such as which records were available for them at what times in the past 🦋 they also allow searching of the stored records on keys other than just the name, such as "find all names which have A records of a particular value" 🌈

Anycast: "The practice of making a particular service address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations." (Quoted from [RFC4786], Section 2) 🧚✨

6. Zones ✨

okay bestie, this section is all about zones 🗺️ and the words we use when we talk about the chunks of DNS that servers actually hand out. let's get into it 💅

Zone: 🌸 "Authoritative information is organized into units called 'zones', and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone." (Quoted from [RFC1034], Section 2.4) so zones are the little bundles of authoritative info that get passed around to the backup name servers too 🫶

Child: 🦋 "The entity on record that has the delegation of the domain from the Parent." (Quoted from [RFC7344], Section 1.1) the child is the one holding the delegation 💖

Parent: 🌷 "The domain in which the Child is registered." (Quoted from [RFC7344], Section 1.1) The parent is where the child gets registered. Earlier, "parent name server" was defined in [RFC882] as "the name server that has authority over the place in the domain name space that will hold the new domain". (Note that [RFC882] was obsoleted by [RFC1034] and [RFC1035].) [RFC819] also has some description of the relationship between parents and children. it's a whole history thing and i'm obsessed 📚

Origin: 🍓 this one has two meanings, so pay attention 👀

  • (a) "The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent). The name of the zone is the same as the name of the domain at the zone's origin." (Quoted from [RFC2181], Section 6.) These days, this sense of "origin" and "apex" (defined below) are often used interchangeably.
  • (b) The domain name within which a given relative domain name appears in zone files. Generally seen in the context of "$ORIGIN", which is a control entry defined in [RFC1035], Section 5.1, as part of the master file format. For example, if the $ORIGIN is set to example.org., then a master file line for www is in fact an entry for www.example.org.. 🧚

Apex: 👑 The point in the tree at an owner of an SOA and corresponding authoritative NS RRset. This is also called the "zone apex". [RFC4033] defines it as "the name at the child's side of a zone cut". The "apex" can usefully be thought of as a data-theoretic description of a tree structure, and "origin" is the name of the same concept when it is implemented in zone files. The distinction is not always maintained in use, however, and one can find uses that conflict subtly with this definition. [RFC1034] uses the term "top node of the zone" as a synonym of "apex", but that term is not widely used. These days, the first sense of "origin" (above) and "apex" are often used interchangeably. ngl the apex vs origin thing is lowkey confusing, but the vibe is: same concept, different outfit 💅

Zone cut: ✂️ The delimitation point between two zones where the origin of one of the zones is the child of the other zone.

"Zones are delimited by 'zone cuts'. Each zone cut separates a 'child' zone (below the cut) from a 'parent' zone (above the cut). (Quoted from [RFC2181], Section 6; note that this is barely an ostensive definition.) Section 4.2 of [RFC1034] uses "cuts" as 'zone cut'."

Delegation: 🎀 The process by which a separate zone is created in the name space beneath the apex of a given domain. Delegation happens when an NS RRset is added in the parent zone for the child origin. Delegation inherently happens at a zone cut. The term is also commonly a noun: the new zone that is created by the act of delegating. it's giving handing off the keys to a new zone 🔑

Glue records: 🧷 "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones]. These RRs are only necessary if the name server's name is 'below' the cut, and are only used as part of a referral response." Without glue "we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn." (Definition from [RFC1034], Section 4.2.1)

A later definition is that glue "includes any record in a zone file that is not properly part of that zone, including nameserver records of delegated sub-zones (NS records), address records that accompany those NS records (A, AAAA, etc), and any other stray data that might appear" ([RFC2181], Section 5.4.1). Although glue is sometimes used today with this wider definition in mind, the context surrounding the [RFC2181] definition suggests it is intended to apply to the use of glue within the document itself and not necessarily beyond. so glue is basically the helpful little address hint that keeps everyone from going in circles 🔄

In-bailiwick: 🏰

  • (a) An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the zone origin. In-bailiwick name servers require glue records in their parent zone (using the first of the definitions of "glue records" in the definition above).
  • (b) Data for which the server is either authoritative, or else authoritative for an ancestor of the owner name. This sense of the term normally is used when discussing the relevancy of glue records in a response. For example, the server for the parent zone example.com might reply with glue records for ns.child.example.com. Because the child.example.com zone is a descendant of the example.com zone, the glue records are in-bailiwick. 🙈

Out-of-bailiwick: 🚪 The antonym of in-bailiwick. bye bye, not your kingdom 👋

Authoritative data: 📜 "All of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone." (Quoted from [RFC1034], Section 4.2.1) It is noted that this definition might inadvertently also include any NS records that appear in the zone, even those that might not truly be authoritative because there are identical NS RRs below the zone cut. This reveals the ambiguity in the notion of authoritative data, because the parent-side NS records authoritatively indicate the delegation, even though they are not themselves authoritative data. this one is a little messy, not gonna lie 😭

Root zone: 🌳 The zone whose apex is the zero-length label. Also sometimes called "the DNS root". the OG zone, the main character 👑

Empty non-terminals: 👻 "Domain names that own no resource records but have subdomains that do." (Quoted from [RFC4592], Section 2.2.2.) A typical example is in SRV records: in the name _sip._tcp.example.com, it is likely that _tcp.example.com has no RRsets, but that _sip._tcp.example.com has (at least) an SRV RRset. ghost names with descendants, very spooky 🎃

Delegation-centric zone: 🍰 A zone that consists mostly of delegations to child zones. This term is used in contrast to a zone that might have some delegations to child zones, but also has many data resource records for the zone itself and/or for child zones. The term is used in [RFC4956] and [RFC5155], but is not defined there.

Wildcard: ⭐ [RFC1034] defined "wildcard", but in a way that turned out to be confusing to implementers. Special treatment is given to RRs with owner names starting with the label *. "Such RRs are called 'wildcards'. Wildcard RRs can be thought of as instructions for synthesizing RRs." (Quoted from [RFC1034], Section 4.3.3) For an extended discussion of wildcards, including clearer definitions, see [RFC4592]. the star label gets extra attention, and [RFC4592] has the full tea ☕

Occluded name: 🌑 "The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, still part of the zone, but not available to the lookup process. The addition of a DNAME resource record has the same impact. The subordinate names are said to be 'occluded'." (Quoted from [RFC5936], Section 3.5) so the names are still technically there, just stuck in limbo 😩

Fast flux DNS: ⚡ This "occurs when a domain is found in DNS using A records to multiple IP addresses, each of which has a very short Time-to-Live (TTL) value associated with it. This means that the domain resolves to varying IP addresses over a short period of time." (Quoted from [RFC6561], Section 1.1.5, with typo corrected) It is often used to deliver malware. Because the addresses change so rapidly, it is difficult to ascertain all the hosts. It should be noted that the technique also works with AAAA records, but such use is not frequently observed on the Internet as of this writing. this one is a red flag, babe 🚩💀

7. Registration Model 💅

this section is all about the people and orgs behind the names, the whole business side of DNS 💼✨

Registry: 🏛️ The administrative operation of a zone that allows registration of names within that zone. People often use this term to refer only to those organizations that perform registration in large delegation-centric zones (such as TLDs); but formally, whoever decides what data goes into a zone is the registry for that zone. This definition of "registry" is from a DNS point of view; for some zones, the policies that determine what can go in the zone are decided by superior zones and not the registry operator. so the registry is whoever decides what goes in, even if they're not the big TLD name you think of 👀

Registrant: 🧑‍💻 An individual or organization on whose behalf a name in a zone is registered by the registry. In many zones, the registry and the registrant may be the same entity, but in TLDs they often are not. the registrant is the one the name is registered for 💖

Registrar: 🛎️ A service provider that acts as a go-between for registrants and registries. Not all registrations require a registrar, though it is common to have registrars involved in registrations in TLDs. the middle person who makes it all happen 🫶

EPP: 📮 The Extensible Provisioning Protocol (EPP), which is commonly used for communication of registration information between registries and registrars. EPP is defined in [RFC5730]. the messaging system for registry-to-registrar chats 💬

WHOIS: 🔍 A protocol specified in [RFC3912], often used for querying registry databases. WHOIS data is frequently used to associate registration data (such as zone management contacts) with domain names. The term "WHOIS data" is often used as a synonym for the registry database, even though that database may be served by different protocols, particularly RDAP. The WHOIS protocol is also used with IP address registry data. the OG lookup tool, still around and still gossiping 🕵️‍♀️

RDAP: 🌈 The Registration Data Access Protocol, defined in [RFC7480], [RFC7481], [RFC7482], [RFC7483], [RFC7484], and [RFC7485]. The RDAP protocol and data format are meant as a replacement for WHOIS. the glow-up to WHOIS, and it's got a whole bunch of RFCs backing it up ✨

DNS operator: 🖥️ An entity responsible for running DNS servers. For a zone's authoritative servers, the registrant may act as their own DNS operator, or their registrar may do it on their behalf, or they may use a third-party operator. For some zones, the registry function is performed by the DNS operator plus other entities who decide about the allowed contents of the zone. the one keeping the servers running, and sometimes they're doing registry stuff too 🎀

8. General DNSSEC ✨

Okay bestie, most DNSSEC terms are defined in [RFC4033], [RFC4034], [RFC4035], and [RFC5155] 📚. A few of them have caused real confusion in the DNS community, so we're highlighting those here 💅.

DNSSEC-aware and DNSSEC-unaware: These two terms show up in some RFCs, but they've never been formally defined 🙈. Section 2 of [RFC4033] does define a bunch of resolver and validator types, though, including "non-validating security-aware stub resolver", "non-validating stub resolver", "security-aware name server", "security-aware recursive name server", "security-aware resolver", "security-aware stub resolver", and "security-oblivious 'anything'". (Also, "validating resolver" is used in plenty of DNSSEC docs and is also not defined, so iykyk 👀.)

Signed zone: This one is literally quoted from [RFC4033], Section 2: "A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records." 🔐 People have pointed out elsewhere that the zone itself isn't really signed, but all the relevant RRsets in it are. Here's the tea, though: if a zone that should be signed has any RRsets that aren't signed (or opted out), those RRsets get treated as bogus, so the whole zone needs to be handled in some way 😭.

It's also worth knowing that, since the publication of [RFC6840], NSEC records are no longer required for signed zones. A signed zone might include NSEC3 records instead 🎀. [RFC7129] has extra background and context on the NSEC and NSEC3 mechanisms that DNSSEC uses for authenticated denial-of-existence responses, so go read it if you're curious ✨.

Unsigned zone: Section 2 of [RFC4033] says this is "a zone that is not signed" 🙃. Section 2 of [RFC4035] goes further and says it's "A zone that does not include these records [properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records] according to the rules in this section". There's also an important note at the end of Section 5.2 of [RFC4035] about one more situation where a zone counts as unsigned: "If the resolver does not support any of the algorithms listed in an authenticated DS RRset, then the resolver will not be able to verify the authentication path to the child zone. In this case, the resolver SHOULD treat the child zone as if it were unsigned." 🌸

NSEC: Here's the official vibe from [RFC4033], Section 3.2: "The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence with the same mechanisms used to authenticate other DNS replies." 💜 Put simply, an NSEC record gives you authenticated denial of existence 🫶.

Section 4 of RFC 4034 adds this: "The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains authoritative data or a delegation point NS RRset, and the set of RR types present at the NSEC RR's owner name." 🧚

NSEC3: NSEC3 is the cool younger sibling of NSEC 💅. It also provides authenticated denial of existence, but it mitigates against zone enumeration and supports Opt-Out. NSEC3 resource records are defined in [RFC5155] 🦋.

Here's a plot twist: [RFC6840] says that [RFC5155] "is now considered part of the DNS Security Document Family as described by Section 10 of [RFC4033]". That means some definitions from earlier RFCs that only talk about NSEC records should probably be read as talking about both NSEC and NSEC3 🤓.

Opt-out: The quote from [RFC5155], Section 3.1.2.1, is: "The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned delegations." 🍓 Opt-out is there to tackle the high cost of securing a delegation to an insecure zone. When you use Opt-Out, names that are an insecure delegation (and empty non-terminals that are only derived from insecure delegations) don't need an NSEC3 record or its corresponding RRSIG records. The catch is that Opt-Out NSEC3 records can't prove or deny the existence of those insecure delegations 😬. (Adapted from [RFC7129], Section 5.1.)

Zone enumeration: Per [RFC5155], Section 1.3, this is "The practice of discovering the full content of a zone via successive queries." 🕵️‍♀️ It's sometimes also called "zone walking". Don't mix it up with zone content guessing, though. That's when the guesser uses a big dictionary of possible labels and sends successive queries for them, or matches the contents of NSEC3 records against that dictionary. Different vibe, different move 🙅‍♀️.

Key signing key (KSK): Per [RFC6781], Section 3.1, these are DNSSEC keys that "only sign the apex DNSKEY RRset in a zone." 🔑

Zone signing key (ZSK): Also from [RFC6781], Section 3.1, these are "DNSSEC keys that can be used to sign all the RRsets in a zone that require signatures, other than the apex DNSKEY RRset." 🗝️ The roles KSK and ZSK are not mutually exclusive, so a single key can be both a KSK and a ZSK at the same time 🌈. And a ZSK is sometimes used to sign the apex DNSKEY RRset too, so don't be shocked if you see it 😭.

Combined signing key (CSK): Per [RFC6781], Section 3.1: "In cases where the differentiation between the KSK and ZSK is not made, i.e., where keys have the role of both KSK and ZSK, we talk about a Single-Type Signing Scheme." 💖 This is sometimes called a "combined signing key" or CSK. Also, whether a particular key is a ZSK, a KSK, or a CSK is decided by operational practice, not by the protocol 🎀.

Secure Entry Point (SEP): This is a flag in the DNSKEY RDATA. Per [RFC6781], Section 3.2.3, it "can be used to distinguish between keys that are intended to be used as the secure entry point into the zone when building chains of trust, i.e., they are (to be) pointed to by parental DS RRs or configured as a trust anchor. Therefore, it is suggested that the SEP flag be set on keys that are used as KSKs and not on keys that are used as ZSKs, while in those cases where a distinction between a KSK and ZSK is not made (i.e., for a Single-Type Signing Scheme), it is suggested that the SEP flag be set on all keys." 🦋 Here's the important bit: the SEP flag is only a hint. Whether it's present or absent doesn't disqualify a given DNSKEY RR from being used as a KSK or ZSK during validation 🧚.

DNSSEC Policy (DP): This is a statement that, per [RFC6841], Section 2, "sets forth the security requirements and standards to be implemented for a DNSSEC-signed zone." 📜

DNSSEC Practice Statement (DPS): Per [RFC6841], Section 2, this is "A practices disclosure document that may support and be a supplemental document to the DNSSEC Policy (if such exists), and it states how the management of a given zone implements procedures and controls at a high level." 🗂️

9. DNSSEC States 🦋

Okay, so a validating resolver can figure out that a response is in one of four states: secure, insecure, bogus, or indeterminate 🔍. These states are defined in [RFC4033] and [RFC4035], but the two definitions differ a bit. This document makes no effort to reconcile them, and it takes no position on whether they need reconciling 🤷‍♀️.

Section 5 of [RFC4033] says that "A validating resolver can determine the following 4 states:" and then gives these:

  • Secure: The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response.
  • Insecure: The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure. A validating resolver may have a local policy to mark parts of the domain space as insecure.
  • Bogus: The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth. 😱
  • Indeterminate: There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode. 🌫️

Section 4.3 of [RFC4035] says that "A security-aware resolver must be able to distinguish between four cases:" and then lays them out like this:

  • Secure: An RRset for which the resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset. In this case, the RRset should be signed and is subject to signature validation, as described above. ✅
  • Insecure: An RRset for which the resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset. This can occur when the target RRset lies in an unsigned zone or in a descendent [sic] of an unsigned zone. In this case, the RRset may or may not be signed, but the resolver will not be able to verify the signature. 🫥
  • Bogus: An RRset for which the resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so, either due to signatures that for some reason fail to validate or due to missing data that the relevant DNSSEC RRs indicate should be present. This case may indicate an attack but may also indicate a configuration error or some form of data corruption. 🚨
  • Indeterminate: An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones. 🌀

10. Security Considerations 🔐

Lowkey the most important part of this whole section: "These definitions do not change any security considerations for the DNS." 🛡️ Don't let the cute vibes fool you, bestie. The DNS security considerations stay exactly as they are 🔥.

11. References 📖

11.1. Normative References ✨

Okay bestie, this is the reading list you NEED before you touch the main spec 📚💅 Every one of these is a citation the document leans on, so I'm keeping every number, title, date, and link exactly as the original has it.

11.2. Informative References 🌸

These ones are the "good to know" extras 🧚 Not required to follow the spec, but they give you the backstory, the history, and the rabbit holes if you want to go deeper 🫶

Acknowledgements 💖

Huge shoutout to every author of the DNS-related RFCs that came before this one 🙌 Thank you to Tony Finch, Stephane Bortzmeyer, Niall O'Reilly, Colm MacCarthaigh, Ray Bellis, John Kristoff, Robert Edmonds, Paul Wouters, Shumon Huque, Paul Ebersman, David Lawrence, Matthijs Mekking, Casey Deccio, Bob Harold, Ed Lewis, John Klensin, David Black, and the many others in the DNSOP Working Group who helped shape this document 🎀✨

Authors' Addresses 🦋

Paul Hoffman ICANN

Email: paul.hoffman@icann.org

Andrew Sullivan Dyn 150 Dow Street, Tower 2 Manchester, NH 03101 United States

Email: asullivan@dyn.com

Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan

Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp

📦 where this page comes from