root-servers hitting my firewall

[Mark_Andrews at isc.org]

> Hi all,
> 
> I'm stil not sure  ..

	Well with "forward first" the nameserver will ask the forwarders
	*first* then if it doesn't get a answer it can use from them it
	will follow the normal DNS resolution algorithm.
 
> i would like to understanfd the entire process, not just ignoring my
> firewall ..
> 
> I feel like there is no clear definition of what is good and wrong when
> setting up a
> 'mixed' forwarding / internal bind dns server behind a firewall  ..
> 
> > > options {
> > >         forwarders { 194.134.5.5; 194.134.0.97; };
> > >         directory "/var/named";
> > >         listen-on { 127.0.0.1; 192.168.0.100; };
> > > }
> 
> > Set "forward only;" the default is "forward first;".
> 
> > Also your firewall is poorly configured if it allows out
> > traffic but doesn't allow reply traffic back in (this
> > includes ICMP traffic).  It sounds like you have been
> > inadvertently been pounding on the root servers (and I presume
> > other servers) as a result.
> 
> My firewall is running ipchains, so yes it is dumb (stateless) and i did
> play around with the other options " query-source port 53"
> 
> this seems to work -if- i open up port 53 offcourse ..
> since my bind only listens on loopback and the others nic this should be
> safe ..
> But this only work for just that one box .. we want to set up a 2nd dns (as
> slave)
> 
> this is what i allow for now ..
> 
> ipchains -A input -s 194.134.5.5/32 53   -d 192.168.1.2/32 1025:65535 -p
> udp -j ACCEPT
> ipchains -A input -s 194.134.0.97/32 53 -d 192.168.1.2/32 1025:65535 -p
> udp -j ACCEPT

	That's the input.  What about the rules that all allow the queries
	*out*.

	I well configured firewall will have output rules that are the
	inverse of these and not just allow out any UDP packet.

> > >- are this hits on my fiirewall a result of my bind trying to resolv
> itself
> > >somehow ?
> 
> > your system is probably interested in resolving it's own name, so the
> > requests might have been due to that.  more likely it's the normal
> building
> > of the root server list that happens every time that bind is started.
> 
> This could be true, because a few lookups go fine when i tail the firewall
> logs..
> Besides the fuctionallity of bind works fine a s from a point of view of the
> clients
> that use it ..
> 
> If my bind is trying to resolv itself exernally (wich i can imagine) i
> wonder what it will
> do when it gets a 62.xx.xxx.xxx reply from it's auth. dns while it own local
> dns zone is
> made up of a 192.168.0.100 ip ...
> 
> It all works fine would most people say untill they look at the firewall
> logs ..
> My firewall is a ipchains one, so yes it is dumb (stateless) and i did play
> around with the
> other options " query-source port 53"
> 
> Mario.
> 
> I know about the "forward only;" / "forward first;". options .. i gues i
> ignored
> them because i though it would ignore my local dns zones ..or do no caching
> In all the bind caching/forwarding samples there is a 127.0.0 zone only .. i
> have 4

	No.  The nameserver will use local information if it has it.
	Forwarding affects *how* the nameserver looks up things remotely
	not whether it looks up things remotely.
 
> the ISC manual isn't very clear about a 'mixed' forwarding / internal
> rersolver wich has a
> lan ip and is behind s firewall, while there are 1000's of boxes out of
> there that run this way..
> 
> Maybe i was just thinking wrong .. I just do not want to open the
> dns -service- ever
> for queries from the outside, not from clients and nor from others servers
> .. so it's not
> a true 'real dns' like the one that are auth.. for my domain-zone.
> 
> I guess i am very wrong when thinking that when using 2 forwarders the reply
> would -allways- come from them
> and not from say the auth. ns of say xxx.ccc.net wich will try to connect to
> my box and may (if to slow) be denied
> by my frewall.

	The reply should come from the address/port tuple the query was sent
	to (named will drop it if it doesn't (BIND 8 ignores the port)).

	Your problem is that you were sending queries to more than your
	forwarders.  If your firewall was setup well to begin with you
	would have been asking "why is named sending the queries to the
	root servers" which may have been enough to allow you to work
	out the answer on your own.

	You have a second problem in that your firewall allowed
	these other queries out but didn't allow the replies back
	in.  I find it amazing that people, when they see this,
	think the roots are attacking them rather than the fact
	that they are attacking the roots (inadvertently) by asking
	queries and ignoring the replies.
 
	Note: you may still get replies from nameservers other than the 
	roots if they are being used as amplifiers in a DNS DoS attack.
	However I doubt that this is the case this time as you have a
	local mis-configuration that results in the behaviour described.
	
	Mark

> I just decicded i better should buy O'reilly's Bind cookbook (i have read
> the ISC bind manual and lots of other stuff but ..)
> 
> 
> Thank you both for your help !
> 
> Mario.
> 
> 
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org