[Unbound-users] [DNSSEC] Resolver behavior with broken DS records

[W.C.A. Wijngaards]

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

Hi Stephane,

On 05/06/2011 04:09 PM, Stephane Bortzmeyer wrote:
> In an (involuntary) experiment under .FR, I discovered that the rule
> "at least one DS must match for a child zone to be authenticated" is
> wrong if a broken DS is present. In our case, the field Algorithm in
> the DS did not match the one in the DNSKEY. While there was another
> correct DS for the child zone, Unbound 1.4.6 servfails. So, the
> incorrect DS made the child zone bogus.

This should not happen, can you send me details, the DS records involved
(and perhaps the DNSKEY records) ?  They are of the same algorithm, I
assume?

Are you sure the other was correct?  If it was SHA1, then it could have
been ignored if the other was SHA256 (as per RFC).  Unbound only reports
the last error it encounters, it might have checked two but reported the
one.

> If there are DS and that one of them is dangling (going to an
> unexisting key) or unknown (new algorithm), Unbound validates if there
> is at least one DS it can process.

Yes that was the plan.

> I won't discuss the legality of this behaviour (my reading of the RFC
> on this point is that a resolver can do what it wants) but I believe
> that the current Unbound behaviour is:
> 
> * inconsistent: Unbound uses a "at least one DS" policy when there are
> dangling DS but a "all the DS" when there are broken DS.
> 
> * dangerous: a simple mistake in one of the DS will make the zone
> bogus.

It is certainly not what we want.

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

iQIcBAEBAgAGBQJNxP8uAAoJEJ9vHC1+BF+NMjUQAIIMbNktULCIe3RvWuIdezTU
ZL72FEgYwbEeg603Q1BIeuW6Q/yl5jIqz7oXjX0b5/PpsbN2f8QwVHG8cqh54Pzy
qKkmsvizgI3csHtOFO60IVb2AlyXzO+nSBt4SZ/7k/ocDXWl7CK/dhqR3NIUZtYT
yAEsq2SqHYBOptYi4+QFpzomachHaU9KKR0DCosp9sCmHdBaQXZyEhR+3aTjgIzm
UY7XGorklJGeSCEzro0uzZuYWYKC+VnBB36L1GZQlJPVRjF2Xi1qZN/FvL4Fhlw2
ogHIU3/Xo9+54t2LL1Dr52JEFjg5SBEJz4lZGmkmgmelQUSIKwGrPmIUtkDqrtaI
JZdlmkhghyB53CGhYxsyIrnFMFaTEVEKt10C48hCm/pfcTR8kWdHR2EgiQxFX8RZ
oaESIJ00+DhuGhK/Uq8XzIeGPlqWoAFmguY1uQfNQ42uy6uVDp8457N4ddPIdjqV
nN7cz9kEic0otrYFUTgQM1paLJNwc3P3M//aH6xZjHnAy4zGaXK2llliMlqPZ0tT
wjgMs2Cw+d97GdKcUrZOOXqIPpRl/A+o+WesZsiAMSJd6yTQBcg/ubqqjEt9kPET
qTK9IQkCY57aftj70eRrfKqHIFmWN2x7TylckfXlvtrM112PpZwLN601rvaFPswo
kRpDpCEBKA+KP//5gxux
=J1RP
-----END PGP SIGNATURE-----