TCP/UDP for queries in BIND

[Kevin Darcy]

Vaishali Paithankar Sadaphal wrote:

> So I assume that both Resolver and the Name Server send queries with
> TCP only if earlier it had sent one with UDP and the response did not
> fit into one packet.

By default, yes. Through the standard resolver API, you can tell the resolver
not to retry queries that received truncated responses -- see the RES_IGNTC
option.

> But either in Name Server or in Resolver, there is no option to set it in
> TCP from beginning.

You can also set this through the standard resolver API. See the
RES_USEVC option.

> There is no point in using TCP because Resolver/Name Server works only on
> Queries and Responses.

In the normal case, there's just one query packet and one response packet.
UDP is much more efficient at that kind of thing. That's why it's the default.

> Is their any other reason for using UDP and not using TCP ?
> Doesn't it need reliability of TCP?

No, not usually. The resolver will retry a query if it times out getting a
response. Stub resolvers will also typically fail over to another nameserver, if
they are configured with more than one (which they always should be!)

> Someone was telling me that the TCP packets are given a higher priority on
> the network.

That doesn't sound right to me, but I don't usually deal with networking at that
level. I could sort of understand why UDP packets might get dropped before
TCP packets in a congestion situation (because some UDP transactions don't need
to be retried), but in the normal course of events I'd expect TCP and UDP to be
given equal priority.


- Kevin

> On Wed, 8 Aug 2001, Barry Margolin wrote:
>
> > In article <9kpq11$qr at pub3.rc.vix.com>,
> > Kevin Darcy  <kcd at daimlerchrysler.com> wrote:
> > >If you're talking about queries sent from a stub resolver to a nameserver,
> > >then it's up to the resolver whether it uses TCP or UDP. This really has
> > >nothing to do with BIND.
> >
> > BIND consists of both a resolver and a server.  Most Unix systems'
> > resolvers are derived from the BIND resolver.
>