Re: the call for bind software

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

    Date:        Sat, 12 Oct 2002 18:01:32 +0200
    From:        Brad Knowles <brad.knowles@skynet.be>
    Message-ID:  <a05200523b9cdf274da62@[146.106.12.76]>

  | 	Scan the interfaces (and their netmasks).  BIND does that 
  | already.

But this would require a BIND (cache) connected to every LAN.   That's
unreasonable (I am used to creating lans with just a single host, plus
router, when I want the host isolated, no place on the LAN for a DNS cache).

  | Of course, you can always add or over-ride network definitions.

That is, you have to explicitly configure what's local.   That's
unmaintainable, as the server has no way to tell you when you've
gotten it wrong (unlike, for example, a dhcp server, which can complain
when it sees requests from lans it hasn't been configured to know about).

  | but more 
  | importantly you teach them that they need to be running their own 
  | nameservers,

That can be done by port filtering to your DNS cache system - don't
allow incoming packets to port 53 (and send queries from some other
port, so the answers go there instead).   If your cache, and auth
servers are different, that's easy, much easier than attempting to
have bind guess what should be served and what should not.

  | and hopefully those machines will be more resistant to 
  | cache pollution/poisoning.

Who you serve queries for makes no difference to that - the same queries
with the same answers, could come from inside, just as easily as from
outside.   If you're susceptible to pollution, it will happen, regardless
of where the queries are allowed from.

  | I disagree.  Many people seem to think they know how they should 
  | be run, but they are wrong.

What I meant was, people have formed a mindset about how things should
operate.  Whether that's right or wrong, in anyone's opinion, doesn't
really matter, it is the collective knowledge, passed around from one
"expert" to another.   That kind of thing is essentially impossible to
kill.

  | At the very least, if you were to turn on 
  | authoritative service and recursive/caching service on the same 
  | machine, the latter should be restricted to local clients.

That gains you absolutely nothing.

  | I'm not suggesting that we make it impossible.  Just that we make 
  | it optional and flip the switch the other way by default.

That could be done, but everyone is simply going to flip the switch to
the way that they're used to it working.  What benefit does that gain
anyone?

  | My experience is that the vast majority of people just 
  | take the default (whatever that is).

That's true, but only to the point where the default is what they're used
to getting - the expected behaviour.   When it isn't, they complain,
submit bug reports, and eventually find the necessary config option to
change it, and then proceed to tell everyone else that the first line
they need in their configs is the one to flip the switch back to the old
way - and then even new users, who might have accepted the default, pick
up the change.

kre


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