[Unbound-users] Disabling EDNS0?
Pavel Simerda
psimerda at redhat.com
Tue Nov 18 09:48:18 UTC 2014
----- Original Message -----
> From: "Michael Tokarev" <mjt at tls.msk.ru>
> To: "Jelte Jansen" <jelte.jansen at sidn.nl>, unbound-users at unbound.net
> Sent: Saturday, October 25, 2014 8:24:07 AM
> Subject: Re: [Unbound-users] Disabling EDNS0?
>
> On 10/15/2014 01:36 PM, Michael Tokarev wrote:
> > On 15.10.2014 10:48, Jelte Jansen wrote:
> >> On 10/14/2014 09:13 PM, Michael Tokarev wrote:
> >>> Hello.
> >>>
> >>> It looks like a there's a common problem in various networks, -- some
> >>> resolvers does not understand EDNS0 OPT record at the end of the DNS
> >>> query packet and returns either NXDOMAIN or NODATA response to *any*
> >>> such query, no matter if the domain in question exists or not.
Hello Michael,
[replying to the whole thread at once]
I have seen this issue at LinuxCon in Dusseldorf and I was told during my
talk on Fedora unbound and dnssec-trigger integration at Linux Plumbers
that it's pretty much common in Germany (there was a good number of
knowledgeable people in the audience).
In that specific network I simply switched unbound to use TCP and hand-configured
it to talk to 8.8.8.8 because of the following conditions:
* UDP/EDNS0 to the local server was answered with NXDOMAIN
* I didn't find a way to tell unbound to use plain UDP
* TCP to the local server was not answered
* UDP (with or without EDNS0) to any public server was hijacked and answered by the local server
* I didn't know how to force unbound to use a port 80/433 fallback (let's call it a documentation
issue, as dnssec-trigger apparently does that)
> >> I guess you mean authoritative servers, not resolvers?
> >
> > No, I mean resolvers. The 'dns server' setting which is being sent over
> > dhcp, -- some distributions use this information and make it available
> > to unbound as `unbound-control forward <ip.add.re.ss>'.
> >
> > At least one network I come across here redirects outgoing port 53 to
> > the local resolver, so it isn't really possible to get it to work
> > even after disabling explicit forwarding.
Same symptoms here except that I forced unbound to use TCP by configuration in /etc
and then could simply configure it to use an external service.
> > So the talk is about broken recursive resolvers (mostly in various
> > SOHO routers), not about certain domains.
I detected that the broken resolver was an older (and possibly also patched) version
of dnsmasq which is more than common on SOHO routers.
> > (The talk is about Dusseldorf, DE -- I'm at linuxcon right now, and
> > the wifi network in the DCC is of this kind, with broken DNS resolver.
Ah, there it was ;). I was actually sharing my experience on twitter with #LinuxCon
hashtag, pity I couldn't reach you that way but I couldn't think of anything better.
https://twitter.com/pavlixnet/status/521644354805719040
> > I found many other wifi networks around the city share the same
> > brokeness -- so it looks like some local telecom issue.)
Likely so.
> > As a user I just had to disable unbound (which I used for local dns
> > caching), because I really needed the thing to work, I don't have
> > any time to fight with this prob at the conference.
Unbound is fortuanately part of my job so I couldn't resist to dedicate
some time just to get it working. So I rather switched it to TCP and
hard-configured it to use 8.8.8.8 but I admit this needed a bit
of research with the dig tool.
> So I ended up throwing away unbound which gave me so many headaches
> and installing dnsmasq.
Good if that works for you. I would rather get unbound improved from
code to documentation, as I like its features.
> It is not as nice and all, but it has a huge advantage over unbound:
> it actually works, while unbound, with
> all its bells and whistles, does not.
That's a bit unfair given that we're talking about a broken environment.
> Thanks,
>
> /mjt
>
> >> Note that any reasonably modern resolver would be adding EDNS0 by
> >> default,
Apparently the vast majority of installations at Dusseldorf used a reasonably
modern resolver that *wouldn't* use EDNS0 and they were lucky they weren't
using unbound or anything like that, otherwise you'd see a huge number of
people complaining about a defunct network at LinuxCon.
> >> so if they are responding badly to it they should have a lot
> >> more problems.
Apparently not.
> > Apparently, with so many people arond me, I was the only one in here
> > who had this prob ;)
Apparently everyone either uses a resolver that won't send EDNS0 (at least
to the broken resolver but I'm not aware of existing automagic tools for
this), or was capable of turning it off, or had to live without internet
connection.
I was also curious why nobody replied to my tweet at least from the hotel
or after LinuxCon. I expected a number of people experimenting with unbound
or some other resolver with features (even dig didn't work by default)
would reach me.
Cheers,
Pavel
>
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
>
More information about the Unbound-users
mailing list