Suspecious DNS traffic

Mark Elkins mje at posix.co.za
Tue Mar 26 19:39:21 UTC 2013


Maybe I can try.

In the very old days - when BIND as a recursive resolver was chasing
down an answer to a question, it would sent the remote authoritative DNS
server the query in a UDP packet which has a query ID which was numbered
sequentially.

This was bad as bad people could guess your next query ID and send back
their own answers.

Then BIND randomised this 16 bit query ID which made it more difficult.
Tie that in with a reasonable TTL, so answers are cached - and the world
was a better place. We asked and received answers all on port 53.

Then Dan Kaminsky (actually a good guy) discovers a protocol weakness
which somewhat negated the effectiveness of the randomness of the 16 bit
query ID. The short term solution for this is to add some more
randomness in the query. A resolving name-server will now ask an
authoritative server on port 53 but will ask from an almost random port.
The Answer has to come back from port 53 but to the same random port and
obviously with the same Query ID (or maybe ports are the other way
around?)

You can by configuration restrict or even remove this extra randomness -
but it makes it easier for bad people to pollute your cache with bad
answers.

The Security Solution is to run DNSSEC - ie Sign all your own zones and
to use DNSSEC recursive resolvers. You'll then ignore bad answers.

If I start 'named' with the '-g' option - I get:
26-Mar-2013 ... using default UDP/IPv4 port range: [1024, 65535]
26-Mar-2013 ... listening on IPv4 interface lo, 127.0.0.1#53

I believe this is BIND telling me its intending to use from port 1024 to
port 65535 as the local source of queries. This is a Good Thing.

Your Firewall could be configured to allow BIND to do this.

One alternative is to lock BIND and the Firewall to only allow port 53
queries and have them all forwarded to a recursive name-server on the
outside of your firewall. If I sell machines - I think this is a great
solution (I sell more machines).

Don't restrict the Randomness that Queries can use. Even with DNSSEC -
the majority of the Internet's DNS is not yet signed.

If my explanation is not quite right - I'm pretty sure its at least in
the right direction.

On Wed, 2013-03-27 at 02:40 +0800, babu dheen wrote:
> Dear Matus,
>  
> I think you got my point. Yes. I am using Stateful Firewall and not
> sure my DNS server connecting to remote DNS  on non standard port?
>  
> So where i need to now look?
>  
> Regards
> Papdheen M
> 
> 
> 
> From: Matus UHLAR - fantomas <uhlar at fantomas.sk>
> To: bind-users at lists.isc.org 
> Sent: Monday, 25 March 2013 7:46 PM
> Subject: Re: Suspecious DNS traffic
> 
> 
> On 26.03.13 00:21, babu dheen wrote:
> >Hi Matus,
> 
> please, skip personal replies. this is mailing list and issued should
> be
> discussed here.
> 
> >Still not convinced because if i need to allow >1024 port from  our
> DNS
> > server to external world(internet)..  where is the security?
> 
> If you have statefull firewall, you simply need to allow "open"
> connections
> (statefull firewalls can track outgoing UDP packets and match the
> replies).
> If not, you have to allow all traffic from port 53 on remote DNS
> servers to
> your DNS server. Since you can't know all DNS servers, you have to
> allow all
> incoming traffic to your DNS server where source port is 53.
> 
> all the "security" is useless if blocks your service. Luckily, most of
> firewalls can track the "connection" state.
> -- 
> Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/


-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6147 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130326/611b66cf/attachment.bin>


More information about the bind-users mailing list