Paul Wouters: Re: [dnssec-deployment] DNS cache issue

Adam Tkac atkac at redhat.com
Fri Nov 23 22:25:57 UTC 2007


On Fri, Nov 23, 2007 at 05:56:00PM +0000, Paul Vixie wrote:
> 
> how is this a response to what i wrote?
> 
> there will be no insistence that anybody remove anything.  the bsd license is
> the most forkable of any i can imagine.  if redhat wants to lock users into a
> controversial "feature" and incompatible config file syntax in order to make
> it harder for users to switch to a competing distro, then who am i to argue?
> (i can see why it's bad for the community, but it may be the best thing for
> redhat's shareholders, i'm no judge of that.)

I'm not going to fork anything. ISC does good work. Also I don't want
anyone lock to RH based systems. On the one side you (= upstream) says
that I have to remove that option but users like it. For now I'm not
going to remove ends patch.

> > > i'm particularly worried about a named.conf file syntax extension that
> > > locks someone into a particular system vendor and makes it impossible for
> > > that user to upgrade bind to a f/oss version later than what the vendor
> > > ships.
> > 
> > I ship that option for our customers. They want it and they have arguments
> > why I should keep that option.
> 
> they didn't ask for an incompatible syntax extension nor vendor lock-in.  you
> chose that solution to the problem people actually reported, which was extra
> messages in a syslog file.
> 
> > > this is something redhat should take up with the bind forum, and
> > > demonstrate some leadership, rather than going rogue like this.
> > 
> > I don't want to be a rogue. I discussed that option here. You have right
> > that EDNS is future of DNS but I say "not yet".
> 
> in the next message i saw on this thread, an alternative solution was proposed
> that would answer your customers' trouble reports perfectly well, and which i
> think would also be a good feature to adopt in the mainline BIND9 code so that
> all EDNS users could benefit.  i'll quote it below, so that you can see how a
> solution can look good vs. bad depending on whether your own revenue streams
> are, or are not, at stake.
> 
> > From: Allen Smith <easmith at beatrice.rutgers.edu>
> > Date: Fri, 23 Nov 2007 06:30:45 -0500
> > To: bind-workers at isc.org
> > Subject: Re: Paul Wouters: Re: [dnssec-deployment] DNS cache issue 
> > 
> > Perhaps, before switching to non-edns, BIND could turn down the
> > edns-udp-size option itself, and the (much less frequent, please!) log
> > messages stating it was doing this could suggest doing this manually to
> > prevent further log messages?
> > 
> > 	      -Allen
> 
> the reason i suggested working within the bind forum on stuff like this is to
> keep the community from fragmenting unnecessarily.  (if it's necessary, then
> i'd say, go for it.)  making BIND9 more adaptive and less chatty about EDNS
> issues would have a universal benefit.  "fixing" this for one vendor's
> customers in a way that makes named.conf files incompatible between systems
> has a universal cost.
> 
> if an influential vendor such as redhat decides that the time for EDNS is "not
> yet" then you actually have the power to make that prophesy self fulfilling,
> at least for a while.  the reason i asked for some "leadership" from redhat is
> that i was hoping you'd use your market power to help put more global pressure
> on middlebox vendors who break EDNS.  we're having a chicken/egg problem on
> both EDNS and DNSSEC (which also depends on EDNS).  a little help, please?

Allen's idea looks like good compromise for me. I'm going to add some
log message to my patch that global option is going to be removed and
when you do something with logging issue I will remove that patch.

> 
> i'm also very concerned that you're shipping 9.5 before its final release.  i
> won't even run new BIND releases on my desktop before it hits RC1.  shipping
> them to unskilled users fills me with dread.
> 

Main argument why I'm shipping 9.5 is that I think GSS-TSIG is pretty
good mechanism and I don't want backport big patch from 9.5 to 9.4.
I don't think current 9.5 is absolutely unstable. Yes, generally
"a" character in release immediately fills anyone with dread but I
think 9.5 is good. And from CVS it looks 9.5 comes to beta stage so it
will be better and better :)

Adam

-- 
Adam Tkac, Red Hat, Inc.


More information about the bind-workers mailing list