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

Paul Vixie Paul_Vixie at isc.org
Fri Nov 23 17:56:00 UTC 2007


> > it's not just that isc didn't want to ship the option in standard bind.
> > it's that the bind-workers community rebelled against the idea of making
> > edns optional, anywhere.  if edns isn't working then there's an isp or a
> > middlebox or firewall that needs to get whacked.  the future of dns is
> > edns, and there is no sense or value in making it possible to turn it off.
> 
> I remember your words about inet_pton and inet_ntop
> (http://marc.info/?l=bind-workers&m=119151658310868&w=2). I'm wonder
> that _you_ insist that I have to remove global edns option before
> "..the last old router on earth is upgraded.."

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

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.


More information about the bind-workers mailing list