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

[Peter Thomassen <[e-mail]>]

Hi Joe,

On 6/12/25 04:22, Brian Dickson wrote:
>> 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 idea is really to do a plausibility check, not to rule out things that can't be ruled out. In other words, it's not about being sure that all is fine; it's about acting reasonably when there is an indication of a problem.

I suspect that there are many cases where errors could happen because the synchronization was not properly done (see the cases in the various Appendixes), and not because some anycast nodes are lagging.

Of course, that can happen, too. In combination with the advice in draft-ietf-dnsop-generalized-notify (in RFC ed queue) that operators not send notifications to the parent "until all publicly visible copies of the zone are updated", the parent's consistency check actually is suitable to (mostly) trigger when an operator actually has made a mistake.

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

I completely agree, but it is likely there will be failures around that sync, when one provider doesn't not properly honor the state machine and proceeds early to the next step. The draft acknowledges such (and other) scenarios in A.3.

Historically, there has been no shortage of DNSSEC-induced outages from early moves during (manual?) key rollovers and such, and I'm pretty sure that multi-provider synchronization implementations will not be immune to such bugs. These situations should lead to the update not being applied, instead of the wrong update being applied and more outages happening (and another round of avoidable DNSSEC reputational loss ensuing).

On 6/12/25 08:10, Joe Abley wrote:
> In this case the duct tape is only being applied in places that are feeling the consequence of forgetting the contract; the consequences of ignoring the contract are largely self-inflicted and not shared with other innocent bystanders.

I'm not sure I agree with that: if a domain goes bogus because of a bad DS update, then users of that domain are also affected, even though they are innocent bystanders.

> This is why I think this proposal overall does no great harm and I think it's ok to publish.

Ah great! Thank you for reading (and commenting!) anyway. :-p

Best,
Peter