Subject: the call for bind software

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Oct 2002 14:59:33 -0400

As I work for an RIR I will not comment on whether or not the RIRs 
should perform the tasks associated with signing the root zone.

But I do have this to say.

A few folks have called for a new public snapshot and/or a stable 
9.3.  (I don't mean to pick on Bill or Måns for such utterances, but 
they are the ones I can quote as anecdotal evidence.)

If there is to be further BIND work, someone has got to fork over the 
resources to make this happen.  Yes, there is a relative trickle now, 
but remember how long it took the DS RR to be implemented while one 
particular stream of funding was in an interrupted state.

The "someones" who can fork over resources may not be on this list, 
but it might be nice if we on this list help make more open source 
versions of DNS software happen.  This isn't the mission of this 
list, but many of us would be the benefactors.

PS
Open Source (DNS) software is more than just BIND
Resources are more than just funds

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Bill Manning <[email-masked]>
Date: Thu, 10 Oct 2002 13:36:44 -0700 (PDT)

% If there is to be further BIND work, someone has got to fork over the 
% resources to make this happen.  Yes, there is a relative trickle now, 
% but remember how long it took the DS RR to be implemented while one 
% particular stream of funding was in an interrupted state.
% 
% The "someones" who can fork over resources may not be on this list, 
% but it might be nice if we on this list help make more open source 
% versions of DNS software happen.  This isn't the mission of this 
% list, but many of us would be the benefactors.
% 
% PS
% Open Source (DNS) software is more than just BIND
% Resources are more than just funds
% 
% Edward Lewis                                          +1-703-227-9854

	AMEN.  However, if this stuff is to be deployed at all,
	it has to be working and stable.  The sad fact is, that 
	in the absense of -anything- else, flawed snapshots will
	be used by those trying to gain operational experience.
	Sane people will -NOT- commit to production services on
	snapshot code (generally).  And for all its downsides,
	BIND is still the reference implementation. To date, its
	the only implementation that does the whole thing. 
	
	So you seem to be intimating that this state of affairs
	is delaying the release of what might be a deployable DNSSEC
	solution.  Or are you arguing for more "genetic" diversity
	in DNS codebases?   If so, folks should be looking beyond the
	"low-hanging" fruit of a non-recursive server.  

--bill

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Oct 2002 17:34:04 -0400

I'm preaching that we need to support the development of software 
that will enable us to do DNSSEC.  We need mature software that will 
meet with the demands of production DNS services.  This includes, but 
is not limited to, being able to keep up with demand (performance), 
be able to stay up (availability), be able to be configured 
(understandable), and be a full implementation of the service 
(functional).

Do I want cybergenetic diversity?  No, oddly enough.  I don't want it 
- but it is a necessary evil.  With it I am more assured that DNSSEC 
will be an available service, but the diversity on its own isn't of 
interest to an user.  I do encourage cybergenetic diversity when I'm 
thinking about the protocol, but when I'm thinking about my servers, 
I only want to run the best version of DNS software.

Yes, folks need to be looking at recursive servers.  The 
authoritative servers are 44.5 kg weaklings compared to it. 
Authoritative servers do nothing but (at best) assemble responses to 
answers.  Recursive servers have to follow referrals, chase down 
CNAMEs, perform KEY-SIG-DS-KEY-...-SIG validations, decide what to 
cache, etc.  Recursive servers do the hard work.

But that's not all we need to address.  Tools, tools, tools.  We need 
to make DNSSEC as simple as possible to use, but no simpler, and 
still be useful.  (Twisting a trite statement about design.)  I'm not 
sure we've identified the simplest way in which DNSSEC can work just 
yet.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Oct 2002 22:11:19 -0400

At 17:34 -0400 10/10/02, Edward Lewis wrote:
>Do I want cybergenetic diversity?  No, oddly enough.  I don't want it - but it

Before any one flames me - this sounds stupid.

What I was thinking was that "having at least one working, functional 
implementation is most important" to me right now.  I especially 
don't mean to say that BIND should be the only one.  Having options 
is better than not.  But what I "want" now is one that works.

Maybe next time I oughta stop typing at 1730 in the afternoon.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Brad Knowles <[email-masked]>
Date: Fri, 11 Oct 2002 19:26:13 +0200

