Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-01

[Douglas Otis <dotis@mail-abuse.org>]

On 10/30/09 10:27 AM, Alex Bligh wrote:
> --On 30 October 2009 17:38:28 +0100 "Alfred H?nes" <ah@TR-Sys.de>
> wrote:
>
> > | DNS clients SHOULD not open more than one TCP connection to a
> > single | recursive resolver or authoritative server.
> >
> > DISCUSS: SHOULD --> MUST ??
>
> If, e.g., a library stub resolver is bound to userspace program X,
> and userspace program Y, each with different users, it would be a
> sizeable amount of work to get them to share the same TCP connection.
> I don't know whether technically that's two clients running on the
> same host, or one client. However, from a caching resolver's point of
> view they are indistinguishable from 2 clients behind a NAT.
>
> I would avoid changing SHOULD to MUST on the basis that it's
> difficult to tell whether it is complied with anyway, and we don't
> want to encourage a naive server operator to limit connections to one
> per IP or something similarly horrible. Perhaps we should add "Hosts
> SHOULD attempt to minimise the number of outgoing TCP connections
> made by clients" or similar.

There is no meaningful method of enforcement against clients wanting to
obtain a greater portion of available bandwidth.  They are likely to use
multiple connections as a common strategy, which is indistinguishable
from that seen from a NAT.  How would someone ensure compliance?  Of
course, there are other transports that will not confront this issue.

This is a concern as multiple connections bring TCP sooner to resource
exhaustion. RFC 793 defines the TIME_WAIT state as 2 times the Maximum
Segment Lifetime.  The Maximum Segment Lifetime is specified as 2
minutes. RFC 1337 describes the problem TIME_WAIT is intended to avoid.
(Not just ensuring receipt of FIN acknowledgment.)

-Doug