minor nit: I don't really think there can be an NXDOMAIN that "*should* be signed, but isn't" from the perspective of a stub resolver. NXDOMAIN is a DNS return code (RCODE:3) like SERVFAIL (RCODE:2). If DNSSEC validation fails (e.g., an authoritative doesn't respond with proof of nonexistence), the RFC instructs recursive resolvers to return SERVFAIL not the typical NXDOMAIN code. Thus, from the perspective of a CA software stack my understanding is that it should be sufficient to treat an NXDOMAIN as properly signed and validated if the recursive is performing proper DNSSEC validation.
>From the perspective of the recursive resolver domain non-existence needs to be checked with the proper algorithms defined in the DNSSEC RFCs to ensure they are authenticated, so here there is the potential for an improperly-signed NXDOMAIN response. At least this is my understanding. Best, Henry On Tue, Mar 17, 2026 at 9:17 AM 'Aaron Gable' via [email protected] <[email protected]> wrote: > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfFNEG5Hbb5gRZPPXXiC%2BEP-nU3%3D0WyvBFNgo9uwJX53w%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/CAGxVKU4m7%2BSQ6NMMR8QjQ-WZeD64pxqsR%3DgmEuA1qsTqK-YuDA%40mail.gmail.com.
