Question about implementation of DNSSEC checks of CAA subdomain with NSEC/NSEC3 status

[Roman Fischer]

Dear Community,

 

One of our PKI engineers brought up the following situation where we are not certain which option to implement:

 

The following is the implemented procedure for domain validations without DNSSEC: 

·                    The base domain, e.g. basedomain.com, is validated.

·                    A certificate with the subdomain sub.basedomain.com has been requested. If the NS servers were set up correctly and the CAA check was successful, it did not matter that there was no zone or RRset for this subdomain.  

·                    In such a case, the certificate could be issued.

 

Now, since DNSSEC checks have been introduced, the situation is slightly different:  

·                    The base domain, e.g. basesecdomain.com, is validated.

·                    A certificate with the subdomain sub.basesecdomain.com has been requested. If the NS servers were set up correctly and the CAA check was positive, we would receive an NSEC or NSEC3 entry if there was no zone and RRset for this subdomain. 

·                    In this case, we do not know whether a certificate can be issued or not. 

 

Arguments in favor of issuance: 

·                    A validly signed NSEC/NSEC3 is NOT a DNSSEC validation error (SERVFAIL or Bogus), but rather a secure statement about the absence of the CAA entry. This must trigger the mandatory CAA tree climbing to the validated base domain. 

·                    Previous behavior for non-existent subdomain configurations are retained and do not confuse customers if they request certificates with multiple domains which may combine domains which have DNSSEC disabled or enabled. 

·                    Certificates can be issued before valid subdomain zones and its RRset’s are set up. 

·                    Example: The PKI manager can issue a certificate for shop.basesecdomain.com before the zone has been set up.

 

Arguments against issuance: 

·                    NSEC/NSEC3 cryptographically proves the authenticated non-existence of the subdomain resource. If such negative proof exists, the name is invalid in the DNSSEC-secured zone; CAA tree climbing as policy validation cannot be considered at this level, as it has been proven that no test object exists. 

·                    The logic behind that is that a DNSSEC RRset chain of the subdomain must be valid in order to even begin a CAA check. 

·                    DNSSEC is supposed to be a mechanism that secures all the domains and subdomains which are used, and it makes somehow no sense to be able to issue a certificate for a subdomain that does not exist. 

·                    Certificates can only be issued after valid subdomain RRset’s have been set up. 

·                    Example: The PKI manager can issue shop.basesecdomain.com after the zone has been set up properly. 

 

What is the community's view on this topic?

 

Kind regards
Roman

 

Roman Fischer

Information Security Manager

 

+41 76 310 12 66

roman....@swisssign.com

 

SwissSign AG

Sägereistrasse 25

Postfach

CH-8152 Glattbrugg
swisssign.com

 

Nichts mehr verpassen: Folgen Sie uns auf LinkedIn!

Abonnieren Sie unseren Newsletter oder besuchen Sie unseren Blog.

 

[Rob B]

My snap thoughts on this 

What happens at a higher level?

EG

Request comes in for www2.example.com, but there is no entry for www2

Or how about for “example.com” where there is no current registration for example.com? There is for .com from .

I’d imagine (and expect) policy language would forbid such issuance (would be prohibited via previous methods), so it feels right to deny such a request for consistency.

Thoughts?

Rob

---

From: 'Roman Fischer' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, September 25, 2025 6:33:34 AM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Question about implementation of DNSSEC checks of CAA subdomain with NSEC/NSEC3 status

 

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB017077CA84BDB1225E4A8AF2FA1FA%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Henry Birge-Lee]

HI all,

My take is that in the example Roman brought up, a certificate can be issued presuming the NSEC/NSEC3 record is retrieved, validated properly, and shows that no secure delegation exists to the provided subdomain.

Checking this record shows that the subdomain is "insecure" (i.e., the DNSSEC validating resolver is assured that there is no possible chain for that subdomain back to the IANA root).

I would count this as a lookup failure outside the CA infrastructure (e.g., a NXDOMAIN error).

The CA could perform a retry.

From a security perspective, I do not think this behavior degrades the security impact of CAs checking DNSSEC. Even with this issuance permitted, any DNSSEC signed domain will still require a valid NoError CAA lookup (this condition will never be met for a DNSSEC signed domain). To me, this is the desired security property of interest from this language (DNSSEC domains benefit from cryptographic protection and robustness to CAA record tampering by on-path or off-path adversaries).

There are I think two other considerations at play here:

1) is it firmly agreed CAs are allowed to issue certificates for labels that are clearly NXDOMAIN (assuming validation can be done at the parent label)? Many CAs have brought this to my attention. This root motivation for discussing this CAA lookup failure language seems to often be certs for NXDOMAINs (there is also some discussion of firewalled nameservers, but I think this issuing in the case of a firewalled nameserver is much less debatable under the current language). The interpretation of if a CA can issue to an NXDOMAIN I feel impacts how this language would be or should be interpreted.

