<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 15 October 2014 09:48, Jelte Jansen <span dir="ltr"><<a href="mailto:jelte.jansen@sidn.nl" target="_blank">jelte.jansen@sidn.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/14/2014 09:13 PM, Michael Tokarev wrote:<br>
> Hello.<br>
><br>
> It looks like a there's a common problem in various networks, -- some<br>
> resolvers does not understand EDNS0 OPT record at the end of the DNS<br>
> query packet and returns either NXDOMAIN or NODATA response to *any*<br>
> such query, no matter if the domain in question exists or not.<br>
><br>
<br>
</span>I guess you mean authoritative servers, not resolvers?<br>
<span class=""><br>
> After facing this prob multiple times, I finally tried to configure<br>
> unbound (1.4.22) to stop using EDNS0 in the first place.  But it looks<br>
> like there's no way to turn it off, as far as I can see at least.<br>
><br>
> I only found edns-buffer-size setting, and it works, by changing<br>
> adverticing buffer size in the OPT record.  Yes, I can set it to<br>
> 512 just fine, and unbound will happily add the corresponding OPT<br>
> record.<br>
><br>
> But the question is how to stop it from _adding_ this record in<br>
> the first place?<br>
><br>
<br>
</span>Not sure if there is such an option, but I kind of hope there isn't;<br>
you'd be getting yourself stuck in compatibility with broken<br>
authoritative servers (because they sure are broken if they respond with<br>
NXDOMAIN or NODATA because of EDNS0), and in the long run this isn't a<br>
good approach. No large DNS packets, no DNSSEC (at all!), etc.<br>
<br>
BTW, if you are looking for a way to disable EDNS0, you should disable<br>
it *only* for those domains (or nameservers). Not sure if that is<br>
possible either :)<br>
<br>
But I'd rather see we try to get those broken domains fixed. Note that<br>
they do not need to support EDNS0, they just need to follow the RFCs<br>
instead of giving false answers.<br>
<br>
Note that any reasonably modern resolver would be adding EDNS0 by<br>
default, so if they are responding badly to it they should have a lot<br>
more problems.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jelte<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Unbound-users mailing list<br>
<a href="mailto:Unbound-users@unbound.net">Unbound-users@unbound.net</a><br>
<a href="http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users" target="_blank">http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users</a><br>
</div></div></blockquote></div><br></div>