Re: the call for bind software

[Brad Knowles <brad.knowles@skynet.be>]

At 9:30 PM +0700 2002/10/13, Robert Elz wrote:

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

	Assuming you use subnetting and subnet masks that are not 
otherwise detectable (and reversible) by BIND, then you would need to 
have an over-riding local configuration.

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

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

	Indeed, you should be doing this anyway.

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

	I don't believe that this is practical or safe.  This is 
depending on a firewall to provide all your network security. 
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.

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

	Right, but if you split the authoritative services from the 
caching/recursive services, then you don't have to worry about the 
authoritative server getting polluted or poisoned.  Moreover, you 
don't have to worry about the authoritative server propagating the 
polluted/poisoned data to other servers.

	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.  You're still better off 
splitting the caching/recursive services onto a separate 
machine/instance of BIND, but it's better than nothing.

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

	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.

>    | 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 disagree.  We're talking about improving the state of the 
overall Internet, not just the services provided to one specific site.

>  That could be done, but everyone is simply going to flip the switch to
>  the way that they're used to it working.

	Some people might choose to do that, yes.  But if so, they will 
be forced to figure out how to make that change, and there is at 
least the chance that you'll be able to educate them about the proper 
way to manage things during that process.


>                                             What benefit does that gain
>  anyone?

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

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

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

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