[Unbound-users] "harden-referral-path" returns SERVFAIL on subsequent queries

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hauke,

Some testing, I reproduced and fixed a bug in svn r1657.
The bug was that on a second validation pass a message lost the secure
status, and this caused dlv lookups to abort, with SERVFAIL to the user.

This issue may also have impacted your other question.  The fix is in
the subversion trunk of the code.

Hauke Lampe wrote:
> Hello.
> 
> I know referral path hardening is an experimental feature. But when
> testing new software, I always like to see what all the knobs and
> switches do and how they work, where they help and, especially, what
> they break and what the symptoms are, so I can recognize it easier.

Yeah!

> Disabling *either* "harden-referral-path" or "dlv-anchor-file" fixes the
> problem.

Yes, it causes different recursion order of processing if you have them
both, with more likely to pickup things from the cache and show them to
the validator again.

> This is with Unbound 1.3.0. The authoritative servers for my subdomain
> run tinydns, BIND 9.6 and NSD 3, although the result is always the same,
> regardless of which server Unbound queries.

Good

> What stands out to me is that Unbound always queries for both the A
> record and the DLV record. Shouldn't it have cached the NXDOMAIN answer
> to the DLV query earlier? It never does this for other records with low
> TTL (like frell.ath.cx). Also, "resolving" is actually the last entry,
> there are no "reply" and "query response" entries following it. Indeed,
> tcpdump shows only the A request going out, no query for the DLV record.

Yes it says resolving, but then does not print anymore because it is
processing results from the cache.  Maybe 'internal recursion to this
name' could be a better term to print, but that is so long.

> I can resolve other names in the zone (ie. mail.frell.ambush.de) and
> always get the same behaviour. The first query suceeds, subsequent
> queries (after the initial TTL expired) all fail.

Thanks for the report,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAko2UNkACgkQkDLqNwOhpPi7RACfSr1KaMCtDNaWRCN7m6iJwsxo
9e4AoIdZfJll+gmx0zaVB28Yho/5FxP7
=HMjY
-----END PGP SIGNATURE-----