[Dshield] Help: DNS (53)

Chris Brenton cbrenton at chrisbrenton.org
Thu Jan 1 23:20:59 GMT 2004

On Thu, 2004-01-01 at 13:58, Jeff Kell wrote:
> Just to stir the fire a bit...
> If the DNS response doesn't fit into one packet, it will back off and 
> make a TCP request.  You have to take TCP into account as well when you 
> are dealing with DNS.

Sort of. The UDP reply packet will actually contain valid answers. It
will just chop the response to fit in the 512 byte packet size maximum
and set the truncation bit in the DNS header. The bit being set tells
the receiving system that if it wants a full answer, it needs to switch
over to TCP. Load balancers will ignore the truncation bit setting. I've
seen this in the wild. I can't think of any normal name server
communications off the top of my head that will ignore it, so TCP is

BTW this is why I included TCP/53 in my rules to Tod. ;-)

The same is not true in reverse however. If you have a publicly
accessible name server _and_ you have insured your answers will never
exceed 484 bytes (484 data + 8 UDP + 20 IP = 512 total), you only need
to open UDP/53 inbound. You don't need to let people access TCP/53,
unless the source IP is a legitimate secondary. 

I saw this distinction save a few butts when Lion was released. If you
where vulnerable to Lion but only permitted inbound UDP/53 Lion could
not root the box because it needed inbound TCP/53 to transfer its root

> Scanners and recons may request a zone transfer via UDP, which is 
> essentially a no-no. 

Dig will let you do this as well. I think host does too, but I would
have to check. I'm not sure how much info they could retrieve this way
beyond your SOA, NS and MX records which they could get though specific
UDP queries anyway. Would be an interesting test.

>  But very few if any firewalls/router ACLs have a 
> clue if it's a zone transfer request or not. 

Routers its doubtful. Firewalls, only if its a proxy or SI that actually
"inspects" UDP/53, a feature that is pretty rare. 

>  For bind, you can specify 
> the hosts that can request a zone transfer from you (should be a list of 
> your authorized secondaries and cache servers).

Agreed. You can even limit which IPs can transfer each unique zone. For
the uber-paranoid, you can implement DNSSec which requires a shared
secret to be verified before the transfer is permitted as well. Defense
in-depth is a good thing. :)

> In general, DNS requests come from ports >1023, and DNS replies should 
> go to ports >1023.  Otherwise there may be issues (Snort checks for this 
> anomaly).

I have not checked 2003, but older version of MS DNS used the port 53 to
53 convention, just like older versions of Bind. In fact, there are
still way too many sites running Bind 4.x so its not uncommon to see
this even today. Not sure if there are any other name servers out there
beyond these examples that are still using this old convention.

> For some reason, recent Linux (RedHat) builds of bind pick their 
> outgoing request port in the 32770ish range.  If you blindly follow the 
> SANS guidelines which say "block 32770-32789 as these are RPC loopback 
> ports" you will hose DNS.  So always permit DNS (53) through this range 
> before you block everything else.

Agreed, you really have to take "guidelines" as just that, especially
when you are talking about upper port numbers. 


More information about the list mailing list