Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

Scott Morizot tmorizot at
Fri Aug 2 13:00:32 UTC 2013

On 2 Aug 2013 at 22:25, Mark Andrews wrote:
> In message <51FB9C18.23133.401EA34 at>, "Scott Morizot" wri
> tes:
> > Hello all,
> > 
> > I ran into an interesting situation resolving 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.



More information about the bind-users mailing list