Re: the call for bind software

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Mon, 14 Oct 2002 23:23:33 +0200
    From:        Brad Knowles <brad.knowles@skynet.be>
    Message-ID:  <a05200512b9d0e240f31b@[146.106.12.76]>

  | 	Not true.  If you have a /18 that you have chopped up into /24 
  | subnets, all you would have to tell BIND is that you have a /18. 

I have various pieces of a /16 (which change from time to time).
Not all of the /16 is what I would consider as "local" for this
purpose (if I cared at all, which I don't really).

  | Everything within that /18 would be considered "local".  If you add a 
  | totally new network in a separate part of IP space, you would need to 
  | add this to the list of "local" networks.

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.

  | 	Indeed, you should be doing this anyway.

Why?

  | 	I don't believe that this is practical or safe.  This is 
  | depending on a firewall to provide all your network security. 

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).

Don't try and frighten people by telling them that you're doing this
to protect them from something, because you aren't.   Certainly you're
wasting your time trying to convince me of that.   (And I'm one of the
people who believe that firewalls for security are close to useless).

  | Moreover, this only works for those people who are already splitting 
  | their services onto separate machines.  They aren't the people we're 
  | trying to help protect.

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.

  | 	For the situation where you restrict caching services to 
  | internal-only clients and you do that on the same machine as the 
  | authoritative services, then you only have to worry about the 
  | internal clients getting polluted/poisoned.

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.   If I want to pollute
your cache, I can do that just as easily by causing one of your local
systems to make a suitable query, as I can by making the query myself
(just send some e-mail that your SMTP server wants to do a DNS lookup
for, for its Received header or something, to translate the address into
a name, and then verify the name by making sure it maps back into the same
number - pick the right name, and your SMTP server's queries will do
everything I could have done by sending the query directly - note it doesn't
matter here whether the SMTP server believes the name I told it in
my in-addr.arpa PTR, what matters is that it generates the query).

  | You're still better off 
  | splitting the caching/recursive services onto a separate 
  | machine/instance of BIND, but it's better than nothing.

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

  | 	I disagree.  I think the best way to kill inappropriate 
  | "knowledge" of this sort is to change the default method by which 
  | BIND works, and force people to figure out how to make it work 
  | correctly.

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.

  | 	Some people might choose to do that, yes.  But if so, they will 
  | be forced to figure out how to make that change,

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.

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" - the second way, the way you're proposing,
can't be literally copied, as it is data dependent.  If there exists
another way (the switch) that isn't, that's what everyone will use.
I suspect you're ignoring human nature.

  | 	Most people will take the default whatever the default may be, 
  | and they will definitely benefit.

They wouldn't really benefit, and they'll use the default only if it works
for them out of the box.

  | 	There may be a certain amount of people that do that, yes. 
  | However, I believe that the vast majority will not be that "smart".

You mean they're so stupid as to leave running a DNS cache that doesn't
actually return results to most of their network?   OK, I can accept that
such people exist.   I find it harder to accept that you really believe
that moving them from "working, but subject to DNS pollution" into "not
working at all" is doing them (or anyone) a service.

And it isn't the "whole network" that benefits from this - only the
users of the cache (that perhaps once was polluted, and is no more).
No-one else will be (should be) sending it any queries except for data
that it is authoritative for,   BIND already protects that data from
pollution, so the kind of pollution that can still happen, won't
affect anyone but the local users.   (Of course, there are still probably
lots of old versions of bind still running, but they're irrelevant to
any discussion of what some new distribution should be doing).

kre

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.