Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-05.txt

["Wessels, Duane" <[e-mail]>]

> On Dec 2, 2019, at 9:38 PM, Puneet Sood <puneets=[e-mail]> wrote:
> 
> On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane
> <dwessels=[e-mail]> wrote:
>> 
>> Hello dnsop,
>> 
>> This draft has been updated with the following changes since -04:
>> 
>> - added DNS-over-TLS to the abstract
>> - added recent discussions about avoiding fragmentation in DNS
>> - changed "SHOULD use TFO" to "MAY use TFO" due to concerns expressed in the WG
>> - changed discussion of KSK rollover to past tense
>> - added privacy consideration text
>> - added a few new references
>> 
>> The authors would like to take this draft to working group last call.
> 
> General comment: I do not see much discussion of this draft on the
> list (https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-dnsop-dns-tcp-requirements%22),
> The longest thread is about the semantics of DNS flag days and their
> (lack of) benefit. Personally I find the appendix very useful since it
> pulls together all relevant RFCs.

Thanks for the feedback.

> 
> Specific comments below.
> 
> COMMENT: Section 5.1 DNS Wedgie
> This is an issue for a resolver. Could we add a recommendation to
> section 4.2 "Connection Management" for resolvers to handle this
> better?
> Something along the lines of "A resolver MAY want to track and limit
> the number of TCP connections it opens to a single nameserver.".

I agree this was missing.  Since this is about establishing connections, I
updated the title of section 4.1 and added this new paragraph:

4.1.  Connection Establishment and Admission

   Resolvers and other DNS clients should be aware that some servers
   might not be reachable over TCP.  For this reason, clients MAY want
   to track and limit the number of TCP connections and connection
   attempts to a single server.  Additionally, DNS clients MAY want to
   enforce a short timeout on unestablished connections, rather than
   rely on the host operating system's TCP connection timeout, which is
   often around 60-120 seconds.


> COMMENT: Section 5.3 DNS-over-TLS seems out of place in section 5. It
> would fit better in section 4. Network and System Considerations.

Moved.

> 
> COMMENT: Section 6 Logging and Monitoring
> Use some SHOULD keywords to make the recommendations stronger.

Done.

   Developers of applications that log or monitor DNS SHOULD NOT ignore
   TCP due to the perception that it is rarely used or is hard to
   process.  Operators SHOULD ensure that their monitoring and logging
   applications properly capture DNS message over TCP.  Otherwise,
   attacks, exfiltration attempts, and normal traffic may go undetected.

   DNS messages over TCP are in no way guaranteed to arrive in single
   segments.  In fact, a clever attacker might attempt to hide certain
   messages by forcing them over very small TCP segments.  Applications
   that capture network packets (e.g., with libpcap [libpcap]) SHOULD be
   prepared to implement and perform full TCP segment reassembly.
   dnscap [dnscap] is an open-source example of a DNS logging program
   that implements TCP reassembly.

   Developers SHOULD also keep in mind connection reuse, query
   pipelining, and out-of-order responses when building and testing DNS
   monitoring applications.


DW