> On Apr 19, 2021, at 8:45 AM, Tony Finch <d...@dotat.at> wrote: > > Suzanne Woolf <suzworldw...@gmail.com> wrote: >> >> This message starts the Working Group Last Call for >> draft-ietf-dnsop-tcp-requirements > > I have read the draft and I am keen to see it published. Just the other > day I was having a discussion about whether TCP support is really needed, > and I wanted something stronger than RFC 7766 to point to. > > The draft is readable and comprehensive. I like it. > > Some minor and pedantic nits: > > 2.2: > > DNSSEC originally specified in [RFC2541] > > I thought this should be RFC 2535 rather than the operational guidelines?
Sure, 2535 works for me. > > 2.3: > > This unsigned 16-bit field specifies, in bytes, the maximum > (possibly fragmented) DNS message size a node is capable of > receiving. > > I suggest adding "over UDP" to the end of the sentence (since the EDNS > buffer size doesn't restrict messages over other transports). Done. > > 2.4: > > Last 2 paragraph s re. avoiding fragmentation, it might be worth > suggesting minimal-any [RFC 8482]. I did add 8482 to the Appendix as you also suggested below. I'm a little reluctant to add a reference in section 2.4 since I think the primary motivation for 8482 was about DDoS amplification, rather than fragmentation. But I could still be convinced otherwise. > > 4.3: > > the Linux kernel provides a number of "sysctl" parameters related to > TIME_WAIT, such as net.ipv4.tcp_fin_timeout, net.ipv4.tcp_tw_recycle, > and net.ipv4.tcp_tw_reuse. > > I believe that net.ipv4.tcp_tw_recycle is problematic and has been removed > https://secure-web.cisco.com/1zq_T2G9VjiDGyCD0UqiwfZ7i0Jc_JcoiRaUvHdWj_Nfh6pjxxQygRKERClmruWq9Yie54GznGNn-TR0ijjBYdidyWjP-mbPF5EWAwdDtalD86OTC3Z--zQWHcwkJtpdtD_iHBJqo4tRAddX5cQM8cJpMFTDMKKcXx-upQpjW14N1FwLeCniHz9apzZbWcIvZ_xlx3UDB4cvVJmNXzOZni24brGiihUnUPzUOipM8mAlwkq7ZuVgFJYRfKCc4DjCjiBYP9m5stLbRNYinc72Nlw/https%3A%2F%2Fvincent.bernat.ch%2Fen%2Fblog%2F2014-tcp-time-wait-state-linux%23netipv4tcp_tw_recycle I removed tcp_tw_recycle. > > 4.4: > > Although DNS-over-TLS utilizes TCP port > 853 instead of port 53, this document applies equally well to DNS- > over-TLS. > > Um, how much of this document applies to DoT? Just the tuning advice, or > the requirement that TLS MUST be supported like TCP MUST be? > > 5: > > re "DDoS mitigation techniques" would it be worth citing DNS RRL here as > well as in section 9? Hows this? message sizes, lack of EDNS(0) support, DDoS mitigation techniques (including [RRL]), or perhaps some future capability that is as yet > > 10: > > Since DNS over both UDP and TCP use the same underlying message > format, the use of one transport instead of the other does change the > privacy characteristics of the message content > > Missing "not"? Yes indeed. > > A: > > Should RFC 2136 UPDATE be mentioned? (sections 2.1, 6.2, 7.8, 7.9) TBH I'm > not sure how much UDP is used, but I certainly rely on 60+ KB updates. I probably don't have enough direct experience with UPDATE to say. If it is largely over TCP then I think it should be included. > > Also RFC 8482 section 4.4 talks about possible different behaviour for ANY > queries over UDP compared to TCP. RFC 8482 has been added to the appendix. > > A.8: > > [RFC3226] strongly argued in favor of UDP messages over TCP largely > > I had to read this twice! How about "instead of" instead of "over"? yes, agreed. > > A.14: > > I think there should be a note that RFC 5966 has been obsoleted by RFC > 7766, with a cross-reference to A.21. Done. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
