Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both
casey at deccio.net
Fri Aug 2 19:05:56 UTC 2013
On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews <marka at isc.org> wrote:
> In message <51FB9C18.23133.401EA34 at tmorizot.sd.is.irs.gov>, "Scott Morizot" wri
>> 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.
> Version 1.4.8 onwards should validate the zone. Earlier versions were
> broken. http://www.unbound.net/documentation/info_algo.html
Actually, while unbound has loosened their requirements as per the
reference above, they are still stricter than BIND--and RFC for that
matter, though the basis for their strictness is actually lack of
specification for some circumstances. There was a recent thread on
the unbound-users mailing list on just this topic and the same DNS
name (though I can't seem to get to the site over v4 or v6 at the
moment to reference it). RFC 6840 (DNSSEC clarifications) says the
following, paraphrased from section 5.11:
- all the algorithms in the DS RRset must be present in the DNSKEY RRset
- addition algorithms are allowed in the DNSKEY RRset, but not vice-versa
- the zone RRsets must be signed by all algorithms in the DNSKEY RRset
- a validator must support any valid path (i.e., don't require that a
path with all algorithms)
dfas.mil is violating the third rule above, which could potentially
hinder some implementations from creating a chain of trust all the way
to the RRset. unbound (capable of both algorithms in the DNSKEY
RRset) is violating the fourth rule above.
The second rule above is what creates the apparent underspecification.
What about validators that don't support the algorithm with which the
(extra) RRset is signed? Insecure delegations happen at the zone cut,
not mid-zone. A delegation might be "secure" because the algorithm at
the DS is understood, but if an additional algorithm from the DNSKEY
RRset is used to exclusively sign an RRset, the behavior is undefined.
IMO, the outcome would need to be "bogus" (as opposed to "insecure"),
but it's simply not defined.
More information about the bind-users