Clarification on CAA NXDOMAIN handling: RFC 8659 vs. BR / Bug 1695786

[Michael Stone]

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:

• 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, 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

[Aaron Gable]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAPWqpPHg6MhO5t8zR5yycrysbV2koKBat%3DE8Wb0WLu%2BcKmS0PQ%40mail.gmail.com.

[Henry Birge-Lee]

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

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnErfFNEG5Hbb5gRZPPXXiC%2BEP-nU3%3D0WyvBFNgo9uwJX53w%40mail.gmail.com.

[Michael Stone]

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

```

[Peter Bowen]

On Tue, Mar 17, 2026 at 7:56 AM Michael Stone <songx...@gmail.com> 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

[Michael Stone]

Hi Peter,

According to this decision flow, I think it's okay for a CA to issue certificates:

```

Receive CAA query result

│

├─ RCODE = NXDOMAIN?

│ │

│ ├─ AD = 1

│ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) <---- example.org

│ │

│ ├─ Parent zone has no DNSSEC

│ │ └─ Trustworthy → CAA(X) = Empty → continue to Parent(X) <---- atomicpath.com

│ │

│ └─ 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

```