[Unbound-users] Disabling EDNS0?

Post by Michael Tokarev
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.

I guess you mean authoritative servers, not resolvers?

Post by Michael Tokarev
After facing this prob multiple times, I finally tried to configure
unbound (1.4.22) to stop using EDNS0 in the first place. But it looks
like there's no way to turn it off, as far as I can see at least.
I only found edns-buffer-size setting, and it works, by changing
adverticing buffer size in the OPT record. Yes, I can set it to
512 just fine, and unbound will happily add the corresponding OPT
record.
But the question is how to stop it from _adding_ this record in
the first place?

Not sure if there is such an option, but I kind of hope there isn't;
you'd be getting yourself stuck in compatibility with broken
authoritative servers (because they sure are broken if they respond with
NXDOMAIN or NODATA because of EDNS0), and in the long run this isn't a
good approach. No large DNS packets, no DNSSEC (at all!), etc.

BTW, if you are looking for a way to disable EDNS0, you should disable
it *only* for those domains (or nameservers). Not sure if that is
possible either :)

But I'd rather see we try to get those broken domains fixed. Note that
they do not need to support EDNS0, they just need to follow the RFCs
instead of giving false answers.

Note that any reasonably modern resolver would be adding EDNS0 by
default, so if they are responding badly to it they should have a lot
more problems.

Jelte

krad

2014-10-15 09:25:11 UTC

If there is no in app support, then your best bet is to probably block the
outbound tcp packet to the relevant auth server on the unbound hosts
firewall, but do it gracefully ie send a disconnect packet rather than
silently dropping. If you use iptables have a look at ipset, or if its bsd
pf will work well with tables. That way you can block for certain hosts
only. Managing the hosts might be a bit of a headache though.

I guess you mean authoritative servers, not resolvers?

Not sure if there is such an option, but I kind of hope there isn't;
you'd be getting yourself stuck in compatibility with broken
authoritative servers (because they sure are broken if they respond with
NXDOMAIN or NODATA because of EDNS0), and in the long run this isn't a
good approach. No large DNS packets, no DNSSEC (at all!), etc.
BTW, if you are looking for a way to disable EDNS0, you should disable
it *only* for those domains (or nameservers). Not sure if that is
possible either :)
But I'd rather see we try to get those broken domains fixed. Note that
they do not need to support EDNS0, they just need to follow the RFCs
instead of giving false answers.
Note that any reasonably modern resolver would be adding EDNS0 by
default, so if they are responding badly to it they should have a lot
more problems.
Jelte
_______________________________________________
Unbound-users mailing list
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

Michael Tokarev

2014-10-15 09:36:58 UTC

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.

So the talk is about broken recursive resolvers (mostly in various
SOHO routers), not about certain domains.

(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.
I found many other wifi networks around the city share the same
brokeness -- so it looks like some local telecom issue.)

[]

Post by Jelte Jansen
But I'd rather see we try to get those broken domains fixed. Note that
they do not need to support EDNS0, they just need to follow the RFCs
instead of giving false answers.

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.

Post by Jelte Jansen
Note that any reasonably modern resolver would be adding EDNS0 by
default, so if they are responding badly to it they should have a lot
more problems.

Apparently, with so many people arond me, I was the only one in here
who had this prob ;)

Thanks,

/mjt

Post by Jelte Jansen
Jelte

Michael Tokarev

2014-10-25 06:24:07 UTC

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.
So the talk is about broken recursive resolvers (mostly in various
SOHO routers), not about certain domains.
(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.
I found many other wifi networks around the city share the same
brokeness -- so it looks like some local telecom issue.)
[]

Post by Jelte Jansen
But I'd rather see we try to get those broken domains fixed. Note that
they do not need to support EDNS0, they just need to follow the RFCs
instead of giving false answers.

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.

So I ended up throwing away unbound which gave me so many headaches
and installing dnsmasq. 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.

Thanks,

/mjt

Post by Jelte Jansen
Note that any reasonably modern resolver would be adding EDNS0 by
default, so if they are responding badly to it they should have a lot
more problems.

Apparently, with so many people arond me, I was the only one in here
who had this prob ;)

Pavel Simerda

2014-11-18 09:48:18 UTC

----- Original Message -----

Sent: Saturday, October 25, 2014 8:24:07 AM
Subject: Re: [Unbound-users] Disabling EDNS0?

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)

Post by Jelte Jansen
I guess you mean authoritative servers, not resolvers?

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.

Post by Michael Tokarev
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.

Post by Michael Tokarev
(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

Post by Michael Tokarev
I found many other wifi networks around the city share the same
brokeness -- so it looks like some local telecom issue.)

Likely so.

Post by Michael Tokarev
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 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

Post by Jelte Jansen
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.