Maintained by: NLnet Labs

[Unbound-users] Unbound recursing and broken NS in RRSET.

W.C.A. Wijngaards
Tue Mar 6 16:56:23 CET 2012

Hash: SHA1

Hi Sander,

On 03/06/2012 03:50 PM, Sander Smeenk wrote:
> Hi,
> i'm running Unbound 1.4.6 on Linux for my recursing needs. It came
> to my

Please update to 1.4.16.  All of the fixes could fix you problem.
Also there have been fixes for reported (DoS) vulnerabilities.

> attention that this Unbound does not even answer(!) queries for
> domains which have at least one malfunctioning NS in their NS

What sort of malfunctioning are you talking about?  Downtime I presume
from the text below.

> In this case it's all about recursing ''. Please
> keep in mind that is running DNSSEC enabled. My Unbound
> is configured to do DNSSEC verification.
> Unfortunately (:P) the situation seems all normal now, all listed 
> nameservers seem to be responding, making this issue a tad bit
> harder to reproduce.
> The domain '' currently has four nameservers listed: |
>     28800   IN  NS |
> 28800   IN  NS |     28800   IN  NS
> |     28800   IN  NS
> Subdomain '' has it's own NS RRSET, 
> geo[123], these seem to work just fine.
>> From what i've seen, from time-to-time, seems not
>> to
> respond to queries which in turn makes recursing
> '' (with no DNS cache) malfunction with Unbound
> like so:
> | [sanders at haze:~] % dig | ; <<>> DiG 9.8.1-P1
> <<>> | ;; global options: +cmd | ;; connection
> timed out; no servers could be reached (i would expect SERVFAIL, at
> least)

That is strange, unbound should be able to fail over to ns1, ns2 and
ns3 to get the results there.  This fail over should happen without a
fraction of a second.  It should even remember this and favor the
other nameservers afterwards.

> At the same time a BIND9 server does not seem to have any real
> problems recursing the query, it just takes a little longer for the
> answer to appear as it seems to skip over the not-responding host.

As far as I understand unbound should behave similar.

> I found that after the neg. cache ttl expires, sometimes Unbound
> *is* able to resolve the domain. This all seems to depend on what
> NS is first in the RRSET returned for ''.

No, unbound picks the servers randomly.  The order in the NS set is

(it picks them randomly to get extra randomisation out of it; as a
defense against Kaminsky things).

> Friends on IRC comment that this behaviour (broken recursing with
> one malfunctioning nameserver in a larger RRSET) is seen more and
> more, also across different recursors...

If you give me bugreports then I can (try to) fix it (regarding the
unbound nameserver, then, :-) ).

> I skimmed through RFCs 1912, 2182, 1034 and 1035 but could not
> really find the proposed way to handle situations like the above.

It should try the other nameserver.

Can you enable verbosity at a higher level (say 4) and give me the
resulting log?  Can be runtime with unbound-control verbosity 4.

> Could someone please comment on this?
> -Sndr.

Best regards,
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -