On Wed, Jun 11, 2025 at 02:13:38PM +0200, Joe Abley wrote: > Hi Ondrej, > > On 28 May 2025, at 14:42, Ondřej Surý <[email protected]> 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
Agree with both points Joe. Fred _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
