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.
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.
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.
Hi Stephane,
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
Stephane sent me details off-list. Turns out to be the RFC4509 rules
that unbound follows, that intends to avoid downgrade attacks. Here it
caused a failure though one record was correct.
Best regards,
Wouter
Zitat von "W.C.A. Wijngaards" <wouter@NLnetLabs.nl>:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
Stephane sent me details off-list. Turns out to be the RFC4509 rules
that unbound follows, that intends to avoid downgrade attacks. Here it
caused a failure though one record was correct.
That means higher grade hashes were invalid and no fallback will be done to the lower grade in this case?
Regards
Andreas
a message of 34 lines which said:
That means higher grade hashes were invalid and no fallback will be
done to the lower grade in this case?
Correct. And this seem to be on purpose (to avoid a downgrade attack
altough, in typical DNSSEC fashion, this will break a valid zone
without enhancing security).