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]
