One interesting aspect of this is how using BIND puts focus upon serial numbers.

Serial numbers were a bane 3 decades ago. When Daniel J. Bernstein invented djbdns, xe made the software (tinydns-data) auto-generate the serial numbers from the last modification timestamp of the source file, and made several observations on the subject of serial numbers that are well known, or at least easy to work out for onesself with a modicum of thought.

This article warns the reader thrice, in all-capitals, about remembering to manually increment serial numbers. That's still after all these years reasonable advice for BIND users and a still habit to form if one uses BIND. The numbering scheme used here will only allow 100 changes per day, of course.

But nothing in the article, nor the planned parts 2 and 3 described in the ensuing FediVerse discussion, actually needs zone serial numbers to be incremented at all, as there's no replication of any kind, let alone "zone transfer", here and parts 2 and 3 (if they end up as stated, they not having been published yet) will not encompass replication either. It's heavily stressed because it has been a common pitfall for BIND users for decades; but ironically the article series does not actually need it.

It's a shame, really, because the things that should be emphasized as much if not more here, are reduced in comparison. internal. still not being an IANA special-use domain name is one. (See RFC 8375 for home.arpa., which is a special-use domain name.) The way that this setup will leak 192.168.0.0/16 reverse lookups outwith 192.168.1.0/24 to the world at large, and 172.16.0.0/12 lookups outwith 172.16.0.0/16, is another. (named.rfc1912.zones does not cover any of the requisite domain apices, RFC 1912 not being RFC 1918, and is in any case a RedHatism that one cannot rely upon on even, say, Debian, let alone on a non-Linux-based operating system.) The pitfalls of using a superdomain that one does not own, e.g. homelab.jhw. here, is a third that is glossed over. (Anyone who has tried to set up an organization's domain naming will know of the pitfalls that this entails; this is as much of a bad habit to avoid gaining in the first place as updating BIND's serial numbers is a habit to learn.)

Furthermore, making "everything at home just work, even with no internet connection" involves something further, missing from this and from the described forthcoming parts 2 and 3: a private root content DNS server. There's a surprising amount of stuff that relies on at minimum getting negative answers from the . content DNS servers for top-level domains that do not exist, and various blackholed domains.

I'm not sure why he didn't use a subdomain of his wildeboer.net domain for his home lab? I put all that stuff under lab.example.com (where example.com is an actual domain that I own, of course.) One nice thing about this is you can then use letsencrypt with a DNS-01 challenge and get real TLS certs for it.

I remember moving to djbdns forever ago in my ISP days because bind was such a security nightmare and configuration footgun.