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

Mark Andrews Mark_Andrews at isc.org
Fri Nov 23 22:23:11 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 lock
> s
> > 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 demonstrat
> e
> > 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".

	The vast majority of nameservers do the right thing with
	EDNS queries (+99%), they respond to them.  There are a
	very small number that don't.

	I'm pretty sure that all current firewalls can pass EDNS
	responses if they are correctly configured.  Just about
	all firewalls pass EDNS responses that are 512 bytes or
	less without configuration changes to the firewall.

	There is no need to turn off edns gobally.  You over reacted
	to a simple diagnostic message.  You went from EDNS to no EDNS
	without getting people to tune the other EDNS parameters

	e.g.
		edns-udp-size 512;

	That change gets around most firewall problems.  If it doesn't
	then you look at adding the server clauses.

	This required education not code change.  The log message
	is about education.  It's not like named's wire behaviour
	changed.  Named was still answering the queries like it has
	for the last 8 years.

	EDNS is 9 years old.  Even the COM servers now support EDNS.

	Mark

> Adam
> 
> -- 
> Adam Tkac, Red Hat, Inc.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org


More information about the bind-workers mailing list