In my previous blog post, I discussed the three major DNS requests—user, recursive, and authoritative—in which everything was largely behind the scenes and broadly consistent across the industry. It’s really when things start being presented to users themselves that terminology starts to get really squirrelly. Every DNS provider out there—as well as other services that use DNS names like CDNs and hosting services—seems to find its own way to name things, making discussion in unambiguous terms difficult.
Okay, for the next set of terms, we should build a zone with just a few of the normal records we use on a day-to-day basis. Records are formally called Resource Records (RR), which are those individual entries in the zone.
Seems normal right? If you have even a beginner relationship with DNS you may notice that we have IPs for things like webservers for the blog and APIs, mailservers; Mail Exchanger (MX) record for inbound mail; and a Service Record (SRV) for Voice Over IP (VoIP).
The terms for various portions of the individual record are not too controversial. Each string between the dividing dots (www, example, com) are known as labels. The labels together form a DNS name that specifies the exact location (www.example.com.) in the DNS tree a particular record can be found. This is often called the “name” of the record or a “host” in various DNS portals.
The next value is the Time to Live (TTL), which is the maximum time the record should be held in cache before a new query occurs. The record type lets us know the difference between a record for IP addresses and one for text, which is useful for finding which record you want within a particular label.
Not represented in a standard BIND zonefile is the record class, which is nearly always IN for internet. There is also an option for CH for Chaos network, but is only really used by us DNS personnel to query DNS server information. Lastly, we have the meat of the record known variously as RDATA for Resource Data, Value, or sometimes, target. A group of all the records of a particular type exist as an RRset.
Some of the specific terms used to describe a scope for any particular location within the DNS tree are contentiously debated, both across organizations and within them. If the description below doesn’t match what you might be used to. we will try to provide some context for the discrepancy.
The first is the location at the very top of that zone – the apex, represented by the @ symbol in our zonefile, with the SOA record designating the Start of Authority (SOA) for the new zone with information on how to handle that zone in certain scenarios. The apex of a zone is the location without an additional label to the left of it. If the zone name was example.com, then the apex of that zone is also example.com, which may hold important records like TXT or MX for email functionality.
While this is sometimes called “the root of the zone,” this should be discouraged if at all possible as the root is a specific location at the root of all DNS names. If you think about it, it’s as if you referred to the home directory on your computer as “root.” People wouldn’t know if you meant that location or actual root. That term is taken, and we have one for this concept, the apex.
From the apex, all labels to the left may be expressed as a subdomain of the label to the right of it. So www.example.com. is a subdomain of example.com. This is very widely used, even in less technology-focused circles like marketing; however, the domain itself is sometimes left off, and we’re left with only a label of www to represent the entire subdomain, which is incorrect.
An even more contentious debate centers around the name for a specific scope of a DNS name. The very literal term for the specific scope of a DNS name is that of a domain name as specified in RFC 1034, which is ok. But, because of the nested nature of the DNS, this is ambiguous. It’s not clear whether it refers to either the specific scope or the zone as a whole—however erroneous that may be. Do we mean example.com (the location with MX records) or the whole zone, which starts at example.com? It becomes difficult to differentiate one from another. So while domain name is the correct term used in standards, it is often not used in most business applications.
The next attempt uses Fully Qualified Domain Name (FQDN) to refer to the entire string of labels with all parts. This is reasonably good, but there is an issue with the full qualification. A true FQDN must include all labels right down to the trailing root (www.example.com.). But on a day-to-day basis, most of us will present a domain name without the trailing dot (www.example.com). So does a FQDN include situations when the trailing dot is excluded? We find ourselves in a situation where many outside the DNS sphere haven’t heard the term, but DNS experts are stuck wondering if it really is or isn’t qualified.
The other major term is hostname or host name, both mean the same thing. As RFC 7719 points out, the DNS was born out of the use of host tables, so it is likely this term has existed since nearly the beginning and is in common use. There is a flaw, however. Technically speaking, not all FQDNs can be hostnames. This specifically pertains to the use of special characters such as the underscores for _udp and _sip for our SRV record. Technically, this invalidates them from being a host, and therefore a hostname.
Alternatively, the very document, RFC 1123, that excludes those underscores itself was increasing the eligibility of hosts by label by allowing numbers in the beginning to valid syntax. The question remains whether such liberalization could be extended. For any of these terms, it’s good to remember that the internet is built on “rough consensus and running code.”
In review, zones are administrative units of the DNS. They are created by a delegation, declared by an SOA record at the apex, and contain various other records to perform useful work. Those records provide the answers to the questions from DNS queries. They have have a type and are associated to a specific DNS name. Our next article will focus on the delegation of these zones, using records, allowing navigation throughout the DNS.