121–130 of 164 posts
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.)
Hetzner does not charge any money for their dns service and they have an api.
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.
What open source DNS servers have an API? (I saw someone elsewhere in the thread talking about doing this with dnsmasq, but it sounded like they'd cobbled something together, rather than the software handling it.)
Earlier quoted context omitted.
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.
Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye by…
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks…
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.
What open source DNS servers have an API? (I saw someone elsewhere in the thread talking about doing this with dnsmasq, but it sounded like they'd cobbled something together, rather than the software handling it.)
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…
https://letsencrypt.org/docs/challenge-types/#:~:text=This%2...
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks…
DNSSEC is encouraged ("SHOULD" wording) in the RFC draft : https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-pe...
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 maste…
Why account URI instead of a public key in the record? (micw, 9dev, csense)
Three reasons:
1. Key rotation without DNS changes. dns-persist-01 exists because DNS updates are expensive. Embedding a public key forces a DNS update on every key rotation — the exact problem this method solves. The account URI survives key rotation (RFC 8555 §7.3.5).
2. CAA alignment. The accounturi parameter matches CAA record syntax (RFC 8657 §3). Domain owners use the same identifier in validation and policy records.
3. Simplicity. Matching uses simple string comparison — no key encoding, no signature verification, no algorithm negotiation. The cryptographic binding between account URI and key pair happens inside ACME, where it belongs.
"Exposing account numbers" / privacy (csense, mmh0000, bflesch)
The account URI is opaque — a URL containing a database key, like https://acme-v02.api.letsencrypt.org/acme/acct/123456789. No email, no name. The privacy exposure is modest: it reveals which CA account controls the domain, similar to what CT logs already show about CA-domain relationships, but with explicit account-level grouping. If you want isolation between domains, use separate accounts.
The accounturi binds validation to a specific account so a stolen DNS record can't be used by a different subscriber. An open PR (#35) adds accounturi to the challenge object so clients can verify it before provisioning.
10-day reuse limit (agwa)
The 10-day maximum comes from the CA/Browser Forum ballot (SC-088), not the IETF draft. The draft defers reuse period to CA policy and caps it at the DNS TTL (see "Validation Data Reuse and TTL Handling" in the Security Considerations). Let's Encrypt is migrating to 7 hours. The TTL cap lets domain owners enforce shorter windows directly.
Mandatory DNSSEC (rmoriz)
Requiring DNSSEC would exclude most domains and block adoption. The current draft specifies DNSSEC validation as SHOULD. An open PR (#35) tightens this: if a CA performs DNSSEC validation and it fails — expired signatures, broken chain of trust — the CA MUST reject the record. This is stricter than general ACME guidance because dns-persist-01 records are long-lived. MPIC (multi-perspective validation) provides the primary defense against on-path attacks regardless of DNSSEC.
Unencrypted DNS queries (1vuio0pswjnm7)
Yes, standard DNS queries are unencrypted. The threat model relies on MPIC — querying from multiple vantage points — not transport encryption. DNSSEC adds an integrity layer where available.
CAA interaction (Ayesh)
Yes. A CAA record with validationmethods=dns-persist-01 combined with accounturi restricts who can validate using this method.
Name-constrained intermediate CAs (infogulch)
Separate problem. dns-persist-01 reduces operational cost of leaf cert issuance by eliminating per-issuance DNS interaction. Delegated intermediates shift the trust model. Both could coexist.
Draft: https://github.com/ietf-wg-acme/draft-ietf-acme-dns-persist> (PR #35 is an open pull request on the draft with several of the improvements mentioned above.)
Earlier quoted context omitted.
You remember what CIA stands for, right?
In order for an attacker to reduce a site's Availability via DNS they must alter the records received by resolvers. If they can do that, they can just refuse to send the records at all (or mangle them such that they are ignored). DNSSEC makes the situation no worse. It does, however, increase Integrity. For the record, the 'A' in CIA refers to resilience against some party's purposeful attempt to make something unava…
That’s pretty clearly not correct.