Use of TCP port 53 for queries?

[Jim Reid]

>>>>> "Jim" == Jim Ault <aultj at joshua.crd.ge.com> writes:

    Jim> My question is: Under what circumstances does a client
    Jim> initiate a UDP resolver query, and under what circumstances
    Jim> does a client initiate a TCP resolver query?

Whenever the application feels like it. Broadly speaking TCP is only
-- but not exclusively! -- used for zone transfers or for dealing with
truncated responses. ie An answer is too big for a 512 byte payload so
a TCP query is made to get the rest of the data. Some applications
will use TCP by default: I think netstat does because it knows it's
going to make lots of queries to do reverse lookups. IIRC an
application that calls sethostent() with a non-zero argument will end
up using a TCP socket to talk to the name server. Some DNS tools like
nsupdate and dig can also be tools to use TCP instead of defaulting to
UDP.

    Jim> Background: We have an internal DNS server that uses two
    Jim> external DNS servers as forwarding servers for external DNS
    Jim> lookups.  We run BIND 9.1.0 on solaris 2.7 (on all our DNS
    Jim> servers), and have already configured all of our BIND servers
    Jim> to add the line

    Jim> query-source address * port 53;

    Jim> so all our queries should be coming through our firewall on
    Jim> port 53.

Well all your UDP queries should. The TCP queries will come from random,
unprivileged ports, just like the documentation says.

    Jim> If something comes in on TCP port 53 is it ALWAYS guaranteed
    Jim> to be a zone transfer?

No. It could be a TCP query. Or it could be someone typing "telnet
name-server 53". Or a port scanner. Or...
	
    Jim> If a client of the internal DNS server generates a TCP
    Jim> resolver query on a random high port, does BIND v9.1.0 keep
    Jim> the high port when it forwards the query to the external DNS
    Jim> forwarder host?

Don't know. I suspect the internal server will try to resolve the
client's query in the conventional manner by making UDP queries and
trying TCP if it gets truncated responses back from the server it
forwards to.