Maintained by: NLnet Labs

[Unbound-users] Disabling EDNS0?

krad
Wed Oct 15 11:25:11 CEST 2014


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.

On 15 October 2014 09:48, Jelte Jansen <jelte.jansen at sidn.nl> 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.
> >
>
> I guess you mean authoritative servers, not resolvers?
>
> > 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
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at unbound.net
> http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20141015/2dd83693/attachment.html>