At 5:34 PM -0400 2002/10/10, Edward Lewis wrote:

>  still be useful.  (Twisting a trite statement about design.)  I'm
>  not sure we've identified the simplest way in which DNSSEC can work
>  just yet.

	I submit that there are other DNS problems that need to be solved first.

	We need to get BIND changed so that it does not default to 
running a caching/recursive resolver for anyone who wants to ask it a 
question -- it should restrict queries to "local" networks.

	When setting up an authoritative server, it should not default to 
also being a caching/recursive server.  Sure, you should be allowed 
to turn on these features if you want them, but they should not be 
turned on by default.

	If we can get these two relatively simple problems fixed 
out-of-the-box, we can make BIND more secure by default.  That will 
then help us to clear the field for additional enhanced security 
features.

-- 
Brad Knowles, <[email-masked]>

"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 <[email-masked]>.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2002 16:56:27 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    Edward> Do I want cybergenetic diversity?  No, oddly enough.  I don't want it 
    Edward> - but it is a necessary evil.  With it I am more assured that DNSSEC 
    Edward> will be an available service, but the diversity on its own isn't of 
    Edward> interest to an user.  I do encourage cybergenetic diversity when I'm 
    Edward> thinking about the protocol, but when I'm thinking about my servers, 
    Edward> I only want to run the best version of DNS software.

  Unfortunately, I don't think that we'll get "best" until we have multiple
as well. One reason is competition - but another reason is differences in
goals - as you say, authoritative servers are not the same as recursive servers. 

  As an non-DNS developer (a customer of the domain name service), I am
suffering from the problem that the only real API that anyone knows about is
gethostbyname(3)... 

  I need to know:
    1) was it signed at all?

    2) how far am is this data from an axiomatic key?  I assume a forest
       of trees, and I assume that as I get further from an axiomatic key,
       that the risk goes up. I just need the number so that I can keep
       it in my audit log. 
       Some orgs will want to cross-sign (SIG(0) or preconfigured keys)
       trees with close partners.

    3) even though some of the signatures may have expired, and it might be
       that the servers are not reachable to update them, I would still like
       to get the data if the signatures continue to check out. I want the
       degraded security to be visible of course! Again for the audit log.

       A perfect example.com of this. foo.example.com wants to talk to bar.example.com.
       The signature from .com on example.com is expired, and due to the
       backhoe event, we aren't getting any new data for awhile.
       But, there is no reason why I can't continue to use the old data for
       some applications. 

  In most cases, end users will not be qualified to make decisions about the
quality of this data. But that doesn't mean it shouldn't be available.

    Edward> But that's not all we need to address.  Tools, tools, tools.  We need 
    Edward> to make DNSSEC as simple as possible to use, but no simpler, and 
    Edward> still be useful.  (Twisting a trite statement about design.)  I'm not 
    Edward> sure we've identified the simplest way in which DNSSEC can work just 
    Edward> yet.

  Your ideas intringue me. Continue. :-)
  
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.

---

From: Robert Elz <[email-masked]>
Date: Sat, 12 Oct 2002 17:29:45 +0700

Date:        Fri, 11 Oct 2002 19:26:13 +0200
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <a05200516b9ccb9714ab1@[146.106.12.76]>

  | 	We need to get BIND changed so that it does not default to 
  | running a caching/recursive resolver for anyone who wants to ask it a 
  | question -- it should restrict queries to "local" networks.

How do you propose that it figure out what is a "local" network and what
isn't?   The only way would be explicit config, and other than
configuring 0/0 as "local" what you create is a maintenance nighthmare.

And in any case, answering queries for random clients from all over the
place isn't a real security/reliability problem for anyone other than the
random clients.  They're the ones choosing to query some random remote
server, so they can be expected to either understand what they're doing,
or simply not care.

Doing lookups for the universe might be a performance issue for the
server (and hence perhaps a DoS issue), but that's a entirely different.

  | 	When setting up an authoritative server, it should not default to 
  | also being a caching/recursive server.

This one would be possible, and might make some difference.  One would
hope these days that any new enough version of BIND (or anything else)
in which this could be implemented though would also be new enough to
understand the cache/zone pollution issues, and avoid them as much as
possible.

