> This note starts a Call for Adoption for > draft-thomassen-dnsop-generalized-dns-notify. > > The draft is available here: > https://datatracker.ietf.org/doc/draft-thomassen-dnsop-generalized-dns-notify/ > > Some time in the next two weeks, 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.
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?) - 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 - 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 - 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) - 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. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
