> 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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to