Suspecious DNS traffic

Tue Mar 26 19:09:05 UTC 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It sounds like exactly the reverse of what Niall described in his
other e-mail (brackets mine):

"The reply to such a query originates from port 53 on the remote
server [in this case, your server], and is destined for the port on
your server [in this case, the remote server] which was used as the
source of the query [which will, again, almost certainly be a random
port above 1024, but the same port the request just came in from to
your port 53]."

Why your firewall is confused about this is anyone's guess. I'd check
with them.

On 03/26/2013 02:50 PM, babu dheen wrote:
> 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?
> 
> Regards Babu
> 
> 
> 
> *From:* Vernon Schryver <vjs at rhyolite.com> *To:*
> bind-users at lists.isc.org *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 
> https://www.google.com/search?q=cache+poisoning+attack and 
> https://www.google.com/search?q=dns+source+port+randomization
> 
> 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 
> https://www.google.com/search?q=ephemeral+port 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 rhyolite.com <mailto:vjs at rhyolite.com> 
> _______________________________________________ Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> 
> bind-users mailing list bind-users at lists.isc.org
> <mailto:bind-users at lists.isc.org> 
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 

- -- 
- ---- _  _ _  _ ___  _  _  _
|Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFR8lIACgkQmb+gadEcsb4B7QCg2f64+sltIkM6KzHV13+pFCR0
+7sAn3J/sEWHigF8MbC4+RCfowfkfyWQ
=YMnI
-----END PGP SIGNATURE-----