On Tue, Mar 17, 2026 at 7:56 AM Michael Stone <[email protected]> wrote: > 3. Bug 1695786 (SECOM) > > In Bug 1695786, SECOM treated NXDOMAIN for the non-existent domain sgnwffw001 > as permission to issue. Ryan and Paul clarified that when the root zone has a > DNSSEC validation chain, a CA must not treat a lookup failure (including > NXDOMAIN) as permission to issue — i.e., it must fail closed.
> 4. The apparent tension > > Subdomain NXDOMAIN (e.g., sub.example.com): RFC 8659 and the Oct 4 thread > suggest we continue to the parent example.com — NXDOMAIN = "no CAA here" = > keep climbing. > Non-existent domain NXDOMAIN (e.g., sgnwffw001): Bug 1695786 indicates that > when DNSSEC is present, NXDOMAIN must not be treated as permission — fail > closed. > Signed NXDOMAIN (Oct 9 thread): The question of whether "signed NXDOMAIN" is > a failure suggests DNSSEC-authenticated NXDOMAIN may have different handling > than unsigned NXDOMAIN. > > 5. Questions: > > Q1 — Subdomain NXDOMAIN: > We are issuing for www.example.com. The parent example.com exists. CAA lookup > for www.example.com returns NXDOMAIN. Should the CA: > (a) Continue to query CAA for example.com, and allow issuance only if > example.com also has no CAA records; or > (b) Treat NXDOMAIN as a lookup failure and deny issuance? > > Q2 — Non-existent domain with DNSSEC: > We are issuing for sgnwffw001 (the domain does not exist in DNS). The root > zone has a DNSSEC validation chain. CAA lookup returns NXDOMAIN. Must the CA > deny issuance (fail closed), and must it NOT treat NXDOMAIN as "no CAA > restriction" and allow issuance? I think Q2 is misleading because you are using an unqualified name, which confuses things. I think you are calling out a disagreement about signed vs. unsigned. Consider requests for the following, both of which are FQDNs that do not exist where the parents exist. demo.example.com demo.atomicpath.com In the first case, example.com is a signed zone that chains back to the root, so the result is a Trusted Existence denied. In the second case, atomicpath.com is an unsigned zone, so the result is an Unsigned No data found. com returned a Trusted Existence denied: atomicpath.com. DS, so we have trusted confirmation that com does not expect atomicpath.com to be signed. There are no CAA records for example.com, atomicpath.com, or com. Is the CA allowed to issue for both names? Thanks, Peter -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAK6vND8Vcond4zy5yf0EM9Jn5%3DfzvJWVV4hmkhJmMUHiU5qvBQ%40mail.gmail.com.
