[unisog] DNS over TCP should we block

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Wed Jan 5 06:18:47 GMT 2005


(merging several replies here...)

On Tue, 04 Jan 2005 16:39:30 EST, Reg Quinton said:
> IMHO there's no need for anyone other than our campus DNS servers to conduct 
> DNS conversations with remote systems.

You've obviously never had to use 'dig @remote.server' to  figure out which NS
entry for some other site is busticated so you can tell them to fix their
system, or figure out if you have stale data cached in *your* server. It's
amazing how many places botch lowering the TTL on a DNS entry preparing for a
change.  Rather than have a usual 3D value, drop that to 1D 4 days before, then
down to 4H 2 days before, etc, they drop the TTL from 3D to 1H just 3 hours
before the change goes live, and then wonder why things are hitting the old
address for another 3 days....

On Tue, 04 Jan 2005 17:05:07 EST, Vijay S Sarvepalli VSSARVEP said:

> 1) Our dns records have never needed a virtual circuit (this means most 
> replies to queries have been small enough) - if it is not needed why allow 
> it is my first thought

OK. Fine. Your network, your rules.  Just remember that you *won't* be
thinking "Oh yeah, TCP/53" when the NOC opens a ticket at 2AM when something breaks. ;)

(This is a *predictable* failure mode - I can't see why anybody would want to
put the bullet in the chamber, point it at their foot, and wait for the trigger
to get pulled....)

> 2) Zone transfer is already denied by default with "allow-transfer { none; 
> };" and specific allow statements for each zone.  Zone transfer is NOT the 
> threat being addressed.  There is also TSIG option for this. 

These are, in fact, the correct way to deal with the zone-transfer issue.

> 3)  DOS attack on TCP port 53.

This is the only other threat I can think of offhand - but again, this is
better addressed other ways.  If you're using Linux iptables on your DNS
server, this might be better:

iptables -A inboound-rule -p tcp --dport 53 --syn -m limit --limit 100/sec -j ACCEPT

(tune 100 per sec to something reasonable for your site).  This should take
the punch out of a DoS flood while still allowing legitimate requests to still
succeed...

You should, of course, have hardware and procedures in place to deal with
DDoS attacks in general - attacks against UDP/53 are much nastier than on
the TCP side...

On Wed, 05 Jan 2005 01:43:31 +0100, Florian Weimer said:
> You've got the wrong perspective on this one.  DoS on 53/UDP is much
> hard to defend against than DoS on 53/TCP.  The trouble with DNS is
> that there is no way to identify non-spoofed sources in a statless
> manner.  Therefore, it's been proposed to answer requests of unknown
> origin with a truncated response, to force the resolver to requery
> over TCP.  Now apply SYN cookies. 

Oooohh..  I hadn't heard that one before.  A clever one.  Only issue I
can see is that if you do that, you suddenly find that everybody behind
brain-dead firewalls that block TCP/53 can no longer talk to you.  I'm
unable to decide if that qualifies as a bug or a feature... ;)

One other issue there is that if you're running a *VERY* high-volume
mail server (something more than 500K-1M outbound connections/day),
the additional latency introduced by trying UDP, then having to redo
via TCP (remember - a min of 8 more packets on top of the 2 UDP packets)
can start to impact your throughput.  This also affects high-volume
Apache servers, but at least there you can usually mitigate it a *lot*
by telling it to log IP addresses rather than hostnames in the access.log.
You don't have a choice for SMTP - you're gonna have to look up those MX
and A records.  (And yes, a close-by caching nameserver does wonders here ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/unisog/attachments/20050105/088d9c1e/attachment-0002.bin


More information about the unisog mailing list