DNSSEC and Logging Requirements

[Martijn Katerbarg]

All, 

As I mentioned on one of the recent calls, I believe there may be some issues with the current DNSSEC requirements, and logging requirements for DCV/CAA. 

DCV/CAA logging currently is defined very broadly, essentially by (Section 5.4.1):

"All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;"

Since the DNSSEC ballot introduced a requirement to "perform DNSSEC validation using the algorithm defined in RFC 4035 Section 5”, one would need to take the stance that any DNSSEC validation itself also needs to be completely logged.  From what I’ve come to understand though, DNS resolvers don’t generally log much. It’s not their primary goal, and they’re not built for it. That means, for the full logging that is implied, we might even need to modify code of DNS resolvers. 

I’m curious to this groups opinion on this topic, both from the issuers and consumers side: Is logging this specifically for the DNSSEC verification something we want to incorporate (which I would claim it currently is), or would there be room for a carve-out of said language in Section 5.4.1, to reduce the amount of data that needs to be logged, purely to the point of showing evidence that a DNS resolver is properly configured the perform the required verifications.

Thoughts?

Regards,

Martijn

[Henry Birge-Lee]

Hi Martijn and all,

I concur that DNS resolvers are not built for extensive logging. I also will add that per DNSSEC validation behavior outlined in RFCs, DNSSEC-validating resolvers can validate DNS records, store these validated records in cache (potentially without keeping the corresponding signatures) and then serve these validated records to answer queries. Even if full logging were enabled, with an implementation like this the DNS resolver may not be able to, at time of query response, produce the full DNSSEC signature chain that was used to determine the validity of a record.

Thus, at this time, I would probably not recommend granular DNSSEC logging since many leading DNSSEC software implementations do not support this currently. I have seen some initiatives discussed to better allow DNSSEC software to produce verifiable trust chains, but I have not seen this in production personally.

The most well-established DNSSEC signal from a logging perspective is likely the AD (Authenticated Data) flag which indicates a full trust chain exists and the records returned had valid signatures. DNS error codes can also be logged and these will capture queries where DNSSEC did not validate.

Best,

Henry

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

[Ganesh Mallaya]

I think both points raised here highlight a fundamental tension between requirements language and practical implementation realities.

On the one hand, Section 5.4.1’s broad phrasing (“all verification activities”) could indeed be read to imply that every step of DNSSEC validation must be logged. If interpreted strictly, that would mean CAs need resolver-level logging of trust chains, RRSIGs, and DS/DNSKEY validations — functionality most DNS resolvers do not provide and were never designed to provide. As noted, this would require modifying core resolver code, which seems disproportionate to the intent of the requirement.

On the other hand, DNSSEC validation is already designed to provide signals of success or failure. The AD (Authenticated Data) flag is a well-established and widely supported marker that a record was validated successfully against the DNSSEC chain. Similarly, resolver error codes capture cases where DNSSEC validation fails. These signals may not provide a full forensic log of the entire validation process, but they are evidence that validation was performed correctly by a compliant resolver.

From a compliance and audit perspective, it seems reasonable to aim for evidence of DNSSEC validation having occurred, rather than exhaustive logging of every cryptographic check. A carve-out in Section 5.4.1 clarifying that logging DNSSEC verification activities may be satisfied by recording resolver signals (AD flag, error codes, resolver configuration details) would align the requirement with industry practice while avoiding unnecessary operational burdens.

This approach also creates room for improvement: if, in the future, DNS software evolves to support verifiable trust chain logging, the requirement could encourage adoption without forcing immediate changes that are impractical today.

Happy to discuss more in detail and work together to bring in the change. 

Regards,
Ganesh Mallaya

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

[Henry Birge-Lee]

Hi Ganesh Mallaya,

I agree with your points. Is this the language you are proposing to be added to Section 5.4.1:

"logging DNSSEC verification activities may be satisfied by recording resolver signals (AD flag, error codes, resolver configuration details)"

Best,

Henry

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

[Ganesh Mallaya]

Yes thats right. 

[Roman Fischer]

Does it make sense to log "resolver configuration details" with every request? How would a DNS-Client get the resolver's configuration? It would need extra access to the system where the resolver is running… that would create additional attack surface that I'm not sure is worth the risk.

 

Resolver configuration is certainly something that needs to be controlled, versioned and audited. But does it have to be in the logs with each request?

 

Rgds
Roman

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

[Michael Richardson]

'Roman Fischer' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
> Does it make sense to log "resolver configuration details" with every
> request? How would a DNS-Client get the resolver's configuration? It
> would need extra access to the system where the resolver is running…
> that would create additional attack surface that I'm not sure is worth
> the risk.

Good question.
If I were taskes with doing that, I'd build a validating recursive resolver
into my authorization system. Such as using libunbound.

> Resolver configuration is certainly something that needs to be
> controlled, versioned and audited. But does it have to be in the logs
> with each request?

Probably half of the details are already in the reply.
(CD, AD, ...), but maybe the other half is worth a new OPT RR.