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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
