SERVFAIL and the DNSSEC requirements

[Martijn Katerbarg]

All,

I’m wondering what this group’s interpretation is on the current DNSSEC language. Specifically:

Effective March 15th, 2026: DNSSEC-validation errors observed by the Primary Network Perspective (e.g., SERVFAIL) MUST NOT be treated as permission to issue.

I wonder if this language is scoping the extent of "MUST NOT be treated as permission to issue.” To a much larger scale than just DNSSEC failures. 

Yes, a DNSSEC verification failure may return a SERVFAIL, depending on how the lookup is performed. But the specific callout of the “SERVFAIL” example, calls into question if CAs need to treat any SERVFAIL response as "MUST NOT be treated as permission to issue.”, including domain names which are not DNSSEC-signed, which suddenly would incorporate lame delegations and other DNS issues at the domain name's name servers. 

What are the thoughts of this group, does this need to be further clarified? 

Regards,

Martijn

[Roman Fischer]

Hi Martjin,

 

My interpretation is that the statement is part of the section 3.2.2.8.1 DNSSEC Validation of CAA Records, and thus only applies to CAA lookups.

 

Rgds
Roman

--
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/SA1PR17MB65035AD833994C0FF4AF784FE363A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Jacob Hoffman-Andrews]

The "MUST NOT be treated as permission to issue" language is in there because RFC 8659 treats the absence of a CAA record as permission to issue (that is, all CAs are authorized by all domains unless the domain states otherwise). That results in a needed clarification: SERVFAIL does not indicate the absence of a CAA record.

For other DNS queries made by the CA, a specific record must be present. For instance DNS Change validation, the CA needs to find a specific TXT record. For host-based validation, the CA needs to find an A or AAAA record. If the CA's recursive resolver returns SERVFAIL due to a misconfiguration or outage at the authoritative resolver, those TXT, A, or AAAA records aren't present, so validation fails. That's always been true, with or without DNSSEC.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB0170BC4EB3598FEA36D2FF4BFA63A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Martijn Katerbarg]

Hi Jacob,

>SERVFAIL does not indicate the absence of a CAA record.

You are correct. However historically, the BRs have account for this. The language in 3.2.2.8 states:

CAs are permitted to treat a record lookup failure as permission to issue if:

    the failure is outside the CA's infrastructure; and

    the lookup has been retried at least once; and

    the CA has confirmed that the domain is "Insecure" as defined in RFC 4035 Section 4.3.

My question was really if the newly added DNSSEC “SERVFAIL” callout, conflicts / negates that final bullet point or not. I’ll also illustrate this with the examples I’ve setup:

• https://dns.google/query?name=dnstestsuite2.com&rr_type=A&ecs=
• This returns a SERVFAIL response. As this a DNSSEC signed domain name, it is not considered Insecure (rather, Bogus). Both old and the newly added DNSSEC verification requirements prevent completing CAA verifications, thus one would not be allow to issue for this domain.
• https://dns.google/query?name=internal.dnstestsuite7.com&rr_type=A&ecs=
• This one likewise has a SERVFAIL response, however the domain name is not DNSSEC signed. The SERVFAIL itself is purely because the name servers of internal.dnstestsuite7.com are not reachable (a Lame Delegation, IIUC). Since the zone is considered Insecure, and the lookup failure is clearly outside of the CAs network, one is able to treat this as permission to issue (and subsequently process CAA at the base domain).
• 
  

In the SCWG call yesterday, this was discussed, and general consensus, including that of the ballot proposer, was that the new SERVFAIL callout is specifically intended to be scoped for DNSSEC signed domain names, not those living in an Insecure zone. 

• 
  

Regards,

Martijn

From: 'Jacob Hoffman-Andrews' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Thursday, 12 February 2026 at 20:17
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] RE: SERVFAIL and the DNSSEC requirements

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAN3x4QkoJtqRn4cMuG%3DFdLSDUd1r_QV7V2jK6bFE9fzoePy%2Bxg%40mail.gmail.com.

[Henry Birge-Lee]

Hi Martijn and all,

I am pretty sure I am the author of the line in question from the ballot. The intent of the line is ensure that DNSSEC-validation errors observed by the Primary Network Perspective MUST NOT be treated as permission to issue. This stance is independent of the error type so long as the error is associated with DNSSEC validation. I included the SERVFAIL example as DNSSEC validation errors are most commonly indicated at the recursive resolver as SERVFAIL, so I felt shedding light on this case provided additional clarity.

That said, not all DNSSEC validation errors are SERVFAIL and not all SERVFAIL errors are associated with DNSSEC validation. A CA could potentially use a DNS library like libunbound to perform custom DNS lookups and validation within CA source code (BTW I personally don't recommend this due to the complexity of implementing the DNSSEC validation algorithms). This is an example of a configuration where a DNSSEC validation error may not be SERVFAIL. Also, SERVFAIL is a DNS error code that predates DNSSEC and as Martijn correctly points out there are DNS configurations that return SERVFAIL independent of DNSSEC validation.

Under both the new and old text, failures on CAA lookups on non-DNSSEC domains can be treated as permission to issue and I feel these permitted failures can include SERVFAIL errors.

I personally feel the text as written still permits this. I am open to hearing the interpretation of others in the community, but this was the intent of that text and the SERVFAIL example.

Best,

Henry