Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

[Scott Morizot]

Hello all,

I ran into an interesting situation resolving dfas.mil. It appears that 
they have attempted to roll their ZSKs to algorithm 8 while leaving their 
KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs 
for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for 
each record set in the zone MUST include at least one RRSIG for each 
algorithm. (The distinction between KSK and ZSK is an operational 
convenience and not part of the standard, per se.) The relevant excerpt 
from Section 2.2 of RFC 4035:

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

DNSViz and Verisign's DNSSEC debugger correctly report the error.

http://dnssec-debugger.verisignlabs.com/dfas.mil

http://dnsviz.net/d/dfas.mil/dnssec/

However, I discovered when I checked against DNS-OARC ODVR (and my own 
personal validating recursive nameserver at home) that BIND 9 apparently 
doesn't correctly enforce that requirement.

https://www.dns-oarc.net/oarc/services/odvr

The BIND 9 resolver returns an answer with the AD bit set. Unbound 
returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the 
only three nameservers I've tested.

It looks like a validation bug in BIND to me, but I thought I would see 
what others thought. It's probably a pretty rare situation, since I can't 
imagine most people who choose to use separate KSKs and ZSKs would try to 
migrate only their ZSKs to a new algorithm while leaving their KSKs at 
the old algorithm.

Thanks,

Scott