Setting harden-algo-downgrade: yes violates RFC 6820 Section 5.11.

In fact, the setting was introduced because the non-compliant behavior was Unbound's default, and the setting provided a workaround for that bug. Later in 2015, the setting was changed to no by default, in accordance with the spec.

The name of the setting is a misnomer. It does not "harden" against algorithm downgrade; it rather imposes obscure requirements on signature presence that, in some cases, can be the opposite of "hardening".

Reading the code a while back, I found that what it really does is the following:

1. Looking at the DS record set, it extracts the record(s) which have the highest digest type in the set.
2. It then requires responses to have valid signatures from all signing algorithms mentioned in that subset of DS records.

Now consider a DS record set like this:

example.com.  IN DS  12345  5 3 ...
example.com.  IN DS  12345  5 2 ...
example.com.  IN DS  56789 13 2 ...

In this case, step (1) would throw away the two records with digest type 2, and only consider the first one, which has digest type 3 (and that is larger than 2). As a consequence, the setting would require signatures from key 12345 (which is of the deprecated signing algorithm 5). A signature of key 56789 (of much better & recommended algorithm 13) would be ignored.

The misconception here is that "higher digest type" does not imply "more secure". Not only would that assumption be incorrect on its own (in fact, digest type 3 is considered less secure than 2); it also does not make sense given the fact that not all keys have to be referenced with all digest types, that is: the digest type value is not a meaningful proxy for selecting strong signing algorithms.

After I pointed this out to Unbound developers, they changed the documentation, which now correctly describes the selection process and also says:

It should thus be explicitly noted that this option violates RFC 6840 for DNSSEC validation and should only be used to perform a signature completeness test to support troubleshooting.
Warning: Using this option may break DNSSEC resolution

And indeed, the setting continues to cause validation failures and user confusion.

The setting further is incompatible with multi-signer setups using a new set of rules currently discussed at the IETF.

I'm writing down all these arguments to make it really clear that using this setting is a mistake. It is a historic artifact from and old bug. (It would be best if it were removed altogether, but that's nothing for this project.)