Maintained by: NLnet Labs

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

W.C.A. Wijngaards
Thu Apr 29 16:29:07 CEST 2010


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

Hi Zbynek,

Which version of unbound is this (1.4.4?)

I have just made fixes to svn trunk that may help in this case.  But
they may not be sufficient to help you here (its about looking in the
key cache to see if nic.cz needs DNSSEC).

Can you do an unbound-control lookup nic.cz  (when it is in the bad state) ?

On 04/29/2010 03:11 PM, Zbynek Michl wrote:
> I am experiencing a problem with validation of signed domain names. When
> I start Unbound, validation works fine. But when I put resolver under
> extreme load (thousands queries per second), I get SERVFAIL reply on
> every correctly signed domain query after some time.
> 
> It is probably caching bug, because if I restart Unbound or wait some
> time, then Unbound responses correctly again.
> 
> Here is log of validating A type query for www.nic.cz when Unbound is in
> the "strange" state.
> 
> --- LOG ---
...
> 
> The error that can be seen above is:
> 
> "info: no signer, using <www.nic.cz. TYPE0 CLASS0>"
> 
> and then
> 
> "info: validation failure <www.nic.cz. A IN>: key for validation
> www.nic.cz. is marked as invalid because of a previous validation
> failure <www.nic.cz. A IN>: no DNSSEC records from 193.29.206.1 for DS
> www.nic.cz. while building chain of trust"
> 
> Yes, because resolver should query 193.29.206.1 for DS nic.cz., not
> www.nic.cz.
> So it seems, that Unbound can not parse signer's name from the
> appropriate RRSIG that is cached, because there is no Unbound's query
> for the RRSIG on the network at this time.

The issue is that it gets no DNSSEC data for nic.cz.  Assuming that is
normal, then the errors above are also normal, so its can parse the
RRSIG fine, but it just does not get one.  What really happens is that
it gets no RRSIG and assumes this must be because www.nic.cz is an
unsigned subzone of nic.cz, and starts searching for that proof - a
query for the DS denial for it - but this also does not work.

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

iEYEARECAAYFAkvZl7MACgkQkDLqNwOhpPj2mgCgpdbdqoV2CgIe/0ov8sB+poWe
9IMAn3kBrKY/CzaWtafFedEFOMVeo6+u
=8Rn0
-----END PGP SIGNATURE-----