If you get a trustworthy NXDOMAIN, that means you have to check the parent domain. There are two kinds of trustworthy NXDOMAINs: - If there is a DNSSEC-authenticated denial of existence (a "signed NXDOMAIN"), that's clearly trustworthy, and you must check CAA at the parent. - Similarly, if there is no DNSSEC at all, then this unsigned NXDOMAIN is the most trustworthy response you can expect to get, and you must check CAA at the parent.
The only situation in which you treat NXDOMAIN as an error and must refuse to issue is when the NXDOMAIN response *should* be signed, but isn't. This indicates that an attacker may be attempting to suppress CAA records which would prevent them from issuing for the domain, so you need to act as though there were CAA records at that domain. In this case, the parent domain's CAA records are irrelevant (because the records at the domain would control), but we don't know what the records at the domain itself actually are, so we have to fail closed. In summary: Q1: You must check the parent. Q2: I don't think your description of this situation is sufficiently precise. But I think you're describing the situation in the paragraph above, in which the parent zone is DNSSEC signed but does not carry a signed denial of existence of the subdomain, and yet the subdomain does not have a DNSSEC signature. In this case you must fail closed and not allow issuance. Q3: You must check the parent. Aaron On Tue, Mar 17, 2026 at 7:56 AM Michael Stone <[email protected]> wrote: > > Hi, > > I'm writing to ask for clarification on how CAA checking should handle > NXDOMAIN. I've found what appears to be a tension between different sources > and would like to understand the correct interpretation. > > 1. RFC 8659 > > RFC 8659 Section 3 defines the CAA lookup algorithm: if CAA(domain) is > not Empty, return it; otherwise move to the parent. If no CAA records are > found anywhere, we return Empty and "CAA does not restrict issuance." > NXDOMAIN is often interpreted as "no CAA at that label" (Empty), so the > algorithm continues to the parent. > > 2. CAB Forum discussions (2017) > > From the CAB Forum public list search for NXDOMAIN > <https://groups.google.com/a/groups.cabforum.org/g/public/search?q=nxdomain> > : > > - > > Doug Beattie & Jacob Hoffman-Andrews (Oct 4, 2017) — "CAA look up > failures and retry logic": When sub.example.com returns NXDOMAIN, the > CA is still required to attempt looking up a CAA record for example.com. > This suggests NXDOMAIN at a subdomain should trigger continued lookup at > the parent, not immediate permission to issue. > - > > Doug Beattie & Ryan Sleevi (Oct 9, 2017) — "CAA, DNSSEC and NXDOMAIN": > DNSSEC provides authenticated denial of existence for signed zones, > essentially a "signed NXDOMAIN" response. The thread asks whether this is > considered a failure (i.e., must not be treated as permission to > issue). > > 3. Bug 1695786 (SECOM) > > In Bug 1695786 <https://bugzilla.mozilla.org/show_bug.cgi?id=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? > > Q3 — Signed NXDOMAIN: > We are issuing for sub.example.com. The zone example.com is > DNSSEC-signed. CAA lookup for sub.example.com returns a > DNSSEC-authenticated NXDOMAIN (signed NXDOMAIN). Should the CA: > (a) Treat signed NXDOMAIN as "no CAA at this label" and continue to query > CAA for example.com; or > (b) Treat signed NXDOMAIN as a lookup failure and deny issuance? > > I would appreciate the community's view on how to reconcile these sources. > Ryan's perspective would be especially helpful given his comments in Bug > 1695786. > > Thanks, > > Michael > > -- > 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/CAPWqpPHg6MhO5t8zR5yycrysbV2koKBat%3DE8Wb0WLu%2BcKmS0PQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPWqpPHg6MhO5t8zR5yycrysbV2koKBat%3DE8Wb0WLu%2BcKmS0PQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEmnErfFNEG5Hbb5gRZPPXXiC%2BEP-nU3%3D0WyvBFNgo9uwJX53w%40mail.gmail.com.
