[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Robert Elz <kre@munnari.OZ.AU>
Cc: Brad Knowles <brad.knowles@skynet.be>, Edward Lewis <edlewis@arin.net>, Bill Manning <bmanning@ISI.EDU>, dnsop@cafax.se
From: Brad Knowles <brad.knowles@skynet.be>
Date: Tue, 15 Oct 2002 23:19:08 +0200
In-Reply-To: <15854.1034672673@munnari.OZ.AU>
Reply-By: Wed, 1 Jan 1984 12:34:56 +0100
Sender: owner-dnsop@cafax.se
Subject: Re: the call for bind software

At 4:04 PM +0700 2002/10/15, Robert Elz wrote:

>  That's what I mean by a management nightmare.   More and more places
>  that have to be updated when addressing changes.   We need to be moving
>  towards less of these, not more of them.

	Then you need to be simplifying your network.  Nothing in the 
world is ever going to protect you from needing to know what is 
"local" and what is not.  There are far more applications that depend 
on knowing what is "local" than just BIND.

>  But, once again, this has nothing at all to do with network security
>  (with the side issue perhaps of avoiding overloading, and for that
>  a firewall is a much better idea than having the server receive all the
>  packets and then discard them).

	Belt & suspenders.  Go ahead and do the firewall, but don't 
depend on it.  Configure the nameserver so as to be secure in the 
absence of the firewall, because sooner or later people are going to 
find a way to get around the firewall.

>  Don't try and frighten people by telling them that you're doing this
>  to protect them from something, because you aren't.

	Yes, I am.  You may choose to believe what you like.

>  You'd be much better off getting them to split the cache form the
>  server, which you're also suggesting, and just forgetting this other part.

	Okay, then let's do this by default -- caching & authoritative 
services are mutually exclusive, unless you know the magic 
incantation to get them both running in the same BIND instance.

	We can add the other part later.

>  Even there, the difference is minor.   You're concerned about allowing
>  some nodes to generate the query that causes the pollution, while
>  preventing others.   That's not very effective.

	No, my method is not 100000% fool-proof.  It is possible to work 
around it.  However, it does make things more difficult for them, and 
increases the probability that I will have something somewhere in 
some of the logs that might give me a hint as to where a particular 
attack may have come from.

>  no, it gives the appearance of being better than nothing, while not
>  actually being better at all.   That makes it worse.

	Again, we're talking about improving the state of affairs for the 
whole Internet, not just a particular local network.

	Or are you of the opinion that there is no purpose in doing RFC 
1918 address filtering at your egress routers?

>  But people don't figure things out - not most of them.  They follow
>  recipes.  They just do what someone (or some web site) says they should
>  do, without thinking a lot about what is happening, or why.

	No, they typically blindly take whatever the vendor gives them. 
If we can do our best to make sure that what the vendor will give 
them is more secure, then most of them will probably actually be more 
secure.

	A relatively small portion may attempt to blindly apply some 
recipe given to them by someone else, out of ignorance.  IMO, they 
get what they deserve if they're going to go mucking about with 
things -- they should either leave them alone, or make sure they get 
them right.

>  Again, no, there would be a set of "common" configurations, or
>  "sample configurations" that people just copy.   If none of the
>  ones distributed by ISC (or anyone else distributing bind) work
>  for them, they will find one from elsewhere that does.

	I believe that BIND already includes a variety of configuration 
samples, and this could easily be expanded.

>  And I assure you "enable this option to allow bind to serve queries
>  for your network" is much easier to explain, and much easier to do
>  correctly, than "find out all your local network prefixes and add
>  them in allow statements"

	But that's not what would happen for most people.  Only a 
relatively small group of people would have a problem whereby the 
automatic interface/netmask scanning would fail to appropriately set 
the list of "local" networks.  They are the only edge condition that 
we have to worry about.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list