Option to turn off EDNS globally?

[Dario Aguilar]

Paul,
       sorry, just a doubt, but why RFC still appears like a "proposed 
standard" and not a like a draf std/standard yet,after  8 years?.

http://rfc.net/rfc3700.html
3.4.  Proposed Standard Protocols
EDNS0      Extension Mechanisms for DNS (EDNS0)                    2671


http://www.rfc-editor.org/
      Number Title Author or Ed. Date Format More Info (Obs&Upd) Status
      RFC2671
     Extension Mechanisms for DNS (EDNS0)  P. Vixie August 1999 ASCII 
PROPOSED STANDARD


thank you,

Dario.

----- Original Message ----- 
From: "Paul Vixie" <Paul_Vixie at isc.org>
To: <bind-workers at isc.org>
Sent: Thursday, September 20, 2007 11:17 AM
Subject: Re: Option to turn off EDNS globally?


three replies here.

[adam trak]
> Would it be possible include it in main source or this is step back?

i would see this as a step back.

[lars-johan liman]
> I've seen problems with EDNS too, but in my experience the most common
> case is a bad firewall that has been instructed to drop DNS packets
> that are bigger than 512 bytes.

i'm increasingly seeing problems with firewalls that don't permit IP frags,
either disallowing packets with IP MF or IP OFF set, or allowing the first
fragment but not subsequent ones with the same IP ID, or both.  there's no
BIND option to work around this, as there is when it's just a size issue.

most firewalls don't (can't) hold frag state, so i'm not sure what this
means except that for EDNS0 to succeed, a whole lot of firewalls have to be
not just reconfigured but redesigned/upgraded.

[dario aguilar]
> Can we make Bind to not use ENDS by default and only use it when it 
> receives
> a truncated (UDP) response to a non-EDNS0 query before trying a standard 
> TCP
> query or in configurations with DNSSEC? Nominum CNS is doing this, and
> efectivelly improve the performance with authoritative server that don´t
> support EDNS.

RFC 2671 says no.  i believe the reasoning was, there can be additional data
whose absence won't trigger DNS TC, but whose presence would reduce the need
for additional transactions.  if nominum is doing this, they're out of spec.
if this should be done, then RFC 2671 should be revised to accomodate it.

the days of BIND randomly implementing noncompliant features and options
outside of a community driven protocol development process like IETF are 
long
past.  for example, when devising DLV, we made it fit into an error case of
DNSSEC, where "local policy" was allowed to control the behaviour.  RFC 2671
contains no such allowance.