On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews <[email protected]> wrote: > > In message <[email protected]>, "Scott Morizot" > wri > tes: >> 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. Casey _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
