> On Dec 2, 2019, at 9:38 PM, Puneet Sood <[email protected]> > wrote: > > On Sat, Nov 2, 2019 at 2:18 PM Wessels, Duane > <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