I also half suspect that it is a bit late for this.   People have already
now learned how DNS servers should be run, and for the majority, that's
a server that answer queries for local and remote users alike - doing
recursive lookups when appropriate.   Make it impossible to work that
way, and much of the population will simply not use the new implementation.
Make it optional (as you suggested) and much of the population will
simply turn the switch back to the current mode.

kre

---

From: Brad Knowles <[email-masked]>
Date: Sat, 12 Oct 2002 18:01:32 +0200

>  configuring 0/0 as "local" what you create is a maintenance nighthmare.

	Scan the interfaces (and their netmasks).  BIND does that 
already.  Of course, you can always add or over-ride network 
definitions.

>  server, so they can be expected to either understand what they're doing,

	By turning off recursive/caching for non-local clients, you do 
reduce abuse of services (and potential DoS issues), but more 
importantly you teach them that they need to be running their own 
nameservers, and hopefully those machines will be more resistant to 
cache pollution/poisoning.

>  now learned how DNS servers should be run,

	I disagree.  Many people seem to think they know how they should 
be run, but they are wrong.  We should make the software more 
idiot-resistant.

>                                             and for the majority, that's
>  recursive lookups when appropriate.

	That capability should exist, yes.  But it should not be the 
default configuration.  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.

>                                       Make it impossible to work that

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

>  simply turn the switch back to the current mode.

	Maybe.  My experience is that the vast majority of people just 
take the default (whatever that is).  If we can make the default more 
secure, then most people will benefit.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Oct 2002 11:02:56 +0200

On Fri, Oct 11, 2002 at 04:56:27PM -0400,
 Michael Richardson <[email-masked]> wrote 

> suffering from the problem that the only real API that anyone knows about is

<troll>
You mean getaddrinfo(3)?
</troll>

We could just add an error code:

EAI_NOAUTH         DNS records not authentified
EAI_INVALAUTH      DNS authentication failed (invalid or corrupted signature)

With an option in /etc/resolv.conf to express if you want only signed
records or not.

But I'm certain it has already been discussed by DNSSEC people. Check archives.
 
>     1) was it signed at all?

See above.
 
>     2) how far am is this data from an axiomatic key?  

