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

[W.C.A. Wijngaards]

-----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-----