I've run DNS servers in the past - BIND and pdns. I've now gone all in ... because ... well it started with ACME.
As the OP states you can get a registrar to host a domain for you and then you create a subdomain anywhere you fancy and that includes at home. Do get the glue records right and do use dig to work out what is happening.
Now with a domain under your own control, you can use CNAME records in other zones to point at your zones and if you have dynamic DNS support on your zones (RFC 2136) then you can now support ACME ie Lets Encrypt and Zerossl and co.
Sadly certbot doesn't do (or it didn't) CNAME redirects for ACME. However, acme.sh and simple-acme do and both are absolutely rock solid. Both of those projects are used by a lot of people and well trod.
simple-acme is for Windows. It has loads of add on scripts to deal with scenarios. Those scripts seem to be deprecated but work rather well. Quite a lot of magic here that an old school Linux sysadmin is glad of.
PowerDNS auth server supports dynamic DNS and you can filter access by IP and TSIG-KEY, per zone and/or globally.
I think CNAME redirections being not supported is reasonable choice. Would make my life easier as well but it opens all kinds of bad possibilities that bad actors would definitely use.
> Sadly certbot doesn't do (or it didn't) CNAME redirects for ACME.
Are you certain? Not at a real machine at the moment so hard for me to dig into the details but CNAMEing the challenge response to another domain is absolutely supported via DNS-01 [0] and certbot is Let's Encrypt's recommended ACME client: [1]
Since Let’s Encrypt follows the DNS standards when
looking up TXT records for DNS-01 validation, you can
use CNAME records or NS records to delegate answering
the challenge to other DNS zones. This can be used to
delegate the _acme-challenge subdomain to a validation
specific server or zone.
... which is a very common pattern I've seen hundreds (thousands?) of times.
The issue you may have run into is that CNAME records are NOT allowed at the zone apex, for RFC 1033 states:
The CNAME record is used for nicknames. [...] There must not be any other
RRs associated with a nickname of the same class.
... of course making it impossible to enter NS, SOA, etc. records for the zone root when a CNAME exists there.
P.S. doing literally fucking anything on mobile is like pulling teeth encased in concrete. Since this is how the vast majority of the world interfaces with computing I am totally unsurprised that people are claiming 10x speedups with LLMs.
I prefer and use the knot DNS server for authoritative DNS (and either knot-resolver or Unbound for caching DNS servers) myself: it is quite feature-rich, including DNSSEC, RFC 2136 support, an easy master-slave setup. Apparently it does support database-based configuration and zone definitions, too, but I find file-based storage to be simpler.
stub resolver (client) -> OPTIONAL forwarding resolver (server) -> recursing / caching resolver (server) -> authoritative server. "Personal DNS server" doesn't disambiguate whether your objective is recursive or authoritative... or both (there is dogma about not using the same server for both auth and recursion, if you're not running your resource as a public benefit you can mostly ignore it). If it's recursive I don't know why you'd run it in the cloud and not on-prem.
You'll find that you can restrict clients based on IP address, and you can configure what interfaces / addresses the server listens on. The traditional auth / nonrepudiation mechanism is TSIG, a shared secret. Traditionally utilized for zone transfers, but it can be utilized for any DNS request.
The traditional mechanism for encryption has been tunnels (VPNs) but now we have DoH (web-based DNS requests) and DoT (literally putting nginx in front of the server as a TCP connection terminator if it's not built in). These technologies are intended to protect traffic between the client and the recursing resolver. Encryption between recursing resolvers and auths is a work in progress. DNSSEC will protect the integrity of DNS traffic between recursives and auths. I don't know how big your personal network is, for privacy / anonymity of the herd you might want to forward your local recursing resolver's traffic to a cloud-based server and co-mingle it with some additional traffic; check the servers' documentation to see if you can protect that forwarder -> recursive traffic with DoT or you're not gaining any additional privacy; it's extra credit and mostly voodoo if you don't know what you're doing. I don't bother, I let my on prem recursives reach out directly to the auths. Once the DNS traffic leaves my ISP it's all going in different directions, or at least it should be notwithstanding the pervasive centralization of what passes for the federated / distributed internet at present.
I've been tempted by this because I self host everything else, but "adding an entry to postgres instead of using namecheap gui" is overkill, just use a DNS with an API.
Last few days I've been migrating everything to luadns format, stored in github and then I have github actions triggering a script to convert it to octodns and apply it.
I could have just used either, but I like the luadns format but didn't want to be stuck using them as a provider
Get a mini-pc with 2x LAN ports + a mediatek Wifi 6/7 module. Install Proxmox. Make 3 VM's: OpenWrt (or router firmware of choice), unbound and adguard home. Plug your fibre into lan port, plug rest of network into other lan port. In proxmox, set pcie passthrough for one of the Lan ports and the wifi card. Setup openwrt to connect to your isp and points its dns to you adguard home server. Point your adguard home server to your unbound server as upstream. This is a good starting point if you want to get a feel for running your own router + dns. You don't need to use off the shelf garbage routers; x86/x64 routers are the best. On openwrt I configure a special traffic queue so that I don't have buffer overflows, so my connection is super stable and low latency. Combined with the adguard + unbound dns setup, my internet connection is amazingly fast compared to traditional routers.
Better yet, set up ssh to the proxmox server and ask claude code to set it up for you, works like a charm! claude can call ssh and dig and verify that your dns chains work, it can test your firewall and ports (basically running pen tests against yourself..), it can sort out almost any issue (I had intel wifi card and had firmware locks on broadcasting in 5GHZ spectrum in AP Mode - mediatek doesn't - claude helped try to override firmware in kernel but intel firmware won't budge). It can setup automatic nightly updates that are safe, it can help you setup recovery/backup plans (which runs before updates), it can automate certain proxmox tasks (periodic snapshotting of vm's) and best of all, it can document the entire infrastructure comprehensively each time I make changes to it.
Just remember, if you run your own DNS, and you do so for a mission critical platform, the platform is exposed to a udp DDoS that will be hard to detect let alone prevent.
Unless of course you will invest 5-6 figures worth of US dollars worth of equipment, which by then you can look back and ask yourself, was I better off with Google Cloud DNS, AWS Route 53 and the likes.
We did as well for about 20 years. It is a very solid program and does everything it promises. Unfortunately it lacks modern features, and development is sparse to say the least, so we ended up moving to Knot. I'd still recommend tinydns for really simple deployments, though.
I've found that teaching DNS is an excellent gateway to learning about how the internet itself works, especially to "green" tech folks who go blank-faced when you get into protocols, IPs, etc.
Break out a piece of mail, connect the dots, and you see their eyes light up with comprehension. "Oh, so that's how my computer gets to google.com; it's just like how my postman knows where to deliver my mail!" Then a critical component is demystified, and they want to learn more.
Running a DNS server is honestly such a good activity for folks in general.
I've been running BIND for quite a long time now, and I've been very happy with it, very few issues other than my own folly, since I'm not on a static IP in the past 15 years my IP has changed 4 times (1 time due to a router change, 3 times due to Comcast outages), I didn't catch the last IP swap for over a month.
Which brings me to a rather big gripe about other resolvers not respecting TTL, 70% of https://www.whatsmydns.net/ reported it could not query A names, while 30% were like "Yeah here you go" from their cache.
I fixed the glue and got everything back up, I need to write an automated script to check every day if my IP has changed and alert me to update my glue record at my registar.
I use a lot of mix and match scripts to maintain other aspects like challenges for DNS e.g. Letsencrypt, I'll use their hooks to update my DNS, resign it (DNSSEC), complete the challenge, then cleanup. My more personal domains I don't use DNSSEC so I just skip right ahead.
I quite enjoy handling my own DNS records, BIND has been really good to me and I love their `view "external"` and `view "internal"` scopes so I can give the world my authoritative records, and internally serve my intranet and other services like pihole (which sits behind BIND)
I have run technitium for 4 or so years now, in a recursive mode, handles all my homelab needs and it is faster as well. Now that it has clustering support I have three instances in my proxmox cluster.
You can also serve a root.zone on that DNS server and it does not have to a carbon copy of ICANN's root.zone. I have been doing this for over 15 years. I've tried many DNS server software projects over that time and I always come back to djbdns
Multiple comments in this thread refer to TLS certificates
Why is payment to and/or permission from a third party "necessary" to encrypt data in transit over the a computer network, whether it's a LAN or an internet. What does this phoney "requirement" achieve
For example, why is it "necessary" to purchase a domain name registration from an "ICANN-approved" registrar in order to use a TLS certificate
Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication". What purpose does _purchasing_ a registration serve. For example, similar to "free" Let's Encrypt certificates, domain names could also be "free"
Whatever "authentication" ICANN and its "approved" registries and registrars are doing, e.g., none, is it possible someone else could do it better using a different approach
This comment is not asking for answers to these questions; the question are rhetorical. Of course the questions may trigger defensive replies; everyone is entitled to an opinion and opinions may differ
Yes, you can have a different root zone which includes some or all of ICANN's root servers, or none of them. However if the root zone doesn't match ICANN's then DNSSEC will fail ("fruit of the poisoned tree"). But you could sign your alternate, custom root, and issue DNSSEC keys all the way down.
You don't need ICANN for TLS or encryption. You can create your own CA and sign your own certs. In fact, this is typically how it's done to authenticate for example clients of a web server using certs (you install the cert in the browser).
You can use your CA to sign a cert for your ICANN-registered domain and install it in the web server; there are no internet police who are gonna stop you. Web browsers will complain about this "self-signed cert", unless you install your CA's public key in your browser. (Security-wise, you probably shouldn't go around installing random people's CA certs in your browser. You need to trust them not to issue certs for e.g. google.com. On the other hand you need to trust China and Morocco not to do that already, so maybe you're willing to accept that risk.)
> Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication".
People make the mistake of conflating an FQDN or address with identity all the time. People point at resources in domains which don't exist (this includes DNS resources), and people register those abandoned domains and then click "forgot password" and take over whatever account was tied to that email address in that domain.
I don't know that ICANN requires any proof. There are CAs which have enhanced identity verification, this applies to the certs they issue for both servers and clients / people.
> What purpose does _purchasing_ a registration serve.
Makes you a member of ICANN's club. There are pseudo-TLDs which are registered in ICANN's tree where you can register a (sub)domain, without interacting with ICANN at all.
29 comments
[ 2.7 ms ] story [ 50.5 ms ] threadAs the OP states you can get a registrar to host a domain for you and then you create a subdomain anywhere you fancy and that includes at home. Do get the glue records right and do use dig to work out what is happening.
Now with a domain under your own control, you can use CNAME records in other zones to point at your zones and if you have dynamic DNS support on your zones (RFC 2136) then you can now support ACME ie Lets Encrypt and Zerossl and co.
Sadly certbot doesn't do (or it didn't) CNAME redirects for ACME. However, acme.sh and simple-acme do and both are absolutely rock solid. Both of those projects are used by a lot of people and well trod.
acme.sh is ideal for unix gear and if you follow this blokes method of installation: https://pieterbakker.com/acme-sh-installation-guide-2025/ usefully centralised.
simple-acme is for Windows. It has loads of add on scripts to deal with scenarios. Those scripts seem to be deprecated but work rather well. Quite a lot of magic here that an old school Linux sysadmin is glad of.
PowerDNS auth server supports dynamic DNS and you can filter access by IP and TSIG-KEY, per zone and/or globally.
Join the dots.
[EDIT: Speling, conjunction switch]
https://github.com/ndilieto/uacme
Tiny, simple, reliable. What more can you ask?
Are you certain? Not at a real machine at the moment so hard for me to dig into the details but CNAMEing the challenge response to another domain is absolutely supported via DNS-01 [0] and certbot is Let's Encrypt's recommended ACME client: [1]
... which is a very common pattern I've seen hundreds (thousands?) of times.The issue you may have run into is that CNAME records are NOT allowed at the zone apex, for RFC 1033 states:
... of course making it impossible to enter NS, SOA, etc. records for the zone root when a CNAME exists there.P.S. doing literally fucking anything on mobile is like pulling teeth encased in concrete. Since this is how the vast majority of the world interfaces with computing I am totally unsurprised that people are claiming 10x speedups with LLMs.
[0] https://letsencrypt.org/docs/challenge-types/
[1] https://letsencrypt.org/docs/client-options/
stub resolver (client) -> OPTIONAL forwarding resolver (server) -> recursing / caching resolver (server) -> authoritative server. "Personal DNS server" doesn't disambiguate whether your objective is recursive or authoritative... or both (there is dogma about not using the same server for both auth and recursion, if you're not running your resource as a public benefit you can mostly ignore it). If it's recursive I don't know why you'd run it in the cloud and not on-prem.
You'll find that you can restrict clients based on IP address, and you can configure what interfaces / addresses the server listens on. The traditional auth / nonrepudiation mechanism is TSIG, a shared secret. Traditionally utilized for zone transfers, but it can be utilized for any DNS request.
The traditional mechanism for encryption has been tunnels (VPNs) but now we have DoH (web-based DNS requests) and DoT (literally putting nginx in front of the server as a TCP connection terminator if it's not built in). These technologies are intended to protect traffic between the client and the recursing resolver. Encryption between recursing resolvers and auths is a work in progress. DNSSEC will protect the integrity of DNS traffic between recursives and auths. I don't know how big your personal network is, for privacy / anonymity of the herd you might want to forward your local recursing resolver's traffic to a cloud-based server and co-mingle it with some additional traffic; check the servers' documentation to see if you can protect that forwarder -> recursive traffic with DoT or you're not gaining any additional privacy; it's extra credit and mostly voodoo if you don't know what you're doing. I don't bother, I let my on prem recursives reach out directly to the auths. Once the DNS traffic leaves my ISP it's all going in different directions, or at least it should be notwithstanding the pervasive centralization of what passes for the federated / distributed internet at present.
Last few days I've been migrating everything to luadns format, stored in github and then I have github actions triggering a script to convert it to octodns and apply it.
I could have just used either, but I like the luadns format but didn't want to be stuck using them as a provider
Better yet, set up ssh to the proxmox server and ask claude code to set it up for you, works like a charm! claude can call ssh and dig and verify that your dns chains work, it can test your firewall and ports (basically running pen tests against yourself..), it can sort out almost any issue (I had intel wifi card and had firmware locks on broadcasting in 5GHZ spectrum in AP Mode - mediatek doesn't - claude helped try to override firmware in kernel but intel firmware won't budge). It can setup automatic nightly updates that are safe, it can help you setup recovery/backup plans (which runs before updates), it can automate certain proxmox tasks (periodic snapshotting of vm's) and best of all, it can document the entire infrastructure comprehensively each time I make changes to it.
Unless of course you will invest 5-6 figures worth of US dollars worth of equipment, which by then you can look back and ask yourself, was I better off with Google Cloud DNS, AWS Route 53 and the likes.
(disclaimer: I contribute a tiny bit to dnsdist.)
Break out a piece of mail, connect the dots, and you see their eyes light up with comprehension. "Oh, so that's how my computer gets to google.com; it's just like how my postman knows where to deliver my mail!" Then a critical component is demystified, and they want to learn more.
Running a DNS server is honestly such a good activity for folks in general.
Which brings me to a rather big gripe about other resolvers not respecting TTL, 70% of https://www.whatsmydns.net/ reported it could not query A names, while 30% were like "Yeah here you go" from their cache.
I fixed the glue and got everything back up, I need to write an automated script to check every day if my IP has changed and alert me to update my glue record at my registar.
I use a lot of mix and match scripts to maintain other aspects like challenges for DNS e.g. Letsencrypt, I'll use their hooks to update my DNS, resign it (DNSSEC), complete the challenge, then cleanup. My more personal domains I don't use DNSSEC so I just skip right ahead.
I quite enjoy handling my own DNS records, BIND has been really good to me and I love their `view "external"` and `view "internal"` scopes so I can give the world my authoritative records, and internally serve my intranet and other services like pihole (which sits behind BIND)
gawd just install webmin ffs
Multiple comments in this thread refer to TLS certificates
Why is payment to and/or permission from a third party "necessary" to encrypt data in transit over the a computer network, whether it's a LAN or an internet. What does this phoney "requirement" achieve
For example, why is it "necessary" to purchase a domain name registration from an "ICANN-approved" registrar in order to use a TLS certificate
Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication". What purpose does _purchasing_ a registration serve. For example, similar to "free" Let's Encrypt certificates, domain names could also be "free"
Whatever "authentication" ICANN and its "approved" registries and registrars are doing, e.g., none, is it possible someone else could do it better using a different approach
This comment is not asking for answers to these questions; the question are rhetorical. Of course the questions may trigger defensive replies; everyone is entitled to an opinion and opinions may differ
You don't need ICANN for TLS or encryption. You can create your own CA and sign your own certs. In fact, this is typically how it's done to authenticate for example clients of a web server using certs (you install the cert in the browser).
You can use your CA to sign a cert for your ICANN-registered domain and install it in the web server; there are no internet police who are gonna stop you. Web browsers will complain about this "self-signed cert", unless you install your CA's public key in your browser. (Security-wise, you probably shouldn't go around installing random people's CA certs in your browser. You need to trust them not to issue certs for e.g. google.com. On the other hand you need to trust China and Morocco not to do that already, so maybe you're willing to accept that risk.)
> Is obtaining a domain name registration from an "ICANN-approved" registrar proof of identity for purposes of "authentication".
People make the mistake of conflating an FQDN or address with identity all the time. People point at resources in domains which don't exist (this includes DNS resources), and people register those abandoned domains and then click "forgot password" and take over whatever account was tied to that email address in that domain.
I don't know that ICANN requires any proof. There are CAs which have enhanced identity verification, this applies to the certs they issue for both servers and clients / people.
> What purpose does _purchasing_ a registration serve.
Makes you a member of ICANN's club. There are pseudo-TLDs which are registered in ICANN's tree where you can register a (sub)domain, without interacting with ICANN at all.
Rhetorically speaking, of course.