DNS-Persist-01: A New Model for DNS-Based Challenge Validation • Hacker News Board

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#61

Post by glzone1 » Wed, Feb 18, 2026, 10:27 PM UTC

mcpherrinm wrote: post #13

ragall wrote: post #5

Earlier quoted context omitted.

Those who choose to use DNS-PERSIST-01 should fully commit to automation and create one LetsEncrypt account per FQDN (or at least per loadbalancer), using a UUID as username.

There is no username in ACME besides the account URI, so the UUID you’re suggesting isn’t needed. The account uri themselves just have a number (db primary key). If you’re worried about correlating between domains, then yes just make multiple accounts. There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.

Interesting.

I didn't realize the email field wasn't persisted. I assumed it could be used in some type of account recovery scenario.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#62

Post by inahga » Wed, Feb 18, 2026, 10:31 PM UTC

bob1029 wrote: post #37

I've changed my mind about the short lived cert stuff after seeing what is enabled by IP address certificates with the HTTP-01 verification method. I don't even bother writing the cert to disk anymore. There is a background thread that checks to see if the current instance of the cert is null or older than 24h. The cert selector on aspnetcore just looks at this reference and blocks until its not null. Being able to d…

You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#63

Post by infogulch » Wed, Feb 18, 2026, 10:45 PM UTC

This is a nice increment in ACME usability.

Once again I would like to ask CA/B to permit name constrained, short lifespan, automatically issued intermediate CAs. Last year's request: https://news.ycombinator.com/item?id=43563676

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#64

Post by tptacek » Wed, Feb 18, 2026, 10:46 PM UTC

cyberax wrote: post #60

akerl_ wrote: post #51

Earlier quoted context omitted.

Ok, it's inconvenient and clumsy in ways that make it easy to shoot oneself in the foot. But that's not dangerous?

When you shoot yourself in the foot with DNSSEC, you typically end up with a non-working setup. The biggest problem is that DNS replies are often cached, so fixes for the mistakes can take a while to propagate. With Let's Encrypt you typically can fix stuff right away if something fails.

When you shoot yourself in the foot with DNSSEC, your entire domain falls of the Internet, as if it had never existed in the first place. It's basically the worst possible case failure and it's happened to multiple large shops; Slack being the most notorious recent example.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#65

Post by amluto » Wed, Feb 18, 2026, 11:16 PM UTC

9dev wrote: post #57

itintheory wrote: post #36

I'm really excited for this. We moved 120+ hand renewed certs to ACME, but still manually validate the domains annually. Many of them are on private/internal load balancers (no HTTP-01 challenge possible), and our DNS host doesn't support automation (no DNS-01 challenges either). While manually renewing the DCV for ~30 domains once a year isn't too bad, when the lifetime of that validity shrinks, ultimately to 9 days…

For the love of god, switch to a DNS provider with an API. Whatever legacy behemoth you’re working with doesn’t justify a gap this wide.

Name one that doesn’t have an AWS-style per-query cost.

(There might well be a nice one, but I haven’t found it yet.)

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#66

Post by dextercd » Wed, Feb 18, 2026, 11:17 PM UTC

muvlon wrote: post #53

cube00 wrote: post #49

Earlier quoted context omitted.

Pretty risky given the rate limits of Let's Encrypt are non negotiable with no choice but to wait them out.

They are quite literally negotiable: https://isrg.formstack.com/forms/rate_limit_adjustment_reque... There are also a bunch of rate limit exemptions that automatically apply whenever you "renew" a cert: https://letsencrypt.org/docs/rate-limits/#non-ari-renewals . That means whenever you request a cert and there already is an issued certificate for the same set of identities.

Your comment is 100% correct, but I just want to point out that this doesn't negate the risks of bob's approach here.

LE wouldn't see this as a legitimate reason to raise rate limits, and such a request takes weeks to handle anyway.

Indeed, some rate limits don't apply for renewals but some still do.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#67

Post by nfredericks » Wed, Feb 18, 2026, 11:33 PM UTC

amluto wrote: post #65

9dev wrote: post #57

Earlier quoted context omitted.

For the love of god, switch to a DNS provider with an API. Whatever legacy behemoth you’re working with doesn’t justify a gap this wide.

Name one that doesn’t have an AWS-style per-query cost. (There might well be a nice one, but I haven’t found it yet.)

Might be obvious, but Cloudflare

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#68

Post by cortesoft » Wed, Feb 18, 2026, 11:35 PM UTC

mschuster91 wrote: post #46

Ayesh wrote: post #20

Earlier quoted context omitted.

I think the previous post is talking about a search that will find the sibling domain names that have obtained certificates with the same account ID. That is a strong indication that those domains are in the same certificate renewal pipeline, most likely on the same physical/virtual server.

Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.

you dont even need a docker container to do that.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#69

Post by mschuster91 » Wed, Feb 18, 2026, 11:38 PM UTC

cortesoft wrote: post #68

mschuster91 wrote: post #46

Earlier quoted context omitted.

Run ACME inside a Docker container, one instance (and credentials) for each domain name. Doesn't consume much resources. The real problem is IP addresses anyway, CT logs "thankfully" feed information to every bad actor in real time, which makes data mining trivially easy.

you dont even need a docker container to do that.

Agreed, that's just a personal preference thing of me. Harder to mess up and easier to route.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#70

Post by amluto » Wed, Feb 18, 2026, 11:41 PM UTC

nfredericks wrote: post #67

amluto wrote: post #65

Earlier quoted context omitted.

Name one that doesn’t have an AWS-style per-query cost. (There might well be a nice one, but I haven’t found it yet.)

Might be obvious, but Cloudflare

No. Cloudflare will give a key scoped to an entire administrative domain in the Cloudflare sense like “a.com”. They will not give you a key scoped to a single entry within that domain. (That entry would be a domain in the RFC 9499 sense, but do you really expect anyone to agree on the terminology?)

In particular, there is no support for getting a key scoped to _acme-challenge.a.b.c or, even better, to a particular RR.

Maybe if you have an enterprise plan you can very awkwardly fudge it using lots of CNAMEs and subdomains.

Some DNS hosts that support old-school dynamic dns can do this. dns.he.net is an example, but they have a login system that very much stuck in the nineties.