Suspecious DNS traffic

babu dheen babudheen at
Tue Mar 26 18:49:45 UTC 2013

Dear Vernon,
Thanks for your wonderful and detailed reply. I read the update given by you as below.
>Many stateful firewalls can also record the source and destination
>IP addresses and port numbers of outgoing UDP packets and allow
>subsequent incoming UDP packets with source and destination reversed.
>This has nothing to do with TCP.
   I am using stateful firewall and still why my BIND DNS server connection iniated using source port 53 to remote DNS server on non standard destination port is getting blocked?
 Not sure why my DNS server is initiating the connection to remote DNS server on non standard destination Port?

From: Vernon Schryver <vjs at>
To: bind-users at 
Sent: Monday, 25 March 2013 8:40 PM
Subject: Re: Suspecious DNS traffic

> > Still not convinced because if i need to allow >1024 port from  our 
> > DNS server to external world(internet).. where is the security?

Every UDP and TCP packet has two port numbers, the source port and
the destination port.  When a resolver sends a request to a distant
DNS authority, it sends to destination port 53 with a random local
source port number.  When the distant resolver responds, it will
send a UDP packet with source port 53 and with destination port
equal to the source port number in the request.  If you block all
packets from port 53 to local ports other than 53, then you will
block all response to your resolver's requests.

Some DNS resolver software in ancient days sent requests to distant
authorities with source port 53, so that both the source and destination
port numbers in DNS/UDP packets were 53.  There are many reasons why
that was a bad idea.  For one modern reason, see and

Contrary to claims in this thread, that source port need not be greater
than 1024 except on some operating systems.  The notion of "privileged
ports" smaller than 1024 is an ancient "BSDism" that many consider a
mistake.  However, the source ports in DNS/UDP requests (as well as
DNS/TCP) are likely to be restricted to parts of the complete [1,65535]
range of port nubmers, but those partial ranges depend on the operating
system, operating system configuration, DNS resolver software, and the
resolvers configuration.  For TCP and stub DNS resolvers, see
For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference
Manual (ARM) including the query-source,use-v4-udp-ports, use-v6-udp-ports,
avoid-v4-udp-ports, and avoid-v6-udp-ports options.

> You send request via UDP from random high port to an authoritative server. 
>  Answer is too large to fit in UDP packet, so it responds via TCP to the 
> source port of the request (random high port from above).  If you block 
> that TCP connection, you cannot receive answer to your query.

No, a distant DNS authority certainly does not respond via TCP after
a UDP response fails to fit in a DNS/UDP packet.  Instead, the distant
authority responds with a DNS/UDP packet with the TC or "truncated"
error bit.

A resolver will react to TC bits or truncation errors by making the
same request with TCP unless it has already received the required
data from some other DNS authority.  This can happen after the local
resolver has tired of waiting for an answer from one authority and
sent the request to some other authority.

Making a request via TCP consists of sending a TCP segment (or
packet) with SYN bit sent to port 53 at the distant authority and
with yet another random source port number.  The distant authority
will respond with a TCP segment with both the SYN and ACK bits set.
The local resolver will respond with another TCP segment with both
the SYN and ACK bits set.  This is the famous "3-way handshake"
that establishes a TCP connection.  Only after the TCP connection
is established does the local resolver send the DNS request through
the TCP connection.

> Another reason for TCP replies is DNS Response Rate Limiting (RRL). 

Not exactly.

> Some "modern" stateful firewalls understand DNS and if there is a UDP 
> packet sent to port 53, it will accept TCP connections back from the 
> destination address on port 53 to the source address/port.

That is wrong.  UDP packets have nothing to do with telling reasonable
firewalls to allow TCP.

Firewalls for more than 10 years have automatically dealt with TCP
in at least two ways.  One is to notice and remember (i.e. save
state) the initial TCP SYN segment 3-way handshake and allow the
later predictaBle TCP segments.  Another mechanism is to blindly
block incoming TCP segments with SYN but without ACK.  The first
mechanism requires saving state or memory for every established TCP
connection, and so can be vulnerable to some kinds of "state
exhaustion attacks." The second mechanism prevents outsiders from
originating TCP connections, but does not protect against using the
local system for some kinds of reflection DoS attacks.

Many stateful firewalls can also record the source and destination
IP addresses and port numbers of outgoing UDP packets and allow
subsequent incoming UDP packets with source and destination reversed.
This has nothing to do with TCP.

Vernon Schryver    vjs at
Please visit to unsubscribe from this list

bind-users mailing list
bind-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list