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

[Brian Dickson <[e-mail]>]

Hi Joe, 
(Response below or in-line or both…)
Sent from my iPhone

> On Jun 11, 2025, at 5:14 AM, Joe Abley <jabley=[e-mail]> wrote:
> 
> 
> 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 think a balanced reading of the advice, which might depend on favorable interpretation of semantics and definitions, can be actionable and an improvement.

I think this boils down to looking at signatures as “proof of possession” and also as an authoritative indication of intent.

The (IMHO) reasonable expectation regarding these specific record types is that they SHOULD be consistent across an anycast set. This reading of the recommendations reduces the required queries to one per unique server name/address, without weakening the logic or the security model(s) involved.

The presence of multiple signers implies multiple operators, and a trust boundary that requires a “trust but verify” approach to preserve the trust model (where the authorization properly belongs to the registrant, notwithstanding the involvement of additional parties).

> 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.
> 

Unfortunately, the automation involved prevents the ability to distinguish between innocent errors and malicious activity, particularly from an otherwise trusted participant. I would expect this present document to create enough of a protection to dissuade such activity by anyone not possessing sufficient resources to successfully use brute force to defeat the encryption involved.

Sincerely,
Brian

> 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
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]