Bug 275091

EDNS is NOT pseudo-feature (yes, only BIND implement it but it's good idea :) ).
And about patch - we have our modification (please see bind-9.3.3-edns.patch)
which adds enable-edns option. So specify enable-edns yes_or_no in your options
statement or view statement.

Adam

Adam, I can't agree with you. There seems to be no option in your patch, which 
allows to disable edns completely. Putting "enable-edns no;" into "options {};" 
doesn't turn it of at all which would expected behaviour, thus re-opening.

Hm, if this really doesn't work I'm wonder if Wilmer's patch will work. Could
you please test it and report me if works as expected? (I will build binaries
for you if you want).

Thanks

I'll build binaries myself, as this isn't hard for me. If it works, you can 
maybe merge these patches somehow and get it upstream as feature. I'll let you 
know whether Wilmer's patch is working for me better in the next days.

Adam, here's my status: Wilmers patch doesn't solve the problem for me, too.
It is currently not possible to disable EDNS completely. My syslog contains 
further on many many timeout error messages from BIND.

Could you test 9.5.0-12.1.a6 (from http://people.redhat.com/atkac/test_srpms/ ),
please? You should be able to specify "edns no;" in options/view statement.

Adam

Created attachment 198401 [details]
My local /etc/named.conf

Running on:
bind-9.5.0-12.1.a6.fc8.x86_64
bind-chroot-9.5.0-12.1.a6.fc8.x86_64
bind-libs-9.5.0-12.1.a6.fc8.x86_64
bind-utils-9.5.0-12.1.a6.fc8.x86_64
using the attached `/etc/named.conf'
and still get zillions of:
Sep 18 16:08:16 host0 named[20017]: too many timeouts resolving
'12.83.144.176.combined-HIB.dnsiplists.completewhois.com/A' (in
'dnsiplists.completewhois.com'?): disabling EDNS
Sep 18 16:08:16 host0 named[20017]: too many timeouts resolving
'12.247.13.87.combined-HIB.dnsiplists.completewhois.com/A' (in
'dnsiplists.completewhois.com'?): disabling EDNS
while having
options {
	edns no;
};

Thanks for report. Could you please package with more improvements?
http://kojiweb.fedoraproject.org/koji/taskinfo?taskID=166219

Yes, it looks fine now:
default .conf - Messages still produced
options { edns no; }; - Messages suppressed

bind-9.5.0-12.2.a6.fc8.x86_64
bind-chroot-9.5.0-12.2.a6.fc8.x86_64
bind-libs-9.5.0-12.2.a6.fc8.x86_64
bind-utils-9.5.0-12.2.a6.fc8.x86_64

Still I would rather like to turn off only the warnings as I expect the EDNS
feature would be still used for the servers supporting it.  Something similiar
to the following useful setting but targeted at EDNS:
logging {
        category lame-servers { null; };        
};  
I assume both types of the warnings should be turned on by default.
(Still I do not understand it much, just giving the possibly missing feature hint.)

There already is option which should disable those messages. Put "category
edns-disabled { null; };" to your logging statement. Also let me discuss
proposed edns global option in upstream

I'm using bind-9.5.0-12.2.a6 since yesterday evening and nothing edns specific 
in logs until now. But the last time, the messages came up after a day.

After discussion in upstream I'm going to completely throw away global edns
option (http://marc.info/?t=119027612100006&r=1&w=2). There will be three broken
things whose break EDNS (with solutions):

- bad remote server - use server's statement edns option
- big packet loss - simple disable EDNS related logging (comment #10)
- bad firewall/router (most cases) - report bug to your router vendor

Adam

(In reply to comment #12)
> - bad firewall/router (most cases) - report bug to your router vendor
- also set EDNS packet size should help (edns-udp-size, max-udp-size options)

Adam, I can't agree with you. I can't add thousands of bad remote servers to my 
configuration. And there are cases where I can't fix the firewall/router and 
the stuff *has* to work. So there *has* to be a workaround for such IMHO pseudo 
features. Please keep this patch at downstream, because not every upstream 
decision is clever and upstream doesn't want to see the reality in this case.

(In reply to comment #14)
> Adam, I can't agree with you. I can't add thousands of bad remote servers to my 
> configuration. And there are cases where I can't fix the firewall/router and 
> the stuff *has* to work. So there *has* to be a workaround for such IMHO pseudo 
> features. Please keep this patch at downstream, because not every upstream 
> decision is clever and upstream doesn't want to see the reality in this case.

Yes, upstream will be stupid sometimes but not in this case.

if you have one or more forwarders I don't believe that many doesn't support
EDNS. If yes it means that you are using old software with security bugs etc.
And set server statement for one of them isn't so annoying. And I also believe
that all (or near all) root servers and frontline servers support EDNS.

if you have bad firewall options edns-udp-size 512; (for outgoing queries) and
max-udp-size 512; (from incomming queries) should help you.

if you have bad network simply disable edns logging

It's really no argument why add global edns option, is it?

As written in comments #12, #13, #15, closing. Global edns option isn't needed

My forwarders support EDNS. But many authoritative DNS servers in eastern 
Europe, Asia and when wandering more through the Pacifc room don't. Most of 
this timeouts are from eastern EMEA and I don't want to configure eastern
EMEA's authoritative DNS servers as exceptions in my BIND configuration. So
there has to be a *real* solution for this. Just disabling logging doesn't
solve the problem, that DNS is very slow for these servers. IMHO you never
used EDNS in a huge environment where countless DNS queries are done. And
there *must* be a good reason, that vendors like HP are introducing similar
patches for BIND regarding this "feature". When having HP-UX, I'm able to 
disable the stuff completely, because HP recognized, there *are* cases like
I described above, where EDNS slows up heavily.

You'll have to change this for RHEL6 anyway, so why is the problem to add
this patch to Fedora 8, too? And please don't tell me, you won't add a patch
to BIND for RHEL6. There will be many customers killing you for this feature
as I'm currently doing. Do you really want to make me switching to HP-UX? ;-)

In the end I've added that patch to f8 build...

*** Bug 387191 has been marked as a duplicate of this bug. ***

After big discussion on bind-workers
(http://marc.info/?t=119566296700004&r=1&w=2) this option is going to be removed
in F9. I'm not going to rebel against all bind developers despite I think this
is good option. Please use

server ::/0 { edns no; };
server 0.0.0.0/0 { edns no; };

instead edns no;

As I wrote above real problem is often in bad router. Please report it to router
vendor.

Accepted as far as your suggestion works the same way.

And just once more: How to report to the router vendor such problems when
many companies of DNS servers in Asia Pacific (sorry, but the problems are 
always coming up when walking more and more east) are just too dumb to 
configure their routers either correctly or not buying working routers? :)

(In reply to comment #21)
> Accepted as far as your suggestion works the same way.
> 
> And just once more: How to report to the router vendor such problems when
> many companies of DNS servers in Asia Pacific (sorry, but the problems are 
> always coming up when walking more and more east) are just too dumb to 
> configure their routers either correctly or not buying working routers? :)

Yes, it is problem. You could only tell them that they doesn't honour eight year
old standard. Best will be send that people to jail and let them go after they
promise that they will never viloate ENDS again :)

Adam, "server ::/0 { edns no; }; server 0.0.0.0/0 { edns no; };" does NOT work
for me. It causes the same error messages as it wouldn't be there. Reopening.

Hm, what you mean with "doesn't work"? There are messages in system log?

"server ::/0 { edns no; }; server 0.0.0.0/0 { edns no; };" causes the same "Too 
many timeouts resolving $DOMAIN (in $DOMAIN): disabling EDNS" messages for me
and DNS gets ugly slow (even my forwarders support EDNS), but some DNS servers
in foreign don't. I know, that I can hide the log stuff, but that doesn't speed
up DNS/resolving for me. Anyway, shouldn't disabling "edns no" as above really
disable EDNS in BIND?

OUCH! Is the segfault somehow related to the EDNS thing?

Apr 15 02:27:54 tux named[5132]: too many timeouts resolving
'roberthansen.com/MX' (in 'roberthansen.com'?): disabling EDNS
Apr 15 02:27:59 tux named[5132]: too many timeouts resolving
'roberthansen.com/MX' (in 'roberthansen.com'?): disabling EDNS
Apr 15 02:34:59 tux kernel: named[5134]: segfault at 00000000 eip 0016079f esp
b74feec0 error 4

*** Bug 445080 has been marked as a duplicate of this bug. ***

After investigation server 0.0.0.0 { edns no; }; statement doesn't work now. I'm
going to release update with some additional patches right after F9 release

Created attachment 304558 [details]
simple patch

32:9.5.0-31.b3 doesn't seem to contain the patch, yet.

(In reply to comment #30)
> 32:9.5.0-31.b3 doesn't seem to contain the patch, yet.

You are right. After more investigation this patch isn't sufficient. Final patch
is going to be different and waiting for review in upstream.

Note that if you specify "server 0.0.0.0/0 { edns no; };" (and also for ::/0,
make sure you included "/0") EDNS is really disabled globally (you can check it
with tcpdump or dnscap), only log message leaks when query timeouts (not due
EDNS but when server is really unreachable)

Btw could you please check if your problem is really in EDNS, please? What says
"dig @<your_forwarder_IP> <some_name> +edns=0" ? And if it fails can add
+bufsize=512 parameter, please? From comment #26 it looks that you have big UDP
packet loss than your forwarder doesn't support EDNS. Thanks

I'm using /0 of course. My forwarders are both working fine, interestingly the 
following causes a timeout and thus a log message as in summary:

tux:~ # dig @127.0.0.1 redrumterriers.com +edns=0

; <<>> DiG 9.5.0b3 <<>> @127.0.0.1 redrumterriers.com +edns=0
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
tux:~ # 

AFAIK I've got no special configuration of bind on my server (just caching DNS 
which provides the same forwarders as in /etc/resolv.conf).

Created attachment 305175 [details]
Output from dig

Look on this dig output - from comment #26 it might look that roberthansen.com.
server doesn't support EDNS but it supports it. Log messages were due query
timeouts (packet loss, server was down etc) so no problem related to EDNS.

I recommend do not disable EDNS but first check if servers really doesn't
support it. And if they don't then proper administrator should be informed that
he doesn't conform nine year old standard and he should fix his server.

tux:~ # grep -c "too many timeouts resolving" /var/log/messages*
/var/log/messages:619
/var/log/messages-20080420:2146
/var/log/messages-20080427:2782
/var/log/messages-20080504:2942
/var/log/messages-20080511:4064
tux:~ #

You or me writing these e-mails? ;-)

bind-9.5.0-31.b3.fc9 has been submitted as an update for Fedora 9

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

bind-9.5.0-31.b3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bind'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3861

bind-9.5.0-32.rc1.fc9 has been submitted as an update for Fedora 9

bind-9.5.0-32.rc1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #33)
> I recommend do not disable EDNS but first check if servers really doesn't
> support it. And if they don't then proper administrator should be informed that
> he doesn't conform nine year old standard and he should fix his server.

Sorry but I am not going to contact admins of about 3000 servers per day, this
log is for the last two days on my workstation:
  http://www.jankratochvil.net/priv/disabling-edns
  named[24415]: too many timeouts resolving 'LINE-CONTENT/xxx' (in 'yyy'?):
  disabling EDNS
Connectivity is over ADSL on public static IP (through openvpn), 30ms RTT.

this problem is addressed in upcomming 9.5.1 release. Currently we have 9.5.1b2 in rawhide so if anyone is using F10 tree he could test bind-9.5.1-0.7.b2.fc10 and check if situation is better.

bind-9.5.1-0.7.b2.fc10.x86_64
Still a flood of them but they are of two kinds now:
Oct  4 20:12:54 host0 named[17739]: too many timeouts resolving 'homebanc.com/TXT' (in 'homebanc.COM'?): reducing the advertised EDNS UDP packet size to 512 octets
Oct  4 20:13:06 host0 named[17739]: too many timeouts resolving 'scissorlok.com/A' (in 'scissorlok.COM'?): disabling EDNS
Oct  4 20:15:21 host0 named[17739]: too many timeouts resolving 'valent.com/TXT' (in 'valent.COM'?): reducing the advertised EDNS UDP packet size to 512 octets
Oct  4 20:15:29 host0 named[17739]: too many timeouts resolving 'imaginemedia.co.uk.fulldom.rfc-ignorant.org/A' (in 'fulldom.rfc-ignorant.org'?): reducing the advertised EDNS UDP packet size to 512 octets

(full MTU/MRU 1500 - openvpn)

After many discussions about EDNS0 there is no way how better solve this problem. named works as RFC 2671 says and that messages are usually helpful so they are logged by default. If you want suppress that messages use "category edns-disabled { null; };" in your logging statement in named.conf. Closing

*** Bug 494948 has been marked as a duplicate of this bug. ***