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]

    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.

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.

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/

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.

  1.  Run OpenWRT
  2.  Use it for the DNS of one's own choosing

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.

You could also add whitelisting on your dns server to known IPs, or at least ranges to limit exposure, add rate limiting / detection of patterns you wouldn’t exhibit etc.

You could rotate your dns endpoint address every x minutes on some known algorithm implemented client and server side.

But in the end it’s mostly security through obscurity, unless you go via your own tailnet or similar

If you want DNS that is only for you, edit your hosts file.

The main thing I can think of is DNS amplification attacks, but that's more your DNS server being used as part of a DDoS attack rather than being targeted for one. Also (afaik) resolvers are more common targets for DNS amplification than authoritative.

[0]: https://www.knot-dns.cz/docs/3.5/singlehtml/index.html#autom...

And when using such turn-key DNSSEC support, I think there's very little risk to enabling it. While other commenters pointing out its marginal utility are correct, turn-key DNSSEC support that Just Works™ de-risks it enough for me that the relatively marginal utility just isn't a concern.

Plus, once you've got DNSSEC enabled, you can at the very least start to enjoy stuff like SSHFP records. DANE may not have any real-world traction, but who knows what the future may bring.

Simplistically you need a DS record at your registrar, then sign your zones before publishing. You can cheat and make the KSK not expire, which saves some aggravation. I've rolled my own by hand for 10 yrs with no dnssec related downtime

[1] DNSSEC Operational Practices https://datatracker.ietf.org/doc/html/rfc6781

That is to say, if you misconfigure it, or try to turn it off, you will have an invalid domain until the TTL runs out, and it's really just not worth the headache unless you have a real use case.