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]
