Four key themes that dominate the discussion
| # | Theme | Representative quotes |
|---|---|---|
| 1 | Operational convenience vs. the cost of a persistent DNS record | “I really like and hate this at the same time.” – mmh0000 “This 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.” – csense “This will make it so much easier.” – qwertox |
| 2 | Privacy and exposure of the ACME account URI | “This is publicly publishing the account ID… it’s easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).” – TrueDuality “The account URI is opaque… the privacy exposure is modest: it reveals which CA account controls the domain.” – pepdar |
| 3 | Security posture – DNSSEC, MPIC, and attack surface | “DNSSEC prevents any modification of records, but isn’t widely deployed.” – mcpherrinm “We query authoritative nameservers directly from at least four places… this (called MPIC) makes interception more difficult.” – msmith “If a CA performs DNSSEC validation and it fails… the CA MUST treat it as a challenge failure.” – pepdar |
| 4 | Implementation & tooling choices (Docker, APIs, per‑domain accounts, key rotation) | “Run ACME inside a Docker container, one instance (and credentials) for each domain name.” – mschuster91 “Use a UUID as username… create one LetsEncrypt account per FQDN.” – ragall “Key rotation doesn’t change the account URI – ACME key rollover replaces the key pair but keeps the same account URL.” – pepdar |
These four themes capture the bulk of the conversation: the promise of easier automation, the trade‑off of exposing account identifiers, the security mechanisms that mitigate the new attack surface, and the practical choices developers make to adopt the new DNS‑PERSIST‑01 method.