> I really should use the official .internal TLD (Top Level Domain) for my homelab network, but I decided against it. This introduces the risk of name resolution problems, should someone offer a public .jhw TLD in future. It’s a risk I am willing to accept in exchange for using a 3 letter TLD at home. Don’t be like me! Use .internal instead. With that out of the way, let’s continue.
Why not .lan? The key word is official?
papascrubs · 19m ago
I run Technitium DNS server at home in a container. It supports DoH, DoT, multiple upstream resolvers (and multiple upstream queries, adblock support and a sleep of other goodies (API). If you're self hosting an internal resolver I highly recommend checking it out. I prefer it to pihole.
I set up authoritative nameservers at home using unbound, which appears to be considerably easier than configuring BIND, but I still can't say that I fully understand it. DNS (and networking in general) is a bit of a dark art.
gerdesj · 41m ago
You can't go too far wrong with unbound and it is seriously fast and light.
Real men cry into their text editors with BIND and PowerDNS but you do get the whole toy box with these beasties. I've whizzed up many BIND daemons. I once ran a pair of PDNS servers with a MySQL replicated back end.
I currently have an internet exposed and rather locked down PDNS for ACME DNS-01 (Lets Encrypt). The CA consortium are insisting on SSL certs going down to 40 odd day lifetimes within about three years. I look after quite a few SSL certs for my customers. Anyway.
For home labbers, you might consider a Pi Hole (doesn't have to run on a Pi - a VM will do) or, a bit more hard core: https://technitium.com/dns/ (web GUI - yay!) pfSense has Unbound built in and I think OPNSense does too - both are fine choices of router. OpenWRT probably has unbound in it.
When I say, you can't go too far wrong with unbound, I mean it. If it works then it is almost certainly configured correctly.
sgc · 26m ago
I am just using adguard home as my dns server (installed as a plugin in opnsense). Am I naively doing something wrong, or is that a relatively decent choice as well?
icedchai · 1h ago
I've been running BIND at home since the mid 90's when I had ISDN. The O'Reilly "DNS and BIND" book was my go-to guide when I got started.
gerdesj · 33m ago
It Still Does Nothing.
The sheer luxury of two B channels at 64kBps each and if you were cunning, the D channel at 16k (I wasn't cunning and didn't bother)! Yay, double phone charges if you raised the second channel. That was a BRI. A PRI was lots of channels (30) and an even more eye watering bill.
A customer dumped their BRI that was acting as a backup to SIP n that about six months ago. That's the last one I know of.
icedchai · 19m ago
A trick some ISPs used in the 90's was a "data over voice" call, which ran at 56K but was charged voice rates instead of data rates. That meant the call was generally free. The improved latency of ISDN made a huge difference compared to a 56K modem.
ai-christianson · 1h ago
> DNS (and networking in general) is a bit of a dark art.
Dynamic routing is fun :)
daneel_w · 1h ago
Try NSD. Unlike unbound, NSD is the actual authoritative name server in the project.
seiferteric · 32m ago
I’m setting up NSD for authoratative and Unbound for recursive layer at my company and they are a breeze to work with.
kQq9oHeAz6wLLS · 37m ago
Same, with ad blocking to boot.
zamadatix · 12m ago
Is there really a setup burden a reason to explicitly switch dnssec from the default implied "auto" to "no"?
Arch-TK · 2h ago
At home I have an openbsd box as my network gateway running unbound and nsd. Unbound handles the caching and recursion, nsd handles the local name resolution.
I have a small utility (made up of two shell scripts and a python script) which watches /var/db/dhcpd.leases for changes and parses it to produce the zonefiles for nsd.
Y’know the script approach sounds like a good idea.
I also have an OpenBSD box similar to what you describe, but I run ISC dhcpd and BIND because it’s the only setup that does old-school dynamic DNS where the dhcp server sends zone updates to BIND when a lease happens.
But I hate BIND, and not to mention this setup doesn’t work with DHCPv6 (no idea why, it should in principal…) maybe I should just do the “script to read the leases and generate the zone file” approach instead.
JdeBP · 33m ago
The world has been waiting for a DHCP and content DNS server that simply share a common database back-end, meaning no notifications/updates/scripts, for decades. See https://news.ycombinator.com/item?id=44395279 for more.
Arch-TK · 33m ago
Depends on bash, inotify-tools, ldns-utils, python
I personally find Bind to be such an awful DNS server to configure. It's a bit like setting up Arch or Gentoo; tons of configuration so you can get down to the details and learn about every single part of the system, but ultimately there are only a few fields that you generally need to touch.
My DNS server of choice remains PowerDNS. I also find the API easier to use with certbot and the available web UIs.
zamadatix · 17m ago
90% of the times Bind is deployed then named.conf probably could have been:
And it would have done the same job the person was looking for. This binds to all interfaces, avoids explicitly respecify the default paths as a lot of the config lines on the site do, logs what most people care to log to syslog, and forwards requests from any private subnet or the local machine. Alternatively, the distro probably comes with a default file with any distro specific customization which just needs these 3 lines added.
For the next 8% where people operate "real" dns servers I agree the zone definition syntax is a bit verbose (especially if you're doing many domains or reverse lookup zones) but not necessarily that complicated. The last 2% probably care about all of the syntax that starts to look like mumbo-jumbo which bind documentation focuses on. Oh, I will complain about bind expecting you to manually increment serial numbers in your zonefiles though... but most deployments like this (or even ones acting as the nameserver for some domains) don't actually need that anyways.
No complaints about choosing PowerDNS though. Hard to go wrong with it for this either.
JdeBP · 44m ago
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.
pixl97 · 12m ago
I remember moving to djbdns forever ago in my ISP days because bind was such a security nightmare and configuration footgun.
icedchai · 36m ago
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.
jwildeboer · 10m ago
Author here. I used the homelab.jhw mainly as part of my tests and experiments with my own certificate authority and to avoid going into split horizon DNS setup.
louwrentius · 1h ago
If you decide not to use a forwarder, the DNS server will be truly independent.
The DNS server will contact the Root servers for the TLD namesevers of a domain, the TLD nameservers and then the actual authoritative nameserver for the particular domain.
No forwarder needed.
This means you bypass any DNS based filtering any DNS ‘forwarder’ may have in place.
zamadatix · 33m ago
I've always felt it makes sense to either use a forwarder you trust or just operate the root zone yourself. Going to the root zone dynamically is certainly the most technically correct, but if your goals involve either "independence" or "retaining some measure of the performance of using forwarders while still resolving things directly yourself" then you can just pull the root zone daily and operate your own root server https://www.iana.org/domains/root/files. Of course, IANA would rather you just use DNS as technically correct as possible because, well, that's what they exist for, but they don't attempt to roadblock operating your own copy of the root.
It's hard to go much deeper than that in practice as the zonefiles for TLDs are massively larger, massively more dynamic (i.e. syncing once a day isn't usually enough), and much harder to get ahold of (if it all, sometimes).
Regardless of how you go about not using a forwarder, if that's the path you choose then I also heavily recommend considering setting up some additional things like cached entry prefetching so recently used expiring entries don't get "hitches" in latency.
JdeBP · 7m ago
There's an unofficial list of the ones that one can officially replicate.
There are actually several additional subdomains of arpa. that one can also replicate, not on that list, which are largely invariant.
And really it's not about technical correctness. It has been known how to set up private roots since the 20th century. Some of us have had them for almost that long. Even the IETF has glacially slowly now come around to the view that idea is a good one, with there now being an RFC on the subject.
The underlying problem for most of that time has been that they're difficult to do with BIND, at least a lot more difficult to do than with other content DNS server softwares, if one clings, as exhibited even here in the headlined article, to a single server vainly wearing all of the hats at once.
All of the people commenting here that they use unbound and nsd, or dnscache and tinydns, or PowerDNS and the PowerDNS Recursor, have already overcome the main BIND Think obstacle that makes things difficult.
craftkiller · 1h ago
I used to do that, but that has the downside of sending all your DNS requests unencrypted over the network. By using a forwarder you have the option to use DoT or DoH.
Why not .lan? The key word is official?
https://technitium.com/dns/
Can you talk more as to why?
Real men cry into their text editors with BIND and PowerDNS but you do get the whole toy box with these beasties. I've whizzed up many BIND daemons. I once ran a pair of PDNS servers with a MySQL replicated back end.
I currently have an internet exposed and rather locked down PDNS for ACME DNS-01 (Lets Encrypt). The CA consortium are insisting on SSL certs going down to 40 odd day lifetimes within about three years. I look after quite a few SSL certs for my customers. Anyway.
For home labbers, you might consider a Pi Hole (doesn't have to run on a Pi - a VM will do) or, a bit more hard core: https://technitium.com/dns/ (web GUI - yay!) pfSense has Unbound built in and I think OPNSense does too - both are fine choices of router. OpenWRT probably has unbound in it.
When I say, you can't go too far wrong with unbound, I mean it. If it works then it is almost certainly configured correctly.
The sheer luxury of two B channels at 64kBps each and if you were cunning, the D channel at 16k (I wasn't cunning and didn't bother)! Yay, double phone charges if you raised the second channel. That was a BRI. A PRI was lots of channels (30) and an even more eye watering bill.
A customer dumped their BRI that was acting as a backup to SIP n that about six months ago. That's the last one I know of.
Dynamic routing is fun :)
I have a small utility (made up of two shell scripts and a python script) which watches /var/db/dhcpd.leases for changes and parses it to produce the zonefiles for nsd.
Edit: https://paste.rs/vgr7t.txt
I also have an OpenBSD box similar to what you describe, but I run ISC dhcpd and BIND because it’s the only setup that does old-school dynamic DNS where the dhcp server sends zone updates to BIND when a lease happens.
But I hate BIND, and not to mention this setup doesn’t work with DHCPv6 (no idea why, it should in principal…) maybe I should just do the “script to read the leases and generate the zone file” approach instead.
https://paste.rs/vgr7t.txt
Enjoy
My DNS server of choice remains PowerDNS. I also find the API easier to use with certbot and the available web UIs.
For the next 8% where people operate "real" dns servers I agree the zone definition syntax is a bit verbose (especially if you're doing many domains or reverse lookup zones) but not necessarily that complicated. The last 2% probably care about all of the syntax that starts to look like mumbo-jumbo which bind documentation focuses on. Oh, I will complain about bind expecting you to manually increment serial numbers in your zonefiles though... but most deployments like this (or even ones acting as the nameserver for some domains) don't actually need that anyways.
No complaints about choosing PowerDNS though. Hard to go wrong with it for this either.
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.
The DNS server will contact the Root servers for the TLD namesevers of a domain, the TLD nameservers and then the actual authoritative nameserver for the particular domain.
No forwarder needed.
This means you bypass any DNS based filtering any DNS ‘forwarder’ may have in place.
It's hard to go much deeper than that in practice as the zonefiles for TLDs are massively larger, massively more dynamic (i.e. syncing once a day isn't usually enough), and much harder to get ahold of (if it all, sometimes).
Regardless of how you go about not using a forwarder, if that's the path you choose then I also heavily recommend considering setting up some additional things like cached entry prefetching so recently used expiring entries don't get "hitches" in latency.
* https://news.ycombinator.com/item?id=44318136
There are actually several additional subdomains of arpa. that one can also replicate, not on that list, which are largely invariant.
And really it's not about technical correctness. It has been known how to set up private roots since the 20th century. Some of us have had them for almost that long. Even the IETF has glacially slowly now come around to the view that idea is a good one, with there now being an RFC on the subject.
The underlying problem for most of that time has been that they're difficult to do with BIND, at least a lot more difficult to do than with other content DNS server softwares, if one clings, as exhibited even here in the headlined article, to a single server vainly wearing all of the hats at once.
All of the people commenting here that they use unbound and nsd, or dnscache and tinydns, or PowerDNS and the PowerDNS Recursor, have already overcome the main BIND Think obstacle that makes things difficult.