Regarding the suitability of SVCB, note that SVCB requires a registered URI scheme. If you are willing to adopt a mental model that includes URIs like "dns-notify://ns1.example.com/..." then it might be usable; otherwise not.
Also, SVCB is designed primarily for bootstrapping authenticated transports. If the transport is not authenticated, the mapping would have to explain the threat model and security implications. A relevant example is the SVCB mapping for DNS, which contains special recommendations to avoid downgrade attacks (https://www.ietf.org/archive/id/draft-ietf-add-svcb-dns-09.html#name-adversary-on-the-transport-). --Ben Schwartz ________________________________ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Peter Thomassen <pe...@desec.io> Sent: Sunday, September 24, 2023 6:24 AM To: pmev...@godaddy.com <pmevzek=40godaddy....@dmarc.ietf.org>; dnsop@ietf.org <dnsop@ietf.org> Subject: Re: [DNSOP] Call for Adoption: draft-thomassen-dnsop-generalized-dns-notify !-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! Hi Patrick, On 9/20/23 23:12, pmev...@godaddy.com 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
