TC flag

Mark.Andrews at nominum.com Mark.Andrews at nominum.com
Fri Jun 8 00:18:02 UTC 2001


> 
> hank at interall.co.il wrote:
> 
> > Can a DNS server be informed to respond via TCP rather than UDP via  the TC
> > (truncated) flag in the reply to udp?
> 
> As the RFC states, if the answer is truncated (as indicated by the TC flag),
> the requestor should retry using TCP. The most the *server* can do is set TC;
> the rest is up to the *client*, and since the RFC says "SHOULD" rather than
> "MUST", the client has the option to just fail the query if it's truncated.
> 
> > RFC 1123 Section 6.1.3.2 states:
> >
> >     6.1.3.2  Transport Protocols
> >
> >        DNS resolvers and recursive servers MUST support UDP, and
> >        SHOULD support TCP, for sending (non-zone-transfer) queries.
> >        Specifically, a DNS resolver or server that is sending a
> >        non-zone-transfer query MUST send a UDP query first.  If the
> >        Answer section of the response is truncated and if the
> >        requester supports TCP, it SHOULD try the query again using
> >        TCP.
> >
> >        DNS servers MUST be able to service UDP queries and SHOULD
> >        be able to service TCP queries.  A name server MAY limit the
> >        resources it devotes to TCP queries, but it SHOULD NOT
> >        refuse to service a TCP query just because it would have
> >        succeeded with UDP.
> >
> > Are there any known DNS implementations that do not support the TC flag?
> 
> I'm not sure what you mean by "support". And when you say "implementations" d
> o
> you mean DNS servers or resolvers? Servers are required to set TC if the
> response doesn't fit in the packet. Any server that fails to do so is
> *broken*; it's not really a matter of "support" but rather correctness or
> brokenness. Similarly, any resolver that ignores the TC flag, treating an
> incomplete answer as a complete one, is just simply broken and needs to be
> fixed. The only "support" issue is whether the resolver opts to retry
> truncated answers using TCP or not. I'm not aware of any that don't TCP retry
> as default behavior (but this can be configurable, see for example the
> "ignore" option of "dig").
> 
> 
> - Kevin

	Well the resolver built into the BIND 4 named doesn't retry with
	TCP.  It does however discard truncated sections in the answer.

	Note this is different to the stub resolver which does retry.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com


More information about the bind-users mailing list