Discussion Period Begins SC-100: DNSSEC Clarification and Consolidation

[Rich Smith]

Ballot SC-100: DNSSEC Clarification and Consolidation

--- Ballot Background ---

Discussion prior to, and at CA/Browser Forum Face to Face Meeting #67 in Houston, TX revealed that there was some lack of clarity regarding the DNSSEC validation requirements, particularly in the area of Remote Network Perspectives, as well as the fact that the DNSSEC validation requirements being somewhat scattered throughout Section 3.2.2 made it more difficult to pin down than it could be if all in one place.

--- Ballot Summary ---

Move all DNSSEC validation requirements to the new Section 4.2.2.2.

Reorganize the structure somewhat for easier reading and reduction of repetition.

Clarify that DNSSEC validation MAY be performed on Remote Network Perspectives, but is REQUIRED only on the Primary Network Perspective.

This ballot does not currently have an effective date, as the intent is merely to address clarity and there is no intention to modify the existing requirements

This ballot is proposed by Rich Smith (DigiCert) and endorsed by Trev Ponds-White (Amazon) and Scott Rea (eMudhra)

 

--- Motion Begins ---

 

Modify the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Server Certificates", based on Version 2.2.8, per the following redline:

 

https://github.com/cabforum/servercert/compare/9270ad7887b48d58bf0954336de32c265a934d66...b6dd09f33c3ef9a88672332faca3c4cbcb391276

 

--- Motion Ends ---

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (at least 7 days):

· Start time: 2026-06-30 17:00 UTC

· End time: 2026-07-07 17:00 UTC or later

Vote for approval (7 days):

· Start time: TBD

· End time: TBD

 

 

Rich Smith

Sr. Director, Product Technical Excellence

 

 

 

[Backman, Antti]

Hi Rich

While reviewing the changes presented in this Ballot, a question came up that I would like some help to ensure that we fully understand the intention of the modified language. 

As per the section 4.2.2.2.7

...

The full set of DNS lookup information related to DNSSEC validation is considered outside the scope of:

1. self-audits performed to fulfill the requirements in [Section 8.7](#87-self-audits); and

2. the logging requirements of [Section 5.4.1](#541-types-of-events-recorded).

...

I believe the “full set of DNS lookup information” is not defined anywhere (at least not in BR), right?

If I have not missed something, there’s nothing on DNSSEC logging (at least not explicitly) in section 5.4.1, obviously some required events to be logged may carry over entries from DNS / DNSSEC queries. 

To verify that our logging meets the expectations, would you be able to help us to understand what should be then logged specifically for DNSSEC queries? 

//Antti

From: 'Rich Smith' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Monday, 29. June 2026 at 22.08
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Discussion Period Begins SC-100: DNSSEC Clarification and Consolidation

Caution: This is an external email. Stop, assess and verify. Please take care when clicking links or opening attachments! When in doubt, report it using “report phishing” function.

--
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/IA0PR14MB6414964F131394F3A38950A2E3E82%40IA0PR14MB6414.namprd14.prod.outlook.com.

[Rich Smith]

Antti,

The language used in 4.2.2.2.7 was pulled directly from existing language in 3.2.2.4.

#1 was included in Ballot SC-085 which instituted the requirement to validate DNSSEC.  #2 was added by Ballot SC-096.  The only changes I’ve made to the wording of these was to remove, “…back to the IANA DNSSEC root trust anchor…,” because we’re already specifying that DNSSEC validation MUST be in accordance with the algorithm defined in RFC 4035, so that phrase doesn’t add anything, and can in fact cause confusion.

 

As far as a need for some additional clarity around these two exclusions, I don’t necessarily disagree, but I’m also afraid I don’t have much to offer, as I am not the originator of the exclusions themselves.  Perhaps the authors of SC-085 and SC-096 can weigh in.  I’m happy to adjust wording as needed to increase the understanding of these provisions, and provided Trev and Scott, as the endorsers of this ballot, agree with the suggestions which may surface.

 

Rich Smith

Sr. Director, Product Technical Excellence

 

 

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

[Henry Birge-Lee]

Hi all,

I remember being involved in several of the logging conversations when I was drafting the original DNSSEC ballot. I will refrain from providing a strict interpretation of what should or should not be logged under the current language, but I can speak a bit to the intention behind the language and the industry behavior that motivated that language.

A major goal in including that language was to avoid the interpretation that the full DNSSEC trust chain for each query must be logged. DNS resolvers often validate trust chains and then discard them to simply store that the response was DNSSEC signed in cache. Thus, typical DNS resolvers are not able to always produce a full DNSSEC trust chain when answering a query. Given that the Baseline Requirements via their references to the relevant RFCs require full trust chain validation, some argued that the interpretation would require preservation of DNSSEC trust chains which is not implemented in most DNSSEC software. This language was included to permit the operation of typical DNS resolvers that cache DNSSEC-signed results but don't store the whole chain.

The most useful element from DNSSEC validation that can be easily logged is the AD or Authenticated Data bit on DNS responses. This bit is generated by all DNSSEC-validating resolvers and indicates whether the response was backed by a fully-signed DNSSEC trust chain (AD = 1) or if unsigned DNS was used at some point to compute the response (AD = 0). For behavior related to DNSSEC, I would personally advise logging the AD bit returned by your DNSSEC-validating resolver. I believe AD bit logging was discussed with some CA/B F participants although its was not explicitly mentioned in the ballot.

The term "full set of DNS lookup information" was largely intended to refer to aggressively verbose logging like DNSSEC trust chains or full recursive DNS query patterns (e.g., dig +trace style). These logs are often not present in DNS software or meant only for debug usage. The goal was to not have the typically light logging behavior of DNS resolvers create a deployment bottleneck.

I am not against adding additional clarity on this front if participants feel that would be helpful and the current round of endorsers and authors want to go ahead with it.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/IA0PR14MB6414D5B5FC8312DAA80BBB33E3F72%40IA0PR14MB6414.namprd14.prod.outlook.com.