Option to turn off EDNS globally?

Paul Vixie Paul_Vixie at isc.org
Thu Sep 20 14:17:16 UTC 2007


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.


More information about the bind-workers mailing list