Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

letsencrypt.org

Post reply on HN
Print view View original

11–20 of 164 posts

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

#11

Post by cyberax »

tptacek wrote: post #9
cyberax wrote: post #6

Ah, the next step towards True DANE! We then can just staple the Persist DNS key to the certificate itself. And then we just need to cut out the middleman and add a new IETF standard for browsers to directly validate the certificates, as long as they confirm the DNS response using DNSSEC.

This decreases the salience of DANE/DNSSEC by taking DNS queries off the per-issuance critical path. Attackers targeting multitenant platforms get only a small number of bites at the apple in this model.

Sure. It's yet another advantage of doing True DANE. But it still requires DNS to be reliable for the certificate issuance to work, there's no way around it.

So why not cut out the middleman?

(And the answer right now is "legacy compatibility")

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

#12

Post by tptacek »

cyberax wrote: post #11
tptacek wrote: post #9

Earlier quoted context omitted.

This decreases the salience of DANE/DNSSEC by taking DNS queries off the per-issuance critical path. Attackers targeting multitenant platforms get only a small number of bites at the apple in this model.

Sure. It's yet another advantage of doing True DANE. But it still requires DNS to be reliable for the certificate issuance to work, there's no way around it. So why not cut out the middleman? (And the answer right now is "legacy compatibility")

I mean, the reason not to do DANE is that nobody will DNSSEC-sign, because DNSSEC signing is dangerous.

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

#13

Post by mcpherrinm »

ragall wrote: post #5
mmh0000 wrote: post #4

I really like and hate this at the same time. Years ago, I had a really fubar shell script for generating the DNS-01 records on my own (non-cloud) run authoritative nameserver. It "worked," but its reliability was highly questionable. I like this DNS-PERSIST fixes that. But I don't understand why they chose to include the account as a plain-text string in the DNS record. Seems they could have just as easily used a ra…

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.

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

#14

Post by NoahZuniga »

tptacek wrote: post #9
cyberax wrote: post #6

Ah, the next step towards True DANE! We then can just staple the Persist DNS key to the certificate itself. And then we just need to cut out the middleman and add a new IETF standard for browsers to directly validate the certificates, as long as they confirm the DNS response using DNSSEC.

This decreases the salience of DANE/DNSSEC by taking DNS queries off the per-issuance critical path. Attackers targeting multitenant platforms get only a small number of bites at the apple in this model.

DNS queries are still part of the critical path, as let's encrypt needs to check that the username is still allowed to receive a cert before each issuance.

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

#15

Post by newsoftheday »

Today I do the following:

/usr/bin/letsencrypt renew -n --agree-tos --email me@example.com --keep-until-expiring

Will I need to change that? Will I need to manually add custom DNS entries to all my domains?

PS To add, compared to dealing with some paid certificate services, LetsEncrypt has been a dream.

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

#16

Post by Ayesh »

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily.

The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credentials, so this does not provide any new isolation.

~It's also not quite clear how to revoke this challenge, and how domain expiration deal with this. The DNS record contents should have been at least the HMAC of the account key, the FQDN, and something that will invalidate if the domain is transferred somewhere else. The leaf DNSSEC key would have been perfect, but DNSSEC key rotation is also quite broken, so it wouldn't play nice.~

Is there a way to limit the challenge types with CAA records? You can limit it by an account number, and I believe that is the most tight control you have so far.

---

Edit: thanks to the replies to this comment, I learned that this would provide invalidation simply by removing the DNS record, and that the DNS records are checked at renewal time with a much shorter validation TTL.

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

#17

Post by CqtGLRGcukpy »

"Support for the draft specification is available now in Pebble, a miniature version of Boulder, our production CA software. Work is also in progress on a lego-cli client implementation to make it easier for subscribers to experiment with and adopt. Staging rollout is planned for late Q1 2026, with a production rollout targeted for some time in Q2 2026."

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

#18

Post by dextercd »

newsoftheday wrote: post #15

Today I do the following: /usr/bin/letsencrypt renew -n --agree-tos --email me@example.com --keep-until-expiring Will I need to change that? Will I need to manually add custom DNS entries to all my domains? PS To add, compared to dealing with some paid certificate services, LetsEncrypt has been a dream.

This adds a new validation method that people can use if they want. The existing validation methods (https://letsencrypt.org/docs/challenge-types/) aren't going away, so your current setup will keep working.

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

#19

Post by amluto »

Ayesh wrote: post #16

I'm surprised the ballot passed, unanimously even! I get that storing the DNS credentials in the certificate renewal pipeline is risky, but many DNS providers have granular API access controls, so it is already possible to limit the surface area in case the keys get leaked. Plus, you can revoke the keys easily. The ACME account credentials are also accessible by the same renewal pipelines that has the DNS API credent…

> but many DNS providers have granular API access controls

And many providers don't. (Even big ones that are supposedly competent like Cloudflare.)

And basically everyone who uses granular API keys are storing a cleartext key, which is no better and possibly worse than storing a credential for an ACME account.

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

#20

Post by Ayesh »

gsich wrote: post #7
TrueDuality wrote: post #2

I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that. While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attac…

The account is the same as you create in any acme client. I don't see potential for a reverse lookup.

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.
Post reply on HN