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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
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
> RRSET.

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

> In this case it's all about recursing 'archive.debian.org'. Please
> keep in mind that debian.org 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 'debian.org' currently has four nameservers listed: |
> debian.org.     28800   IN  NS  ns1.debian.org. | debian.org.
> 28800   IN  NS  ns2.debian.org. | debian.org.     28800   IN  NS
> ns3.debian.org. | debian.org.     28800   IN  NS  ns4.debian.com.
> 
> Subdomain 'archive.debian.org' has it's own NS RRSET, 
> geo[123].debian.org, these seem to work just fine.
> 
>> From what i've seen, from time-to-time, ns4.debian.com seems not
>> to
> respond to queries which in turn makes recursing
> 'archive.debian.org' (with no DNS cache) malfunction with Unbound
> like so:
> 
> | [sanders at haze:~] % dig archive.debian.org | ; <<>> DiG 9.8.1-P1
> <<>> archive.debian.org | ;; 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 'debian.org'.

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

(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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPVjOnAAoJEJ9vHC1+BF+ND14P/0gwUJrzSFyAg+pQMa+3WoOS
W7n9cvpNkJJ37uxUm5TXGu8Ken8J8CXDcwBI/XUpQ9rsMbiZkZkPQws+xLcyDeXZ
m0DfSWLiN+7KiWjsev0pT544swLIr/9CwwS7gFK/Jv7zSCCQ6ef+6l0ZSo+L1x9W
FSvYsRhRe2vsVld51G1gyrXU5A18yWEw7axRULznb9DKRbIBXkZKhSIUYpOUMFkm
NXvclB2I1gosPfiOgV6CE39JWBEeHjQs1+qpbiNjgAevwclOfgl+a8aAxusgJK9U
VbHEfnmEfvKEtBLZoC08cKJ70CQnr8h7BSJ8j388zZgJQmgvQ11FUluR3+uhlvkG
oS2LGw+1Syra4sLMTSUE6tjT5W8wsNjO2mtle0pU/SC0bmDkv62ZYi88LB4P5B8Y
shLjyhzdq8YNShbk90gLQXnIWBaaKvWlvnq9GyIQvaZHaQtsqjh0YCbQwDasblLN
DK41BdfrByXBV6kkmU0+DkwceAMipVutIq+S5EufdElasJ9te6WSBBPPlprzbx08
8Y2i1y5J1H0+cLrQeRlpyXAGmq3IcCrdCmpihez2xty2FMhu8tvEyI9sg8jEsWNY
YGyogSN3Hf0XmN8Ujd6nMRi6IkSOQIxaq7kZDSjK1oo+zzE25NdPBip2aHLvVWpP
wL2C+UJsBzsJukRWDy5y
=q96O
-----END PGP SIGNATURE-----