[e2e] [unclassified] TCP improved closing strategies?

[William Allen Simpson]

Dan McDonald wrote:
> On Wed, Aug 12, 2009 at 09:14:54PM -0400, David P. Reed wrote:
>> I'm not sure whether it wouldn't be better to think through a non-TCP 
>> solution here.  TCP is incredibly heavy duty for the purpose of doing a 
>> properly "secure" DNS transaction, which ultimately involves a single 
>> request-response in the most common case.
>>
>> And if you do, there is no reason why the server needs to maintain 
>> *connection* state at all - connections are for long term interactions.
>>
>> Am I missing something here?
> 
> I thought (and I'm not SecureDNS wizard) that SecureDNS packets often exceed
> PathMTU for most of the Internet, and that you wanted segmentation *and*
> retransmission covered.
> 
Dan is correct.  At least, *I'm* not aware of paths with greater than 4K.
Heck, most paths are 1,500 at best, and 1,460 is common.

Worse, it turns out that 4K doesn't work well, either.  The EDNS0 default
is 4K; the DNS UDP packets fragment, and the SOHO firewalls and/or NATs
drop the fragments.  UDP is only good for data less than 1,420 at most.

Steve Crocker has a clever draft to allow the user query to limit the
algorithms requested, but that only works for end systems.  Caching
servers still need something more -- a lot of SOHO boxen also act as
caching servers, and most every ISP these days designates one or more
caching servers in its DHCP.  That's a lot of servers.

I've got another proposed option to calculate the size of the remaining
(post-truncation) response, by RRType.  That will allow a caching server
to make subsequent UDP queries for each RRType, for a complete cache.

Mine also will indicate whether UDP is hopeless, and TCP *has* to be used;
when the total response for any single RRType will be greater than 1,420.

Both those proposed UDP EDNS0 options will help lower the number of TCP
requests, but neither can be *required* to be implemented.  So, we still
need to handle the existing problem -- a problem that has been known for
many years, but no solution has yet been standardized.

It's time to bite the bullet.  Sadly, there's no TCPng, and it's too late
for that to help now.

Remember, most network appliances won't be upgraded.  The only remaining
possibilities are vanilla UDP and vanilla TCP.