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

Adam Tkac atkac at redhat.com
Fri Nov 23 08:42:37 UTC 2007


On Thu, Nov 22, 2007 at 07:39:35PM +0000, Paul Vixie wrote:
> >     Adam> Yes. I'm keeping short patch downstream which adds global edns
> >     Adam> option.  This option was discussed on bind-workers and ISC
> >     Adam> don't want that option. Our users has problem that log is
> >     Adam> flooded with "..disabling EDNS.." messages. Of course, EDNS is
> 
> 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.."

> >   Then just turn off that message, or limit it to saying it once.
> >   Bind9 turns off EDNS on it's own, right?
> 
> that's a reasonable approach, as long as the limit is repealed after 24
> hours, so that there will be a burst of errors every day.
> 
> 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.

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

Adam

-- 
Adam Tkac, Red Hat, Inc.


More information about the bind-workers mailing list