Hi All, Thank you for the comments and thoughts on this, with your help, I summarize the following decision flow as following for CAA checking, correct me if I'm wrong:
``` Receive CAA query result │ ├─ RCODE = NXDOMAIN? │ │ │ ├─ AD = 1 │ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) │ │ │ ├─ Parent zone has no DNSSEC │ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) │ │ │ └─ AD = 0 AND parent has DNSSEC │ └─ Untrustworthy → fail closed, refuse issuance │ ├─ SERVFAIL / TIMEOUT / REFUSED / NOTIMP? │ └─ MAY refuse issuance (fail closed → refuse issuance) │ ├─ NOERROR + has CAA records? │ ├─ issue/issuewild restricts issuance → apply CAA policy │ ├─ critical unknown tag → refuse issuance │ └─ iodef or unknown tags only → treat as Empty, continue to parent │ ├─ NOERROR + no CAA records (Empty)? │ └─ continue to Parent(X) │ └─ Reached root "." and still Empty? └─ CAA does not restrict issuance ``` On Wednesday, March 18, 2026 at 2:50:24 PM UTC+8 Henry Birge-Lee wrote: > 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/a177ee80-a6c8-401f-9f47-c3ab7dca70bbn%40mozilla.org.
