[Dshield] Help: DNS (53)

Tod D. Ihde toon at warmerbythelake.com
Thu Jan 1 13:43:21 GMT 2004

cbrenton at chrisbrenton.org wrote:
 >On Wed, 2003-12-31 at 11:37, David Hart wrote:
 >>> We're using bind solely as a caching name server.

Look into DJBDNS, your bandwidth, memory, diskspace, and response times 
will all improve. (I plug it when I can, I'm a big fan).

 >So you only need to support outbound queries.. got it.
 >>> Correct me if I'm wrong but the only connects that I need to accept
 >>> would be UDP to 53 from root servers. Right?
 >Correct. In fact, so long as you are keeping state, you only need to
 >accept ESTABLISHED 53/UDP.

False. You need to accept UDP to 53 from any in-bailiwick ( 
"authoritative") server. For example, f your server is looking up dns 
info for dshield.org, it must accept UDP packets from dshield.org.

Also, there is no such thing as an "ESTABLISHED" UDP session/packet/etc. 
  UDP is a connectionless protocol. The packet is sent, and either 
arrives, or does not. UDP is a stateless protocol, which is why so many 
SPFs (Stateful Packet Filters) have problems with it. (In order for an 
SPF to watch "statefulness" of a UDP stream, it must either understand 
the protocol [in your case, DNS], or must at least be intelligent enough 
to only allow packets back from IPs that packets have been sent to [but 
this is dangerous, as it can either deny legitimate UDP traffic, or 
allow through unwanted UDP traffic], within a specific time frame. 
Obviously, the first option is difficult to impliment, and the second 
option is messy and unreliable).

 >>> I noticed quite a few of these (they resolve to MSFT):
 >>> Dec 31 11:30:31 mail2 kernel: Firewall: IN=eth1 OUT=
 >>> MAC=00:09:5b:22:29:d1:00:06:25:e4:ed:a3:08:00 SRC=
 >>> DST= LEN=73 TOS=0x00 PREC=0x00 TTL=52 ID=31495 PROTO=UDP
 >>> SPT=51861 DPT=53 LEN=53
 >Sounds like you spend a lot of time on the MS site then. ;-)
 >Looks to me like a load balancer. Check your logs and see if you do a
 >query for a host within microsoft.com, msn.com, hotmail.com, etc. just
 >prior to this packet. I'm guessing you'll find an entry. The concept is
 >they connect to the name server making the query and measure round trip

Load balancing? Looks like a normal DNS packet to me, until I see an 
actual dump of the payload.

 >>> Am I doing something wrong (these packets were dropped)?
 >I drop them. Yes it breaks their load balancing and you could end up
 >connecting to a non-optimal server. You are far more secure however not
 >opening up access to UDP/53.

Again, doesn't look like load balancing. I suggest you read up a little 
on how DNS works (at the datagram level). The only thing you're doing is 
causing your DNS server to work harder, use more bandwidth, and place 
more of a load on external DNS servers if you're dropping DNS packets. 
(Please note; this is not 100% true, but the explaination would require 
another page or 2, just read up on how DNS works to understand).

 >>> While I am at it, we accept all connections from port 53 as the 
 >>> Is that appropriate?
 >Older versions of Bind and MS DNS use a fixed source port of 53. As of
 >Bind 8 or so, the source port is an upper port number. So I would focus
 >more on the target port rather than the source port. That or do full
 >payload verification. :)

Source port doesn't matter for filtering (for DNS) incoming replies to 
outgoing queries. Focusing on the target port for the return packet is 
appropriate, yes.

Allowing ALL incoming packets FROM udp port 53 means that ANY UDP 
datagram can get through your firewall, as long as the source port is 
53. Probably not what you intended.


Enjoy your meal!

More information about the list mailing list