Hi Patrick, Thanks for your feedback.
> On 20 Sep 2023, at 23:12, pmev...@godaddy.com > <pmevzek=40godaddy....@dmarc.ietf.org> wrote: > The need of faster convergence is clear, so a specification catering for that > is a good thing to have, and I support adoption by DNSOP working group. > > I will probably not be able to contribute a lot, but reading it make me think > of the following points: > - I didn't see discussion about the possible return codes for the NOTIFY > message, and in which case which DNS error code would happen and what would > it mean (or is §3.12 of RFC1996 enough?) Peter and I discussed this issue quite some time ago, but then decided not to make the initial draft more complex and rather defer such discussions until after the draft was adopted. Which is now :-) > - maybe I missed it but didn't find clear indications that the NOTIFY message > should (or should not) be with ANCOUNT>0 and the answer section having the > relevant records to sync, or in contrary forbidding this to force retrieval > by usual DNS queries enforced by DNSSEC protections I agree with Peters response: the records in the NOTIFY message are not to be used other than as a hint for doing the normal scan of the child zone, but now rather than later. > - SRV instead of new record type is discussed in §9.1 but then rejected: was > SVCB discussed? I think it could be used without having to override anything, > as you can write a proper profile for it (as HTTPS does), and have more > SvcParamKeys SVCB was not discussed. This is my fault, simply not thinking about it. Thanks for reminding me! I agree with your conclusion that SVCB could be used without any overrides. That said, I would be inclined to still argue for a dedicated RR type rather than using SVCB. My reason is that for this use case (generalised notifications), the consumer of the data is typically a name server (the child primary most likely, at the same time it is hatching a new CDS or CSYNC). I.e. the consumer is not some arbitrary application, but rather a part of the DNS infrastructure itself, and then not having to potentially wade through other SVCB RRs at the apex of the parent would seem to be a cleaner solution. But, as the document is now adopted by the working group this is clearly not for me to decide but rather the subject for future discussion. We’ll take this issue with us to Prague unless it gets hashed out on the mailing list before that. > - it is a different use case, but the same mechanism could be useful in > another case, so even if not discussed in the draft, maybe having it in mind > could allow to easily work on it later: instead of manual/web based way to > ask recursive resolvers to flush a given (name, rdtype) entry (because of > some emergency switch wanted), use some kind of NOTIFY to send that signal > (with of course the problem of authenticating the source, but it is similar > for CDS/CDNSKEY and in part discussed in §11) I agree that there are more use cases for generalised notifications than speeding up CDS/CSYNC detection. The multi-signer use case that is mentioned in the draft is another. > - while not creating an amplification problem, I think some explanations > should be given around the case of some attacker trying to disrupt by sending > lots of notify, which can be rate-limited or ignored, but my worries is if > the notify receiver then just decides to "ignore" all notifies for a given > zone (not taking into account emitter IPs, or just seeing too many of them), > which would then prevent the real owner to send notify, or more precisely to > make them worth. Of course nothing breaks but convergence may then go back to > slower agenda, which means the attacker succeeded somehow to disrupt the real > owner operations. I agree in principle, but argue that as no child zone may reasonably have a need to send large numbers of these notifications rapidly a standard and restrictive RRL configuration would work very well to alleviate any such problems. Regards, Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
