TCP support in clients and servers

[Barry Margolin]

In article <gq66ml$2dpe$1 at sf1.isc.org>, grarpamp <grarpamp at gmail.com> 
wrote:

> Given:
>  A research or production network that only supports TCP. Think:
>   I2P, Tor, GNUnet, FreeNet, etc.
>   Corporate/organizational policies/firewalls, etc.
>   Other seemingly odd, broken or interesting special case environments,
>    easier tunneling/encapsulation and so on.
> 
> Supposing:
>  Named(8) seems to bind to TCP and responds when using dig +tcp as
>   a client.
>  No need for the typical reasons to use UDP; performance, etc.
> 
> Questions:
>  Does named fully support operating over only TCP as a server?
>   zone transfers, resolving names for clients, nsupdate, etc.

I'm pretty sure it does.  Note, however, that even though the server may 
receive a query on TCP, it will still use UDP first for the outgoing 
request if it needs to recurse.

>  How to configure client resolver libraries to use TCP?
>   Things like resolv.conf, host.conf, nsswitch.conf don't seem
>   capable of this. Nor do the underlying calls.

Correct.  Libresolv allows you to specify that TCP should be used 
(that's how dig +vc works), but none of the higher-level APIs, or 
daemons like nscd, do.

>  Are not client resolver libraries usually derived from bind?
> 
>  What would be needed for both client and server to fully support
>   a TCP only mode of operation?

Edit the code.

>  Is this a planned feature in the future? Any active work?

I can't imagine anyone has given much thought to this before.  The DNS 
RFC's say that UDP MUST be tried first for everything other than zone 
transfers, and TCP is only used as a fallback if the response is 
truncated.  And the reasons for truncation have been obviated by EDNS0, 
so the general expectation is that there should be LESS use of TCP these 
days.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***