Maintained by: NLnet Labs

[Unbound-users] Validation failure of DNSSEC signed domain names

W.C.A. Wijngaards
Tue May 4 10:48:55 CEST 2010

Hash: SHA1

Hi Zbynek,

Can you try with the svn trunk r2107?  I have made a bugfix which may
help, it stops unbound from disabling its dnssec expectation after it
has seen a response fail without rrsigs.  This could turn into a long
causation chain: dnssec expectation lost, therefore EDNS backoff
possible (with timeouts happening), therefore EDNS backoff stored in
cache, stopping it from sending DO bits (and a bug fixed in r2106 where
this fact got 'stuck' into the cache).

After discussion with my colleague I think this fix may help... The
evidence you kindly provided supports the hypothesis and this fix should
stop it from failing continuously (but a single query still fails).

Also, I believe there to be some trouble with your setup, which is
causing unbound to have slower turnaround; can you email me (offlist if
you want) your configuration (unbound.conf and what is your ulimit(open
files) for unbound, did you compile with libevent) ?  I think this
slower turnaround exists because you have that failing query.

Best regards,

On 04/30/2010 06:32 PM, Zbynek Michl wrote:
> So in the "strange" state the resolver does not send queries with DO
> bit, thus does not receive RRSIG for query type and therefore it can not
> validate result. Then the remote authoritative server (who sent answer
> without RRSIG) is added to the blacklist.
> In the log (complete version has been sent in previous mail):
> Request for DS is sent to (without DO bit), replied DS
> is not validated due to missing its RRSIG and is blacklisted.

>>> Hmm, r2106 experiences the same issue :(
>>> It seems that there is no exact change between correct/incorrect
>>> validation in the one time point. On the start there are all answers
>>> correct, and when I am trying more and more (different in a few cycles)
>>> requests, then there are more and more incorrect answers. And in some
>>> time point all answers are incorrect from the resolver until cache is
>>> flushed (probably).
>>> Regards,
>>> Zbynek
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -