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