[HN Gopher] DNS-Persist-01: A New Model for DNS-Based Challenge ...
___________________________________________________________________
DNS-Persist-01: A New Model for DNS-Based Challenge Validation
Author : todsacerdoti
Score : 144 points
Date : 2026-02-18 18:04 UTC (4 hours ago)
(HTM) web link (letsencrypt.org)
(TXT) w3m dump (letsencrypt.org)
| TrueDuality wrote:
| 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 attack can commence. This also
| provides the ability to associate random found credentials back
| to the sites you can now issue certificates for if they're using
| the same account. This is free scope expansion for any breach
| that occurs.
|
| I guarantee sites like Shodan will start indexing these IDs on
| all domains they look at to provide those reverse lookup
| services.
| krunck wrote:
| Exactly. They should provide the user with a list of UUIDs(or
| any other randomish ID tied to the actual account) that can be
| used in the accounturi URL for these operations.
| gsich wrote:
| The account is the same as you create in any acme client. I
| don't see potential for a reverse lookup.
| Ayesh wrote:
| 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.
| mschuster91 wrote:
| 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.
| liambigelow wrote:
| CAA records including an accounturi already expose the account
| identity in the same manner, so I feel like that ship has
| already sailed somewhat (and I would prefer that the CAA and
| persist record formats match).
| mmh0000 wrote:
| 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 randomly generated key that wouldn't mean
| anything to anyone outside Let's Encrypt, and without exposing my
| account to every privacy-invasive bot and hacker.
| ragall wrote:
| 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.
| mcpherrinm wrote:
| 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.
| 9dev wrote:
| It's still a valid point IMHO - why not just use the public
| key directly? It seems like the account URI just adds
| problems instead of resolving any.
| glzone1 wrote:
| Interesting.
|
| I didn't realize the email field wasn't persisted. I
| assumed it could be used in some type of account recovery
| scenario.
| Ajedi32 wrote:
| > they could have just as easily used a randomly generated key
|
| Isn't that pretty much what an accounturi is in the context of
| ACME? Who goes around manually creating Let's Encrypt accounts
| and re-using them on every server they manage?
| cyberax wrote:
| 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.
| tptacek wrote:
| 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.
| cyberax wrote:
| 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")
| tptacek wrote:
| I mean, the reason not to do DANE is that nobody will
| DNSSEC-sign, because DNSSEC signing is dangerous.
| cyberax wrote:
| Come on. It's not dangerous, it's just inconvenient and
| clumsy. So nobody is really using it.
| akerl_ wrote:
| Ok, it's inconvenient and clumsy in ways that make it
| easy to shoot oneself in the foot. But that's not
| dangerous?
| cyberax wrote:
| 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.
| tptacek wrote:
| 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.
| NoahZuniga wrote:
| 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.
| micw wrote:
| I wonder why they switched from a super-secure-super-complex (in
| terms of operations) way of doing DNS auth to a super-simple-no-
| cryptography-involved method that just relies on the account id.
|
| Why not using some public/private key auth where the dns contains
| a public key and the requesting server uses the private key to
| sign the cert request? This would decouple the authorization from
| the actual account. It would not reveal the account's identity.
| It could be used with multiple account (useful for a wildcard on
| the DNS plus several independent systems requesting certs for
| subdomains).
| tptacek wrote:
| The most common vector for DNS-based attacks on issuance is
| compromised registrar accounts, and no matter how complicated
| you make the cryptography, if you're layering it onto the DNS,
| those attacks will preempt the cryptography.
| Spivak wrote:
| Because LE keeps a mapping of account ids to emails and public
| keys. You have to have the private key to the ACME account to
| issue a cert. The cryptography is still there but the dance is
| done by certbot behind the scenes.
|
| Prior to this accounts were nearly pointless as proof of
| control was checked every time so people (rightfully) just
| threw away the account key LE generated for them. Now if you
| use PERSIST you have to keep it around and deploy it to servers
| you want to be able to issue certs.
| newsoftheday wrote:
| 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.
| dextercd wrote:
| 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.
| jsheard wrote:
| And to elaborate, the reasons you _might_ want to use a DNS
| challenge are to acquire wildcard certificates, or to acquire
| regular certificates on a machine or domain which isn 't
| directly internet-facing. If neither of those apply to you
| then the regular HTTP/TLS methods are fine.
| newsoftheday wrote:
| OK I was sort of thinking that might be the case but wanted
| to make sure in case I had to start prepping now, thanks.
| We use no wildcard domains today, maybe down the road.
| newsoftheday wrote:
| This is good news, not sure I got that from reading the
| article but even if I had to do it, it wouldn't be the end of
| the world I guess.
| Ayesh wrote:
| 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.
| amluto wrote:
| > 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.
| agwa wrote:
| > _It 's also not quite clear how to revoke this challenge, and
| how domain expiration deal with this_
|
| CAs can cache the record lookup for no longer than 10 days.
| After 10 days, they have to check it again. If the record is
| gone, which would be expected if the domain has expired or been
| transferred, then the authorization is no longer valid.
|
| (I would have preferred a much shorter limit, like 8 hours, but
| 10 days is a lot better than the current 398 day limit for the
| original ACME DNS validation method.)
| mcpherrinm wrote:
| We (Let's Encrypt) also agree 10 days seems too long, so we
| are migrating to 7 hours, aligning with the restrictions on
| CAA records.
| mcpherrinm wrote:
| Yes, you can limit both challenge types and account URIs in CAA
| records.
|
| To revoke the record, delete it from DNS. Let's Encrypt queries
| authoritative nameservers with caches capped at 1 minute.
| Authorizations that have succeeded will soon be capped at 7
| hours, though that's independent of this challenge.
| mcpherrinm wrote:
| This wasn't the first version of the ballot, so there was
| substantial work to get consensus on a ballot before the vote.
|
| CAs were already doing something like this (CNAME to a dns
| server controlled by the CA), so there was interest from
| everyone involved to standardize and decide on what the rules
| should be.
| CqtGLRGcukpy wrote:
| "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."
| csense wrote:
| To get a Let's Encrypt wildcard cert, I ended up running my own
| DNS server with dnsmasq and delegating the _acme-challenge
| subdomain to it.
|
| Pasting a challenge string once and letting its continued
| presence prove continued ownership of a domain is a great step
| forward. But I agree with others that there is _absolutely no
| reason_ to expose account numbers; it should be a random ID
| associated with the account in Let 's Encrypt's database.
|
| As a workaround, you should probably make a new account for each
| domain.
| Spivak wrote:
| You bothered to manage your LE accounts? I only say because
| when using the other two challenge types with most deployment
| scenarios you were generating a new account per cert so your
| account ID was just a string of random numbers.
| Havoc wrote:
| Interesting. Think a lot of the security headaches went away for
| me when I discovered providers like CF can restrict the scope of
| tokens to a single domain and lock it to my IP.
| amluto wrote:
| Even CF cannot restrict the scope of a token to a single host.
| cube00 wrote:
| Or a single DNS record.
| jcalvinowens wrote:
| Really happy to see this.
|
| In the meantime, if you use bind as your authoritative
| nameserver, you can limit an hmac-secret to one TXT record, so
| each webserver that uses rfc2136 for certificate renewals is only
| capable of updating its specific record: key
| "bob.acme." { algorithm hmac-sha512; secret
| "blahblahblah"; }; key "joe.acme." {
| algorithm hmac-sha512; secret "blahblahblah2"; };
| zone "example.com" IN { type master; file
| "/var/lib/bind/example.com.zone"; update-policy {
| grant bob.acme. name _acme-challenge.bob.acme.example.com. TXT;
| grant joe.acme. name _acme-challenge.joe.acme.example.com. TXT;
| }; key-directory "/var/lib/bind/keys-acme.example.com";
| dnssec-policy "acme"; inline-signing yes; };
|
| I like this because it means an attacker who compromises "bob"
| can only get certs for "bob". The server part looks like this:
| export LE_CONFIG_HOME="/etc/acme-sh/" export
| NSUPDATE_SERVER="${YOUR_NS_ADDR}" export
| NSUPDATE_KEY="/var/lib/bob-nsupdate.key" export
| NSUPDATE_KEY_NAME="bob.acme." export
| NSUPDATE_ZONE="acme.example.com." acme.sh --issue
| --server letsencrypt -d 'bob.example.com' \
| --certificate-profile shortlived \ --days 6 \
| --dns dns_nsupdate
| ocdtrekkie wrote:
| This might be the first time in ten years that a certificate
| proposal intends to make issuing certificates more reasonable and
| not less. More of this, less of 7-day-lifetime stupidity.
| qwertox wrote:
| This will make things so much easier.
|
| Here, certbot runs in Docker in the intranet, and on a VPS I have
| a custom-built nameserver to which all the _acme-challenge are
| redirected to via NS records.
|
| The system in the intranet starts certbot, makes it pass it the
| token-domain-pair from letsencrypt, it then sends those pairs to
| the nameserver which then attaches the token to a TXT record for
| that domain, so that the DNS reply can send this to letsencrypt
| when they request it.
|
| All that will be gone and I thank you for that! You add as much
| value to the internet as Wikipedia or OpenStreetMap.
| itintheory wrote:
| 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, it'd become a full time
| job. I just hope Sectigo implements this as quickly as LE.
| 9dev wrote:
| 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.
| bob1029 wrote:
| 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 distribute self-hostable software to users that can
| be deployed onto a VM and made operational literally within 5
| minutes is a big selling point. Domain registration & DNS are a
| massive pain to deal with at the novice end of the spectrum. You
| can combine this with things like https://checkip.amazonaws.com
| to build properly turnkey solutions.
| cube00 wrote:
| Pretty risky given the rate limits of Let's Encrypt are non
| negotiable with no choice but to wait them out.
| muvlon wrote:
| They are quite literally negotiable: https://isrg.formstack.c
| om/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.
| inahga wrote:
| You should persist certs somewhere. Otherwise your availability
| is heavily tied to LE's uptime.
| chaz6 wrote:
| Is it possible to create an ACME account without requesting a
| certificate? AFAICT is is not so you cannot use this method
| unless you have first requested a certificate with some other
| method. I hope I am wrong!
| dextercd wrote:
| An account needs to be created before you can request a
| certificate. Some ACME clients might create the account for you
| implicitly when you request the first certificate, but in the
| background it still needs to start by registering an account.
|
| `certbot register` followed by `certbot show_account` is how
| you'd do this with certbot.
| chaz6 wrote:
| Great, thank you!
| aaomidi wrote:
| This is significantly better than my draft of DNS-ACCOUNT-01.
| Thank you Let's Encrypt team!
| zamadatix wrote:
| Yeessss! This should finally make certificates for internal only
| web services actually easier to orchestrate than before ACME.
| This closes probably the biggest operational pain point I've had
| with letsencrypt/modern web certificates.
|
| Thank you so much to all inolved!
| jmholla wrote:
| There's a missing part here, and that's validating your ACME
| account ownership.
|
| I think most users depend on automation that creates their
| accounts, so they never have to deal with it. But now, you need
| to propagate some credential to validate your account ownership
| to the ACME provider. I would have liked to see some conversation
| about that in this announcement.
|
| I'm not familiar with Let's Encrypt's authentication model. If
| they don't have token creation that can be limited by target
| domain, but I expect you'll need to create separate accounts for
| each of your target domains, or else anything with that secret
| can create a cert for any domain your account controls.
| mschuster91 wrote:
| > There's a missing part here, and that's validating your ACME
| account ownership.
|
| Why? ACME accounts have credentials so that the ACME client can
| authenticate against the certificate issuer, and ACME providers
| require the placement of a DNS record or a .well-known HTTP
| endpoint to verify that the account is authorized to act upon
| the demands of whoever owns the domain.
|
| If either your ACME credentials leak out or, even worse,
| someone manages to place DNS records or hijack your .well-known
| endpoint, you got far bigger problems at hand than someone
| being able to mis-issue SSL certificates under your domain
| name.
| basilikum wrote:
| > The timestamp is expressed as UTC seconds since 1970-01-01
|
| That should be TAI, right? Is that really correct or do they
| actually mean unix timestamps (those shift with leap seconds
| unlike TAI which is actually just the number of seconds that have
| passed since 1970001Z)?
| wtallis wrote:
| Do leap seconds even matter here? Doing anything involving DNS
| or certificates in a way that requires clock synchronization
| down to the second would seem to be asking for trouble.
| mscdex wrote:
| After having to deal with VM hosts that do GeoIP blocking, which
| unintentionally blocks Let's Encrypt and others from properly
| verifying domains via http-01/tls-alpn-01, I settled on a DIY
| solution that uses CNAME redirects and a custom, minimal DNS
| server for handling the redirected dns-01 challenges. It's
| essentially a greatly simplified version of the acme-dns project
| tailored to my project's needs (and written in node.js instead of
| Go).
|
| Unfortunately with dns-persist-01 including account information
| in the DNS record itself, that's a bit of a show stopper for me.
| If/when account information changes, that means DNS records need
| changing and getting clients to update their DNS records (for any
| reason) has long been a pain.
| Ajedi32 wrote:
| This is going to make it way easier to get publicly trusted certs
| for LAN servers that aren't internet facing.
|
| I'm looking forward to every admin UI out there being able to
| generate a string you can just paste into a DNS record to
| instantly get a Let's Encrypt cert.
| infogulch wrote:
| 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
___________________________________________________________________
(page generated 2026-02-18 23:00 UTC)