#homelab #sysadmin #sysadmins #dns #linux #bsd

Okay experienced home lab enthusiasts and sysadmins. When implementing internal DNS for your network, is it better to:

Use a fake internal TLD
27.3%
Buy a real domain and only use it internally
23.6%
Use split horizon DNS with a real domain
29.1%
Use a sub-domain of your real one
20%
Poll ended at .
@housepanther Fake internal TLD can run in actual problems with various tools (systemd-resolved maybe? don't remember) and DNSSEC; split horizon is always a real PITA to maintain & will cause you to waste time debugging stuff just because the same name looks different from different sources. Both real domain & sub-domain of real one can work just fine; I'm using both types of setups extensively both in my homelab & at work.
@mosu I've implemented a sub-domain in mine. I was curious as to other people's thoughts. Thank you for sharing! 😁
@housepanther As long as as you don't chose split-horizon, which I have too many customers who do, I won't come after you with fire & vengeance 😂 (tongue in cheek; I'm just so fed up with customers not following our explicitly well-reasoned advice & causing so much headache & lost time)
@housepanther @mosu how do you do the domain/subdomain for internal use? Set records to private addresses?
@chipiguay @mosu I use my internal.goblackcat.com for private addresses.Everything else gets forwarded to Quad9 DNS over TLS.
@chipiguay @housepanther That's one way to do it. Usually I run an internal DNS server solely for the sub-domain. If I want to get fancy I'll even add NS records for the sub-domain in the upper-level zone so that the sub-domain will get delegated properly (note two things about that: 1. if you add NS records for the sub-domain you should also add A/AAAA records for the sub-domain's internal name servers as a request for NS to the upper-level zone will usually receive both the list of NS host names but then also their A/AAAA records from the upper-level zone's server, otherwise the client wouldn't know where to connect further; 2. even though that way to leak a tiny bit of internal information = the A/AAAA of your internal DNS servers, those will obviously only be reachable from the public internet if you want them to via port fowardings/firewall entries — others will likely say even this is unacceptable, which I can partially understand but don't subscribe to).
But then again I'm a DNS-nerd and have been running my own name servers for more than two decades now (bind, unbound, PowerDNS), including primary, hidden primaries, secondaries… It's just of the topics around networking I really like as its so fundamental to pretty much everything. There's the saying for a reason, "It's always DNS!"
@mosu @housepanther thank you for such thorough reply!
I'm not by far that knoledged on DNS.
How do you handle cert challenges?
My way so far (probably bad idea, but works) is:
- Set DNS records to a public ip (a vps)
- Renew cert
- copy the cert to my lan
- override DNS records for that internal domain on pihole so it points to my private ip
@chipiguay @mosu I know this is somewhat cringy, but I have an internal CA and an ansible job that pushes the certs out to all of the client and server machines.
@housepanther @mosu I'd love to keep evolving my whole setup, but I'm currently on maintance mode until my children are older.
@chipiguay @housepanther I usually don't do certs by external CAs such as Let's Encrypt for names only resolvable via internal DNS and use a reverse proxy instead of stuff I need externally (there I do use such certs, of course, usually with DNS authentication by acme.sh which supports TONS of DNS providers out there including most locally-run server types via nsupdate).
For purely internal servers I usually just run a separate, internal, self-signed CA infrastructure. At work we often use our internal DCs and their CA infrastructure, but there are tons of other projects out there that can be used instead, e.g. easy-rsa. Then I distribute that internal CA's certificate to the trust stores of the devices on which I want to use the internal names.
All of this keeps separate worlds & concerns separate and circumvents the specific DNS update problems you're talking about.
The fun thing about DNS is you can always get a completely separate domain name or two just for playing around with & learning. Usually only costs a handful of bucks a year if you're not picky about provider/TLD, and that'll give you ample opportunity to test all this out without f*cking up your real domain too badly.
@mosu @housepanther again thanks for all the details 🙏
It's good to have them at hand when the time comes.
@chipiguay @mosu Who says you've got to wait? Pick up a cheap Dell OptiPlex 7060 or better and go to town. ROFL!
@housepanther @mosu I do have the hardware, I have the goals but I don't have the time to spend on them :)
@chipiguay @housepanther You're quite welcome! The advantage of having a just-for-play domain is that it fits well with the whole "small children" thing, you know, time-wise? You can spend a handful of minutes here or there without the pressure of having to actually get it done (or get it fixed by some deadline should you eff it up). Just saying; all learning doesn't have to stall. Of course only if you actually want to.
@mosu @housepanther I do have a domain for tests, but that became the de-facto main one, so probably a good advice to get another for actual tests.
@chipiguay @mosu @housepanther If certificates are for a resource to be accessed from public Internet, it has to have anyway a name resolving publicly so you are back to normal case. If it is certificates only for internal needs, you can as well generate your own local CA, and even using ACME, generate your own certificates, no external dependencies. Remember there are multiple validation methods and for dns-01 and ACME the name `_acme-challenge` can be a CNAME or NS delegating elsewhere.
@housepanther This seems like it’s pretty much exactly what .internal is for.
@benjamineskola I always thought .internal looked ugly. Never liked the aesthetic.
@housepanther Subdomain of a real one. You can always make it split-horizon as well if you fancy.
@dwm I ended up doing that. I have internal.goblackcat.com strictly for my internal stuff. It seems to be the way to go. I also have an internal CA for internal websites.

@housepanther

.internal is reserved for this use; officially since July 2024.

It can be used for any purpose, but must not be advertised to the outside internets.

.local is available but reserved for mdns/zeroconf usage

.example should only be used in documentation.

.home.arpa is equivalent in use to .internal, but who wants to type that crap?

@housepanther

I use split-horizon myself, but I actually work with nameservers more than once a year...

@dashdsrdash I used to administer DNS as well but in a much more limited capacity. I did it back in the early 2000s when I was a Windows sysadmin. God that was an evil job.
@housepanther Sorry to hear that; panthers, domestic or wild, should not be subject to such abuse.
@dashdsrdash LOL! Agreed! One of the best days ever was when I got an entry level #linux job. I got so sick of Windows professionally, that I sat down to take the CompTIA Linux+ and LPI exams.
@housepanther I use 5-letter domains for my stuff to keep typing to a minimum. (I don't use search domains)
@housepanther I’m not all that experienced, but the correct answer is “it depends” just like software development. (Would experienced homelab enthusiasts agree? It depends :)
@blue_fenix HAHAHA! True!

@housepanther back when #OpenBSD was the only (secure by default) game in town I would have said pf.conf is gospel. With the right rules in the proper order it didn’t matter what topology was on either side of the firewall. You could bend every packet to your will for even the edge cases.

The answer is likely different now but block in log all/only allow what can be trusted is a powerful foundation.

@blue_fenix OpenBSD (and to a certain extent, Kali Linux) is/are still the golden standard. OpenBSD is my firewall/router.
@housepanther we had a dedicated box with inet/public/private three headed interface hardware so packets could not physically pass between protected and DMZ. This was me, approximately back then lol:
@housepanther I use a real domain just for my homelab services. Domains are quite cheep, so its easier for all aspects. Especially if you like to use certificates from Services like @letsencrypt
@housepanther None of the above. Use a real internal address aka .internal

@housepanther
My two go-tos:
IPv6: same fqdn for both internal and external access because the IP is the same!
IPv4: split horizon because I don't want to have update the hostname on my chat app (or other app connections) every time I leave the house, and I want speedy local access when I'm home.

Long story short IPv6 rules, even though it comes with its own caveats

@null_scum I have a small WAN consisting of WIreGuard tunnels between my home and family members. Eventually, I want to move everything to IPv6 ULA.

@housepanther I use both split horizon for real domain I subscribe to / rent.

I also have another real domain that I subscribe to / rent that I only use internally.

I try to avoid made up top level domains as it’s almost certainly a matter of time before it becomes a problem.

@housepanther NEver use a fake TLD. Shouldn't even be an idea. If you really need an internal TLD, ICANN created `.internal` for that need. Guaranteed to never be delegated from IANA root.
@housepanther .lan and .local for me