HN Reader

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.

https://technitium.com/dns/

I liked djbdns. But the development seems stucked. What I liked is the separation of name resolver (dnscache) and authoritative name server (tinydns).

Lee Hutchinson of arstechnica.com did a great rundown of setting up bind with dhcpd as a self hosted CA a while back.

https://arstechnica.com/information-technology/2024/02/doing...

I never took the plunge - dnsmasq, adguardhome, and let's encrypt for me..

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.

Edit: https://paste.rs/vgr7t.txt

> 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?

Because ISC DHCP was discontinued, I switched to dnsmasq, which also caused me to switch my home DNS server from unbound to dnsmasq so that local dhcp hostname registration would continue to work.

I always thought of dnsmasq as a bit of a toy, but I have to admit I've been impressed. So far it's worked flawlessly, and I'm especially impressed that you can reconfigure it without restarting the process.

My only complaint is not specific to dnsmasq, and that's with ipv6. Devices assign themselves essentially random addresses, so it's impossible to correlate DNS lookups from those addresses with what actual device is making the request. The obvious solution to this, a fully managed DHCP6 setup, does not seem to be well supported by dnsmasq, but it wouldn't matter even if it was because so many devices don't support DHCP6, only slaac. So the whole thing is a bit of a mess.

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.

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.

I host my own name servers and have a custom dynamic DNS script with email notifications and everything. Honestly, wish I could replace the domain registrar as well and just have my own public TLD. For 50 million USD though (give or take) and the .sh TLD could be mine

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.

> NEVER FORGET TO INCREASE THE SERIAL WITH EVERY CHANGE TO A ZONE FILE. OR RISK DNS HELL.

> EVERY HOSTNAME RECORD ENDS WITH A . YOU WILL FORGET THIS. YOU WILL FIX THIS.

> WITH A DOT AT THE END. DO NOT FORGET THE DOT!

> WITH THE DOT AT THE END. AND DID YOU UPDATE THE SERIAL? :)

I just love these comments. You made my day! :D

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.

He fails to mention how many systems (Android, iOS, Firefox) feel entitled to ignore the LAN's choice of DNS server and use various DoH or similar solution, which means split DNS no longer works when your resolver is getting its results from CloudFlare et al, with NXDOMAIN or external IP addresses as a result.

"This way works well for most people but, your ISP can see and control what website you can visit even when the website employ HTTPS security. Not only that, some ISPs can redirect, block or inject content into websites you visit even when you use a different DNS provider like Google DNS or Cloudflare DNS. Having Technitium DNS Server configured to use DNS-over-TLS, DNS-over-HTTPS, or DNS-over-QUIC encrypted DNS protocols with forwarders, these privacy & security issues can be mitigated very effectively."

And if using Technitium as encouraged/promoted/facilitated,^1 now "DNS provider like Google DNS or Cloudflare DNS [or IBM Quad9 DNS]... _can_ see and control what website you can visit even when the website employ[s] HTTPS security" and "_can_ redirect, block or inject content into websites you visit"

If the ISP seeing "what website you can visit" is the issue, then Technitium is not going to help. A DNS lookup does not necessarily mean a "visit" but even assuming it does, then the ISP can already see the "visit" (the actual TCP connection not the DNS lookup) via the SNI extension in the TLS ClientHello

If the issue is ISP "control [over] what website you can visit", then Technitium _might_ help

But if the issue is _any_ third party "control [over] what website you can visit", then all that has been done with Technitium is to substitute a "DNS provider" other than the ISP as the third party

Technitium uses the word "can" to describe the issue: "your ISP can see and control..." and "some ISPs can redirect, block or inject..."

Maybe this is purely coincidental, who knows

The fact is some ISPs _have_ redirected, blocked or injected content by utilising their control over DNS

It has happened and, certainly with redirection at least, it is ongoing. Why use the word "can". ISPs do it

As far as we know neither Google nor Cloudflare has done it

It may or may not have happened. But either way, they _can_ do it

There is nothing that stops third parties from doing it in the future, whether it's an ISP or an advertising services and surveillance company or a TLS MiTM CDN

Excerpt from RFC 1035:

"Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular "pruned" subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete, but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism."

The "DNS provider" is not a source for authoritative data

Many self-proclaimed "technical" people use it this way; hopefully they understand exactly what they are doing

For example, according to RFC 1035 the operator of the nameserver for example.com controls the DNS data for example.com, not the ISP, not Google, not Cloudflare or any other third party "DNS provider"

The internet user can run his own authoritative nameserver and/or a cache^2 and decide what the DNS data for example.com should be served when his computers ask for it; he could thereby eliminate the need for third parties

He could obtain that DNS data from the nameserver(s) for example.com

He could also obtain it from an "upstream" third party cache, such as an ISP, Google, or Cloudflare; i.e., he could rely on a third party

But according to RFC 1035 only the nameserver for example.com is the authoritative source^3

1. "Self-host" is not the default

DnsServer-master/Apps/AdvancedForwardingApp/dnsApp.config

2. These do not have to be the same program, as is the case with Pi-Hole (dnsmasq) and Technitium

3. As it happens, many website operators use third parties for authoritative DNS service

Have you had issues with the .jhw TLD on Apple devices? I have my own DNS for my homelab with CoreDNS with house.hill as my domain. My house is on a hill. But .hill is not a TLD, and both my macbook and iphone stopped resolving it quite a while ago.

Cool setup, but seems quite complex and a lot to manage. I’m a UniFi fanboy and they support custom DNS records now. Just configure DHCP to send out your routers IP as DNS and done. Need device static IP assignment? That also is done at the UniFi router instead of having to configure client side static ips.

I tried BIND, Dnsmasq, unbound, adguard. At the end I picked CoreDNS outside kubernetes. It can do everything (including wildcards and ACL), requires few resources and easy to configure.

Doesn't the use of .internal and the likes preclude the use of ACME/certbot for your internal https services? Unless you want the pain of running your own internal CA but then some OSes complain about internal CAs these days.

Is there really a setup burden a reason to explicitly switch dnssec from the default implied "auto" to "no"?