More complicated issue :-(

>        degraded security to be visible of course! Again for the audit log.

This is starting to look complicated. I suggest to add a new function,
only for that level of security.

---

From: Robert Elz <[email-masked]>
Date: Sun, 13 Oct 2002 21:30:29 +0700

Date:        Sat, 12 Oct 2002 18:01:32 +0200
    From:        Brad Knowles <[email-masked]>
    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

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 14 Oct 2002 05:08:53 -0500

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
> to getting - the expected behaviour.   When it isn't, they complain,
===============================================

When they can flip the bits via the DNS, they have more control, and complain less...
...they can also then pay to have the bits flipped the way they want and on certain days...

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
IPv8
0QQQQGGGSSSSSSSS[32-bits][Port]
IPv16
0QQQQGGGSSSSSSSS[32-bits][Port]
1WWWWWWWSSSSSSSS[32-bits][Port]

====

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://www.ietf.com
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://ipv8.dyndns.tv
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Oct 2002 12:53:33 +0200

On Sun, Oct 13, 2002 at 09:30:29PM +0700,
 Robert Elz <[email-masked]> wrote 
 a message of 74 lines which said:

> unmaintainable,

Postfix does it for a long time (scanning interfaces to see who's
allowed to relay but allowing you to override its discoveries) and it
seems all Postfix administrators are happy with it.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 14 Oct 2002 19:08:59 +0200

> seems all Postfix administrators are happy with it.

Postfix is much younger than BIND. Using Postfix is something you actively
choose. That is quite different from the legacy carried by named. Besides,
most nameserver implementations do allow queries from anywhere, so altering
that would not only change the default behaviour, it would challenge the de
facto standard.  

Shouldn't this be discussed on a bind9 mailing list instead? 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 14 Oct 2002 23:28:35 +0200

At 7:08 PM +0200 2002/10/14, Måns Nilsson wrote:

>                                                                     Besides,

	Which caching/recursive nameserver implementations default to 
allowing queries from any source?  This would be a very important 
input to my upcoming talk at LISA 2002....

>  Shouldn't this be discussed on a bind9 mailing list instead?

	Could be.  The subject came up here first, and therefore this is 
where the discussion has continued.  Perhaps we should instead move 
it to bind-workers, however.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 14 Oct 2002 23:23:33 +0200

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

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

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

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

>  "expert" to another.   That kind of thing is essentially impossible to

	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.

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

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

>  way - and then even new users, who might have accepted the default, pick

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

---

From: Brad Knowles <[email-masked]>
Date: Mon, 14 Oct 2002 23:26:45 +0200

>  seems all Postfix administrators are happy with it.

	Not everyone.  I was one of the people pretty unhappy with the 
way postfix did it, since Wietse enforced Class A/B/C distinctions on 
the networks, and did not inspect the netmask on the interface.  This 
meant that if you had a /28 out of a /24 in the normal Class C space, 
you would default to acting as an open relay for everyone else that 
was in that /24 but not inside your /28.

	I suggest that we take that next step and inspect the netmask, 
and restrict what we consider "local" on that basis.  We might be 
forced to open that restriction open, but that could be easily 
manually configured.

---

From: Robert Elz <[email-masked]>
Date: Tue, 15 Oct 2002 16:04:33 +0700

Date:        Mon, 14 Oct 2002 23:23:33 +0200
    From:        Brad Knowles <[email-masked]>
    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

---

From: Brad Knowles <[email-masked]>
Date: Tue, 15 Oct 2002 23:19:08 +0200

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

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

>  to protect them from something, because you aren't.

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

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

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

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

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

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

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 16 Oct 2002 18:55:20 +0700

Date:        Tue, 15 Oct 2002 23:19:08 +0200
    From:        Brad Knowles <[email-masked]>
    Message-ID:  <a05200507b9d233a63eef@[146.106.12.76]>

  | Nothing in the world is ever going to protect you from needing to
  | know what is "local" and what is not.

Why should I care?   It isn't the location of the system that matters
for what I want to allow, but the identity of the user of the system.

Further, I'm at a university, it is just as likely, if not more likely
that attacks will come from local sources as remote ones.

  | Belt & suspenders.  Go ahead and do the firewall, but don't 
  | depend on it.

I wasn't planning on depending upon it, nothing in this makes a
difference, so it doesn't matter.

  | Configure the nameserver so as to be secure in the 
  | absence of the firewall,

Of course the nameserver should be secure.   But answering queries for
random outsiders is not insecure.   It might be foolish to waste my
resources that way, but it is not insecure.

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

I have less problem with that, though I can't think of any particularly
good reason that the people working on bind should take any notice of
your requests.

  | 	No, my method is not 100000% fool-proof.  It is possible to work 
  | around it.

It is trivial to work around it.   Not that it matters anyway.

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

You keep asserting that, with no justification at all.   A polluted
(modern) bind cache affects only the people using it as a cache, and
has no effect on anyone else whatever.

How is the whole internet supposed to benefit from avoiding that
pollution?

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

How did that random thought work its way into this discussion?
What's the relevance?

  | No, they typically blindly take whatever the vendor gives them.

If it works for them.   Only if it works for them.   If it doesn't, they
either make the vendor fix it, or they fix it themselves using some info
they acquire from somewhere.

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

Huh?

Most binds run on singly homed hosts - the only address/mask they can
hope to find (even assuming the host is correctly configured) is the one
for the local LAN.

That means that you're asserting that "most people" live on networks
that consist of exactly one LAN, no more.   That's an interesting
view of the state of the world.

There certainly are a lot of small sites like that around, but most of
them don't run their own DNS cache at all - they use one their provider
supplies (when they're not connected to the internet they have no need
of DNS resolution, usually using hosts file, NIS, or more typically, NMB
or NBP for all the name resolution they need).

kre

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 18 Oct 2002 11:48:36 +0200

On Mon, Oct 14, 2002 at 11:02:56AM +0200,
 Stephane Bortzmeyer <[email-masked]> wrote 

> > suffering from the problem that the only real API that anyone knows about is
...
> But I'm certain it has already been discussed by DNSSEC people. Check archives.

Unfortunately, no, it seems no work has been done yet on this API
issue.
#----------------------------------------------------------------------
# To unsubscripbe, send a message to <[email-masked]>.