Date: Fri, 24 Mar 2000 07:51:42 -0800 From: "Kevin Oberman" <oberman@es.net> To: keramida@ceid.upatras.gr Cc: J A Shamsi <jashamsi@yahoo.com>, freebsd-questions@FreeBSD.ORG Subject: Re: DNS and FIREWALL Message-ID: <200003241551.HAA01629@ptavv.es.net> In-Reply-To: Your message of "Fri, 24 Mar 2000 04:33:34 %2B0200." <20000324043334.C303@hades.hell.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 24 Mar 2000 04:33:34 +0200 > From: Giorgos Keramidas <keramida@ceid.upatras.gr> > Sender: owner-freebsd-questions@FreeBSD.ORG > > On Thu, Mar 23, 2000 at 04:19:31PM -0800, Kevin Oberman wrote: > > > From: Giorgos Keramidas <keramida@ceid.upatras.gr> > > > > > > Being selective on who gets allowed to connect to port tcp/53 is > > > not a bad thing. For instance if you just want your named to > > > play secondary for some zone, no need to allow incoming tcp/53 > > > connections. You can make your named use a non-priviledged > > > ephemeral port for queries, and allow only outgoing connections to > > > tcp/53. > > > > I'm afraid that this is a very bad idea. The specifications are > > explicit that a UDP transfer is tried (except for zone transfers) > > and, if the data is too large for a UDP transfer (512 octets), a TCP > > connection is made. The 512 octet limit is specified in the DNS RFC > > and BIND enforces this limit. > > Then, correct me if I'm wrong, but it seems that apart from bandwidth > limiting with DUMMYNET, one can not do much to protect a running named > from a DoS attack. Is that right? A valid point. If your server gets lots of AXFRs for a large zone, the lack of TCP capability would certainly block it. But, if I understand the attack correctly, it would also be prevented by use of the allow-transfer directive in the configuration. DoS based on a flood of requests for a specific, large RR could be blocked by the elimination of TCP, but this would also make the RR unavailable to whoever it was put there for. If it's only needed internally or for specific hosts, the allow-query directive might solve the problem. I guess it's a trade-off with making sure DNS works correctly. Tracking down failures when TCP is not available can be VERY tricky unless you think to look for it. The symptoms are not typically very descript, but, if you look at your log file, you will find the clues. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003241551.HAA01629>