Thank you for the explanation Youfu! @Authors, I think there is a legitimate point here that the proposed sub-domain structure (based on hash of account URL) will make it difficult to monitor for unexpected acme challenges showing up on the DNS record for a given domain. I am curious to hear your response; whether you think there is a technical solution, or if this is an unavoidable consequence and should simply be noted in the Security Considerations.
On Sun, 29 Mar 2026 at 21:08, Youfu Zhang <[email protected]> wrote: > Hi Mike, > > > is it not feasible in most DNS setups to query all subdomains, and you > can only query if you know the exact subdomain to query for? > > As far as I know, it’s generally not feasible to enumerate all > subdomains in typical DNS setups—you usually need to know the exact > name you’re querying for. There are a couple of notable exceptions: > - DNS zone transfers (AXFR/IXFR): These are mechanisms used to > replicate DNS records from a primary server to secondary servers. When > misconfigured, they can expose the full zone contents, but they’re > typically restricted and not accessible to the public internet. > - NSEC/NSEC3-based enumeration: In DNSSEC-enabled zones, NSEC (and in > some cases NSEC3) records can be used to infer existing domain names > by revealing gaps between entries. While NSEC makes this relatively > straightforward, NSEC3 was designed to make enumeration harder by > hashing names—though it may still be possible under certain > conditions. > > Best, > Youfu Zhang > > On Mon, Mar 30, 2026 at 5:19 AM Mike Ounsworth <[email protected]> > wrote: > > > > Hi Youfu, > > > > > This appears to remove the feasibility of DNS-based monitoring > > approaches that rely on polling a fixed namespace. > > > > I'm not sure that I understand the problem you are presenting. According > to the draft, the account-specific namespaces look like this: > > > > _ujmmovf2vn55tgye._acme-challenge.example.org > > > > I am not a deep expert in DNS, but can't you still monitor _*._ > acmechallenge.example.org, the same way you currently monitor > _acmechallenge? Or is it not feasible in most DNS setups to query all > subdomains, and you can only query if you know the exact subdomain to query > for? I do think you are raising a good point that the authors should > address in the Security Considerations section. > > > > > > > > Having reviewed the document, I have a few comments of my own for the > authors;q > > > > Section 3.2 contains this example: > > _ujmmovf2vn55tgye._acme-challenge.example.org 300 IN TXT > "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" > > > > > > I think it well-explained where the "_ujmmovf2vn55tgye" comes from, but > where does the "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI" come from? Is that > supposed to be the token from the challenge? If so, you should add a bullet > explaining this, and align that to the example in 3.1 which currently has > "token": "ODE4OWY4NTktYjhmYS00YmY1LTk5MDgtZTFjYTZmNjZlYTUx". I also don't > see this well explained in 3.3. > > > > > > You mention in Sec Cons that 10 bytes of the SHA256 hash should be > enough to handle non-malicious collisions. You should do the math and list > out the probability that two Account URLs collide, and say what an ACME > client should do if a collision happens -- I suppose the default is that it > actually doesn't know that there has been a collision since this looks like > the existing DNS record was from a previous run of it, and it just > over-write the value. But I think you should include this somewhere in the > document as an operational pitfall that operators should watch out for -- > it will manifest as there being one less ACME DNS record than they are > expecting to see. > > > > On Sun, 29 Mar 2026 at 01:51, Youfu Zhang <[email protected]> wrote: > >> > >> Hi all, > >> > >> I would like to raise a potential operational/security consideration > >> around DNS-ACCOUNT-01. > >> > >> Prior to DNS-ACCOUNT-01, ACME DNS-based validation methods (e.g., > >> DNS-01, DNS-PERSIST-01) relied on well-known, predictable labels such > >> as _acme-challenge.<domain>. This enabled domain owners or third > >> parties to monitor those names for unexpected TXT records as a weak > >> signal of ongoing or potentially unauthorized validation activity. > >> > >> With DNS-ACCOUNT-01, the validation name incorporates an > >> account-derived label. As a result, the effective validation namespace > >> becomes unpredictable to observers who do not already know the ACME > >> account URI. > >> > >> This appears to remove the feasibility of DNS-based monitoring > >> approaches that rely on polling a fixed namespace. In effect, > >> DNS-ACCOUNT-01 replaces a shared, predictable monitoring surface with > >> per-account isolation. > >> > >> A few questions for the WG: > >> - Is this reduction in a predictable DNS monitoring surface an > >> intentional trade-off of DNS-ACCOUNT-01? > >> - Has the WG considered whether this changes the detectability of > >> unauthorized validation activity in environments where DNSSEC is not > >> deployed (e.g., where DNS responses may be forged/modified on-path)? > >> - Would it be useful to document this explicitly in the Security > >> Considerations section, so operators are aware that DNS-based > >> monitoring techniques targeting _acme-challenge no longer generalize? > >> > >> To be clear, I understand that Certificate Transparency is the primary > >> mechanism for detecting misissuance. This question is specifically > >> about whether DNS-ACCOUNT-01 removes a secondary (albeit weaker) > >> monitoring signal that some operators may currently rely on. > >> > >> Thanks, > >> Youfu Zhang > >> > >> _______________________________________________ > >> Acme mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
