On Fri, Feb 14, 2025 at 10:12 AM Éric Vyncke via Datatracker < [email protected]> wrote:
> Éric Vyncke has entered the following ballot position for > draft-ietf-dnsop-compact-denial-of-existence-06: Yes > Thank you for your review Éric. > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Suzanne Woolf for the shepherd's detailed write-up > including > the WG consensus *and* the justification of the intended status. > > Other thanks to Antoine Fressancourt, the Internet directorate reviewer > (at my > request), and I have read Shumon's reply: > > https://datatracker.ietf.org/doc/review-ietf-dnsop-compact-denial-of-existence-06-intdir-telechat-fressancourt-2025-02-10/ > > Other thanks to Patrick Mevzek , the DNS directorate reviewer, and I have > read > Shumon's reply: > > https://datatracker.ietf.org/doc/review-ietf-dnsop-compact-denial-of-existence-06-dnsdir-telechat-mevzek-2025-02-02/ > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS (non-blocking) > > ### Section 3.5 > > Please expand `EDE` at first use. > The expanded form (alone) appears in the paragraph immediately preceding it. I will add a parenthetical "(EDE)" after it to address your comment. ### Section 4 > > Should there be a normative reference to base32 ? > The sentence it appears in is copied verbatim from the NSEC3 RFC (RFC 5155, Section 3), and since RFC5155 is already referred to earlier, I didn't feel strongly that we need another reference, but we could. In looking at the sentence again though, I think it is not precise enough - it should clearly state that it is base32hex, or (base32 with extended hex alphabet). We could make that change and reference RFC 4648, Section 7. > ### Section 5.1 > > A nice and smart trick ;-) > I feel it is compensating for a trick, but semantics :) ### Section 6 > > This section is about the drawback of the proposed system... While the > section > is clear and the technique appears to work fine in real life, I cannot > refrain > from wondering what will happen when DNSSEC is more widespread and with > HAPPY > WG probably requesting first SVCB, then AAAA, and finally A (i.e., 3 RR in > a > row). > This is an excellent point. Although, the draft states that an NXDOMAIN response would have immediately suppressed follow-on queries for other record types at the same name, my subsequent inspection of some popular name resolution functions has shown that a lot of them don't in real life do this. And yes, most Happy Eyeballs implementations in particular will not wait for an NXDOMAIN to decide to query other record types, since they will parallelize and race all the queries. It might be worth noting this. I will ponder some text ... ### Section 8 > > Section 1 includes `The use of minimally covering NSEC or NSEC3 records > also > prevents adversaries from enumerating the entire contents of DNS zones by > walking the NSEC chain,`, this is really important in IPv6 world as > enumerating > DNS is faster than enumerating a /64. I.e., suggest adding this positive > consideration in the security section. > Ok, we'll ponder this too and try to come up with some text. ### Appendix B > > While this appendix helps the reader to assert the feasibility, it lacks > references, i.e., how can the authors/WG/IETF assert this statement? > Because the authors (and others) were involved in those implementations :) Our motivation for including this section is to document what precursor methods were actually deployed in the field. This is useful as a reference for anyone looking at past DNS query/response data or code in understanding what was going on. As for references, we could (if necessary) include links to posts on DNS operations mailing lists, where a lot of this was announced and discussed. Shumon.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
