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

From: Puneet Sood <[email-masked]>
Date: Tue, 3 Dec 2019 00:38:25 -0500

On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane
<dwessels=[email-masked]> 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.

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.".

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.

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

Thanks,
Puneet

>
> DW
>
>
> > On Nov 2, 2019, at 1:08 PM, [email-masked] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Domain Name System Operations WG of the IETF.
> >
> >        Title           : DNS Transport over TCP - Operational Requirements
> >        Authors         : John Kristoff
> >                          Duane Wessels
> >       Filename        : draft-ietf-dnsop-dns-tcp-requirements-05.txt
> >       Pages           : 26
> >       Date            : 2019-11-02
> >
> > Abstract:
> >   This document encourages the practice of permitting DNS messages to
> >   be carried over TCP on the Internet.  This includes both DNS over
> >   unencrypted TCP, as well as over an encrypted TLS session.  The
> >   document also considers the consequences with this form of DNS
> >   communication and the potential operational issues that can arise
> >   when this best common practice is not upheld.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-dns-tcp-requirements-05
> > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-tcp-requirements-05
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-tcp-requirements-05
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > DNSOP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 4 Dec 2019 22:22:41 +0000

> On Dec 2, 2019, at 9:38 PM, Puneet Sood <puneets=[email-masked]> wrote:
> 

Thanks for the feedback.

> 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.

> would fit better in section 4. Network and System Considerations.

Moved.

> 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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 4 Dec 2019 16:05:16 -0800

Wessels, Duane wrote on 2019-12-04 14:22:
> ...

i suggest a reference to 'dnstap' here, as a server-integrated 
monitoring protocol intended to facilitate wide scale dns monitoring.

-- 
P Vixie

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 5 Dec 2019 00:49:11 +0000

> On Dec 4, 2019, at 4:05 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> i suggest a reference to 'dnstap' here, as a server-integrated monitoring protocol intended to facilitate wide scale dns monitoring.

Done:

   As an alternative to packet capture, some DNS server software
   supports dnstap [dnstap] as an integrated monitoring protocol
   intended to facilitate wide-scale DNS monitoring.

DW