[secdir] Secdir review of draft-ietf-dnsop-dns-tcp-requirements-12

[Alan DeKok <[e-mail]>]

Reviewer: Alan DeKok
Review result: Has nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  Over all, I think this document is clear, useful and well written.

Section 1 says:

   ... Section 6.1.3.2 to clarify that all DNS resolvers and recursive MUST
   support and service both TCP and UDP queries.

NIT: bare "recursive" should perhaps be "recursive servers", to match similar text elsewhere in the document.


  It may be good to update Section 3 with notes on "head of line blocking".  This text could arguably be in RFC 7766, but having it here is a reasonable alternative:

   When using UDP as a transport for DNS, there is no ordering of
   packets.  If a packet is lost, that loss has no
   effect on subsequent packets sent by that client or server.

   Unlike UDP, TCP is subject to issues related to Head of Line (HoL)
   blocking.  This occurs when a TCP segment is lost and a subsequent
   TCP segment arrives out of order.  While the DNS implementation can
   process DNS packets out of order, the semantics of TCP makes this
   impossible.  This limitation can lower the maximum packet processing
   rate of DNS over TCP.


Section 6 says:

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

  It would also be good to note that if the monitoring software tracks requests and responses, then clients could potentially attack the monitoring software, too.  i.e. by sending large volumes of requests to "black hole" IPs, which will never get a response.   So the monitoring software should have both timeouts for request/response tracking, and also limit the total number of request/responses which are monitored.