In message <CAEKtLiT9=m1nbfjq2ormrdqr2uprjhcx9lznkxsytzv4tdj...@mail.gmail.com> , Casey Deccio writes: > On Fri, Aug 2, 2013 at 5:25 AM, Mark Andrews <ma...@isc.org> wrote: > > > > In message <51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov>, "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 listed requirement is the signer signs with all key algorithms. This is per instance of the zone. There is no requirement that all visible sources of zone have signature for all key algorithms published in all visible instances of the zone. There is no requirement that one apparent source of the zone present a single instance of the zone only that a single answer comes from a single instance. Unless you can see the full contents of a instance (i.e. be able to transfer the zone) of the zone you cannot check if the signer is correctly operating or not. There is no other way. > 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? The ignore those records. They DO NOT care if they are there or not. > Insecure delegations happen at the zone cut, not mid-zone. Correct. > 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. Which is why there is a requirement on the signer. There is no requirement on the validator to check that the signer did the correct thing. If a signer makes this mistake then some validators will treat the records being signed as good (those that support both algorithms) and some will treat it as bogus (those that only support the algorithm in the DS set). You would like to see consistancy when rules are not followed. The specification does not give that and does not require that. It is designed to give consistency when the rules are followed. In this instance all the records in dfas.mil are signed with algorithm 7. The DS records are for algorithm 7. There are algorithm 7 and 8 dnskey records visible. A validator that only supports algorithm 8 treats this zone as insecure as there is no DS record which lists agorithm 8. A validator that only supports algorithm 7 treats this zone as secure as there is a DS record that lists algorithm 7. It expects to see RRSIGs with algorithm 7. A validator that supports algorithm 7 and 8 treats this zone as secure as there is a DS record that lists algorithm 7. It expects to see RRSIGs with algorithm 7. If the validator is operating correctly will pass the answers from this zone. The operator of the zone is required to wait until all caches are clear of answers which only contain algorithm 7 records before publishing a DS record with algorithm 8. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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
