> making a mistake ... in banking on CoreDNS Well, I'll start by quoting the article: "Sanely hosting services 101 ... The first step is to not be us ... we created a lot of complexity that was generally [un]necesssary." You are 100% right in saying that BIND is more than likely a better solution than CoreDNS. And although some of it is "well, I found this that should work," it sometimes boils deeper, namely in the case of CoreDNS. It's something included in every pod of K3s and makes sense to get familiar with; which loops back to the start of wanting to learn how things work.
tl;dr : I appreciate the insights! Things are done for: a reason, for fun/experiment, or no reason. The Internet has some expected uptimes (not to say we don't for our intranet), but considering the small circle of trust, we aren't as constrained to the angry fist-waving when it goes down, rather we're all trying to figure out what happened, how to fix it, and how to prevent it from being an issue again: a fun "practicum," per se.
I mentioned BIND being the reference implementation for a reason. Every single DNS feature will be supported in BIND. In X years when something new and cool comes and/or k8s/k3 becomes somewhat "legacy" and people move onto the "next" infrastructure, CoreDNS has a very real chance of becoming something like Designate. It works. It's fine. BIND will keep ticking. I haven't had to adjust my named.conf (other than adding hooks for things like the sig-external-dns addon) in over a decade.
Do whatever you want with most of it. DNS in particular should be boring, stable, and able to run on a potato.
BIND is THE reference DNS server. It is the RFC, and the k8s external-dns sig to dynamically create record for services is the right way to go here, with delegation of some subdomain to k8s if you really want to. BIND's ocnfiguration is a relatively tiny text file and some RNDC keys. You could practically run it on on an Arduino, and adding secondaries is mindblowingly simple.
BIND supports every single part of the DNS spec. BIND will work with k8s/k3s plus whatever infrastructure is added later, out of the box, with no changes, in plain text files. Drive failure? Just grab stuff from git. It is 100% the right solution.
K8s/k3s are fine, but the authors are dramatically overestimating how far "we admin some websites" is going to take them during major version changes changes which adjust the arguments to kubelet/kube-admin, tryint to get some legacy/future software working, etc. Either use Kubevirt or, if I were starting this in 2022, I'd use a system like Nomad as the base and delegate things which belong in k8s to k8s so your core infrastructure doesn't depend on the hip tech.
Core infrastructure should be boring, stable, and "just work". PSQL is great. BIND and isc-dhcpd on whatever embedded boards you feel like will run forever, the config will probably never have breaking compatibility changes, and integrate with everything. Layer other things on top of that.
Ceph/Rook are great. Until you run out of storage. Shared nothing for DNS/dhcpd (let them handle transferring themselves). If you need "real" shared storage, pick whichever one you think you can recover when it catastrophically fails, because it WILL catastrophically fail. Ceph will run out of free inodes or the ratio will get too high and nodes will fail to start until you add capacity or recover manually with ceph-osd/ceph-bluestore-tool/etc.
Like k8s, don't select tools which are built to be monitored/managed by a team of dedicated people for your more or less hobby project in your free time. Pick something boring and stable.
If you want to build it like the internet, run it like the internet.
The SSL concerns can easily be mitigated. So can whatever weird TLD issues this is talking about with appending "/". Host a private DNS namespace. This has been done for decades. Your DNS servers (BIND) will be authoritative. Users of your network will need to disable DNS-over-http. Or make BIND do it. As mentioned, use Name Constraints for the CA.