-----BEGIN PGP SIGNED MESSAGE----- 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, Wouter 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 nic.cz is sent to 194.0.12.1 (without DO bit), replied DS > is not validated due to missing its RRSIG and 194.0.12.1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvf33cACgkQkDLqNwOhpPgwcwCeLSmiLxzpRZbPDfzRZwMMDqmI EjsAoKioC7qmqZBePZ86Wn1i7Emb1ie5 =x4SU -----END PGP SIGNATURE-----