My pragmatic sysadmin view on subdomains and DNS zones

February 27, 2021

Over on Twitter, Julia Evans had an interesting poll and comment:

computer language poll: is a subdomain of (not a trick question, no wrong answers, please don't argue about it in the replies, I'm just curious what different people think the word "subdomain" means :) )

the ambiguity here is that doesn't have its own NS/SOA record. An example of a subdomain that does have those things is -- it has a different authoritative DNS server than does.

This question is interesting to me because I had a completely different view of it than Julia Evans did. For me, NS and SOA DNS records are secondary things when thinking about subdomains, down at the level of the mechanical plumbing that you sometimes need. This may surprise people, so let me provide a quite vivid local example of why I say that.

Our network layout has a bunch of internal subnets using RFC 1918 private IP address space, probably like a lot of other places. We call these 'sandbox' networks, and generally each research group has one, plus there are various other ones for our internal use. All of these sandboxes have host names under an internal pseudo-TLD, .sandbox (yes, I know, this is not safe given the explosion in new TLDs). Each different sandbox has a subdomain in .sandbox and then its machines go in that subdomain, so we have machines with names like sadat.core.sandbox and lw-staff.printers.sandbox.

However, none of these subdomains are DNS zones, with their own SOA and NS records. Instead we bundle all of the sandboxes together into one super sized sandbox. zone that has everything. One of the reasons for this is that we do all of the DNS for all of these sandbox subdomains, so all of those hypothetical NS and SOA records would just point to ourselves (and possibly add pointless extra DNS queries to uncached lookups).

I think most system administrators would consider these sandbox subdomains to be real subdomains. They are different namespaces (including for DNS search domains), they're operated by different groups with different naming policies, we update them separately (each sandbox has its own DNS file), and so on. But at the mechanical level of DNS zones, they're not separate zones.

But this still leaves a question about is it a subdomain or a host? For people outside of Google, this is where things get subjective. A (DNS) name like '' definitely feels like a host, partly because in practice it's unlikely that people would ever have a <something> But could quite plausibly someday have names under it as <what>, even if it doesn't today. So to me it feels more like a subdomain even if it's only being used as a host today.

(People inside Google probably have a much clearer view of what is, conceptually. Although even those views can drift over time. And something can be both a host and a subdomain at once.)

Because what I consider a subdomain depends on how I think about it, we have some even odder cases where we have (DNS) name components that I don't think of as subdomains, just as part of the names of a group of hosts. One example is our IPMIs for machines, which we typically call names like '<host>.ipmi.core.sandbox' (for the IPMI of <host>). In the DNS files, this is listed as '<host>.ipmi' in the core.sandbox file, and I don't think of 'ipmi.core.sandbox' as a subdomain. The DNS name could as well be '<host>-ipmi' or 'ipmi-<host>', but I happen to think that '<host>.ipmi' looks nicer.

(What is now our IPMI network is an interesting case of historical evolution, but that's a story for another entry.)

Comments on this page:

By Danny Thomas at 2021-02-28 15:08:28:

The namespace underneath a DNS zone can be considered a tree of names. Terminal names (leftmost label) could represent hosts, interfaces, services, etc. DNS zones are partitions of that tree ("zone cuts") which allow administration of sub-trees to be delegated by someone else. Even if the whole name-space is managed by one group, sub-zones can be useful when a change only needs a smaller part of the name-space to be loaded by the nameserver.

I remember when our group was secondarying the zones for another university. Even though they didn't have an very large number of DNS records, maybe 5K, at one point we started having a large number of zone transfers because nearly all their records were in their top-level zone and they used that zone-name for AD and of course nearly all their hosts were windows machines making dynamic DNS updates. We negotiated a change so that we would initiate a secondarying zone-transfer every 15 minutes.

A terminal label could be an empty zone. It's not an issue for name-servers whose configuration is a database, but zone files with a delegated sub-domain can only have the NS delegation records (including DNSSEC ones as well as NS ones) and no other record within that sub-zone.

zone1 IN NS some-name-server-fqdn.

     IN SOA (...)

; sub-domain not delegated to another zone mail.sub-zone1 ; no limit to depth host1.backup.mail.sub-zone1

; delegation of sub-domain to another zone sub-zone2 IN NS some-name-server-fqdn1. sub-zone2 IN NS some-name-server-fqdn2.

; but having "out of zone" records is forbidden. ; At one point long ago bind accepted these alongside delegation ; The record needs to be moved to the sub-zone1 zone file some-host.sub-zone1

Written on 27 February 2021.
« The HTTP Referer header is fading away (at least as a useful thing)
My Firefox addons as of Firefox 86 (and the current development version) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 27 00:59:34 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.