[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-cds-consistency

[Joe Abley <[e-mail]>]

Hi Ondrej,

On 28 May 2025, at 14:42, Ondřej Surý <[e-mail]> wrote:

> this starts a Working Group Last Call for draft-ietf-dnsop-cds-consistency
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-cds-consistency/
> 
> The Current Intended Status of this document is: Proposed Standard

I don't think the recommendations in the document will do any harm, and some people think they are useful, so I think it is fine to publish this advice. However, I do have some reservations, about which I am happy to be told why I am wrong.

The core advice:

   This document therefore specifies that parent-side entities MUST
   ensure that the updates indicated by CDS/CDNSKEY and CSYNC record
   sets are consistent across all of the child's authoritative
   nameservers, before taking any action based on these records.

is, in general, not actionable. The full set of authority servers for a zone are frequently not available from a single vantage point, since a single nameserver address often maps to many different individual servers which may or may not serve consistent information (e.g. when an individual NS target is deployed using anycast in one or more address families). Depending on how you count them, most nameservers are anycast, so I think it could be said that this is not a niche observation. The revised advice might boil down to "instead of just looking for an answer as a stub resolver would, look at a random two out of 100,000 possible authoritative servers" and I'm not convinced that is much of an improvement.

I am also not very convinced that incoherence between authoritative servers or the effects of caching are good reasons to do this. I can see how there are failure modes where those effects could be unhelpful, but there are always more failure modes and sometimes I think a failure should just be a failure and the greater mission  is not actually helped by the application of yet more duct tape.

With respect to multi-signer configurations, I think the right way to solve that is to sync CDS and CDNSKEY between participating signers just as the corresponding DNSKEY RRs are synced. This seems like a solution that is more effectively aligned with the problem; to put it another way, multi-signer implementations would be more robust if they didn't have to make assumptions about whether the polling advice in this document was followed or not.


Joe