Hi Patrick, On 9/20/23 23:12, [email protected] wrote:
I will probably not be able to contribute a lot, but reading it make me think of the following points:
Thank you very much for your feedback; even if you don't feel able to contribute a lot, that's VERY helpful :)
- 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?)
Good point. I'm not sure if doing anything beyond that would add any reliable benefit, as the return code cannot be signed. For example, if one would specify REFUSED for when a parent-side rate limit is exceeded, an suitable attacker could trick the child into thinking that a DS rollover cannot currently be triggered, which may mislead the child about what to do next. Perhaps it's better to not send such signals, and rather have the child determine its next steps by assessing the actual situation (i.e., observing which DS records are deployed etc.). It would be interesting to learn what you think about this. This is tracked at https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/11.
- 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
Section 4 says: [...] Upon receipt of NOTIFY(CDS), the parent SHOULD initiate the same scan that would otherwise be triggered based on a timer. In other words, records provided in the NOTIFY message are not to be used. Some more thoughts on this topic are here: https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/13
- 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
I'm deferring to Johan.
- 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)
Neat idea! I think this needs some input from resolver people.
- 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.
Yes. Some extra thoughts are here: https://github.com/peterthomassen/draft-thomassen-dnsop-generalized-dns-notify/issues/17#issuecomment-1513789295 Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
