Option to turn off EDNS globally?

[Adam Tkac]

On Thu, Sep 20, 2007 at 02:17:16PM +0000, Paul Vixie wrote:
> 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.

Yes this is big problem. But tell to someone: "You have problem with BIND and EDNS? Buy new router!"

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

Yes, this behavior makes sence. I don't know how would be EDNS useful without DNSSEC. But if RFC says that this is impossible it (means RFC) should be revised before do this change.

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

Adam