Hi, here are my comments to draft-thomassen-dnsop-cds-consistency-03.
"In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set."
I don't feel confident about the consequences of this cathegorical statement. What if you have two DNSSEC providers, one has an outage (or just network breakage between them and the polling entity), and the other one maliciously takes over by publishing new CDNSKEYs? The polling entity might re-query several times from different locations, but this is usually only performed when bootstrapping the scure delegation, not when already established. And even if, it's not clear if (when) this would be enough. I understand, on the other hand, that relying on permanently disfunctional (or lame in any meaning of that word) child NSs might be problematic. To sum this up, if this is an issue in the proposed method, it should be fixed, and if it isn't, it should be more verbosely described why. The document seems too brief in this regard.
"CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC validation enforced."
Isn't this sentence disabling secure delegation bootstrapping? Thanks, Libor Dne 21. 06. 23 v 15:52 Tim Wicinski napsal(a):
AllThe call for adoption period for this draft wrapped up this morning. While we saw several strong comments and issues raised, we also saw the working group wishing to adopt this work and working on it. We consider this passed. Thanks all, and we will work with the authors to itemize the list of larger issuesthanks tim On Wed, Jun 7, 2023 at 11:52 AM Tim Wicinski <tjw.i...@gmail.com> wrote: All, We've had this document in DNSOP for a bit and Peter has presented three different meetings. When I went back and looked at the minutes, the feedback was good. But when the chairs and Warren discussed it, we had confused ourselves on this document, which is our bad. We decided to stop confusing ourselves and let the working group help us out. What I did was to pull the comments on this document from the minutes of the meetings and include them below to make it easier to remember what was said. This starts a Call for Adoption for draft-thomassen-dnsop-cds-consistency The draft is available here: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and send any comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 21 June 2023 Thanks, tim wicinski For DNSOP co-chairs Minutes from past meetings on "Consistency for CDS/CDNSKEY and CSYNC is Mandatory" ---- 114 Mark: CDS records are no different than any others One NS might be down, which would stop the Peter: This is telling the parent how to act when faced with inconsistent information Viktor: There might be hidden masters Don't want to get stuck Peter: Wording could be changed to allow servers down Ben: There is a missing time constant When do I recheck if I get an inconsistent set? Peter: 7344 doesn't put any time limit Ben: Should suggest some time to retry when there is an inconstancy 115 Wes: Supports this Likes mandating checking everywhere Ralf: Supports this Can't ask "all" servers in anycast What if you don't get a response Peter: Ask each provider Is willing to add in wording about non responses Paul Wouters: This wasn't in CSYNC, our bug Viktor: Concern was hidden masters and nameservers that are gone and are never going to come back 116 Viktor: Corner case: if someone is moving to a host that doesn't do DNSSEC Peter: Could add a way to turn off DNSSEC on transfer Johan Stenstram: Breaks the logic that "if it is signed, it is good" Doesn't like "if this is really important" Let's not go there Authoritative servers are proxies for the registrant Out of sync is reflection on the registrant: business issues Wes: CSYNC was for keeping DNS up and running CSYNC can't fix the business problems Peter: Agrees that one signature should be OK Other parts of the spec also suggest asking multiple places _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
