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

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

> On Aug 27, 2021, at 1:28 PM, Alan DeKok <[e-mail]> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> Reviewer: Alan DeKok
> Review result: Has nits

Thanks for the review Alan.

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

Yep, I'll make that change.

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

Can you clarify by what you mean with "While the DNS implementation can
process DNS packets out of order, the semantics of TCP makes this impossible."
Do you mean in the case of a lost TCP segment, or in general?

I wonder if this might fit equally well under a new 2.x subsection.




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


Yes, thats a good point.  I will come up with some text for that.

DW