2) the NSEC/NSEC3 opt-out bit. The opt-out bit changes the behavior of NSEC/NSEC3 records to allow them to either show or skip over insecure delegations. The NSEC records in a zone will always show exactly where each secure delegation is (i.e., a subdomain with a DS record). However, without the opt-out bit, NSEC records also show all delegations from the zone in question. With the opt-out bit, NSEC records only show secure delegations. If the opt-out bit is set, I feel grounds for issuing in the case Roman discussed are stronger as the cryptographically-signed record makes no statement as to the existence or lack of existence of an insecure delegation at the label in question. With the opt-out bit unset, I think the problem more directly hinges on point 1: is a CA truly allowed to sign on an NXDOMAIN.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/DM6PR01MB4329742789A0C37A139F8277D11FA%40DM6PR01MB4329.prod.exchangelabs.com.

[Michael Richardson]

'Roman Fischer' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
> Arguments in favor of issuance: · A validly signed NSEC/NSEC3 is NOT a
> DNSSEC validation error (SERVFAIL or Bogus), but rather a secure
> statement about the absence of the CAA entry. This must trigger the
> mandatory CAA tree climbing to the validated base domain.

Yes.
The CAA does not exist. Same as NXDOMAIN before DNSSEC.
Do whatever you did then, which is climbing.
You didn't need the A/AAAA to exist before, so no change.

> Arguments against issuance: · NSEC/NSEC3 cryptographically proves the
> authenticated non-existence of the subdomain resource. If such negative
> proof exists, the name is invalid in the DNSSEC-secured zone; CAA tree

It's invalid in the view that they have shown you.
Geofenced and split-horizon DNS might have useful things, but you can't see that.

> secures all the domains and subdomains which are used, and it makes
> somehow no sense to be able to issue a certificate for a subdomain that
> does not exist.

Does not *yet* exist.

> · Certificates can only be issued after valid
> subdomain RRset's have been set up. · Example: The PKI manager can
> issue shop.basesecdomain.com after the zone has been set up properly.

There are lots of good reasons to want security to be setup and automated before going live.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[Peter Thomassen]

Hi Roman,

On 9/25/25 12:33, 'Roman Fischer' via Server Certificate WG (CA/B Forum) wrote:
> Now, since DNSSEC checks have been introduced, the situation is slightly different:
>
> ·The base domain, e.g. basesecdomain.com, is validated.
>
> ·A certificate with the subdomain sub.basesecdomain.com has been requested. If the NS servers were set up correctly and the CAA check was positive, we would receive an NSEC or NSEC3 entry if there was no zone and RRset for this subdomain.

The meaning of an NSEC/NSEC3 proof is not that there was no zone, or that the subdomain does not exist.

What it does: NSEC returns
- the name that is (in canonical order) the zone's largest name that is not larger than the query name;
- the record types that exist at this name;
- the next larger name.

NSEC3 does the same, but names are hashed before ordering.

This has nothing to do with whether the zone exists. In your example, basesecdomain.com is already validated, so the zone surely exists.

> ·/In this case, we do not know whether a certificate can be issued or not. /
>
> *Arguments in favor of issuance:*
>
> ·A validly signed NSEC/NSEC3 is NOT a DNSSEC validation error (SERVFAIL or Bogus), but rather a secure statement about the absence of the CAA entry. This must trigger the mandatory CAA tree climbing to the validated base domain.

This.

> · Previous behavior for non-existent subdomain configurations are retained and do not confuse customers if they request certificates with multiple domains which may combine domains which have DNSSEC disabled or enabled.

DNSSEC indeed does not alter the meaning of a (true, that is, untampered) DNS response. It only provides integrity and origin authentication.

So, behavior should not change -- not to prevent customer confusion, but simply because the semantics of the DNS response are the same.

You do not need to investigate NSEC/NSEC3 responses in detail. You can use a trusted (= run yourself) validating DNS resolver, and then look for the AD bit in the response. Apart from this, responses can be handled the same way as before.

> *Arguments against issuance:*
>
> ·NSEC/NSEC3 cryptographically proves the authenticated non-existence of the subdomain resource. If such negative proof exists, the name is invalid in the DNSSEC-secured zone;

No, that's incorrect.

Even if the name was proven to not exist, there would be no problem. Such a response (if AD=1) simply counts as "empty" in the sense of RFC 8659 Section 3 -- just like NXDOMAIN without DNSSEC.

> CAA tree climbing as policy validation cannot be considered at this level, as it has been proven that no test object exists.

I don't know what this means. The CAA RRset is empty, so tree climbing is applicable.

> ·The logic behind that is that a DNSSEC RRset chain of the subdomain must be valid in order to even begin a CAA check.

I don't understand where this requirement comes from. (Also, NSEC/NSEC3 responses don't indicate a validity problem. They just provide proof that a certain RRset does not exist.)

> ·DNSSEC is supposed to be a mechanism that secures all the domains and subdomains which are used, and it makes somehow no sense to be able to issue a certificate for a subdomain that does not exist.

How is this different from issuing a certificate for a domain without DNSSEC, where the CAA query returns an NXDOMAIN response (= subdomain does not exist)?

Best,
Peter