On 2 Aug 2013 at 22:25, Mark Andrews wrote: > In message <51fb9c18.23133.401e...@tmorizot.sd.is.irs.gov>, "Scott Morizot" > wri > tes: > > 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).
> Because the requirement is *only* on the signer. You will note > that the validator is NOT required to check for this as part of the > list of things it is supposed to check for and that is a deliberate > design decision. If the signer follows this and the timing rules > the zone will not be treated as bogus. The unbound developers > didn't realise this initially and added unspecified checks to their > validator. I hadn't noticed the differences between 2.2 and 5.3. Interesting. So you can have signing errors (at least according to the standard) that don't result in validation errors. 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
