Re: [DNSOP] On obsoleting DNSSEC RFCs; Example from RFC 4035 (2)

[Viktor Dukhovni <[e-mail]>]

> On Nov 11, 2019, at 2:39 PM, Дилян Палаузов <[e-mail]> wrote:
> 
> Does it make sense to generate RRSIG for the ZSK and why 1/3 of the DNSSEC
> enabled sites [sample size of 3], maintaining DNSSEC enabled DNS servers do it?

While it makes sense to keep DNS RRsets as small as possible,
to avoid UDP fragmentation issues, there is no prior restraint
on signing the DNSKEY RRset also with the ZSKs.

Therefore, while avoiding redundant signatures can be seen as
a best-practice it is not presently a requirement.

If you're looking for guidance on whether your DNSKEY RRsets
should be signed also with the ZSKs, the answer is generally
"no".

You're typically better off signing them with just the KSKs
(keys with the SEP bit set in their flags), provided it is
these same KSKs that match the DS RRs in the parent zone.

IIRC the SEP bit in the key flags is only a hint (generally
valid) that the key is (was, or is intended to be in the
future) one of the ones matching a DS RRset at the parent.
Ultimately, one or more key matching the DS RRs signs the
DNSKEY RRset, and one or more keys that appear in the DNSKEY
RRset sign the rest of the RRsets.

Algorithm agility means that validators may ignore some
weaker algorithms or keys in the presence of stronger
algorithms, which may necessitate signing with more than
one key in some cases, to accommodate both validators
that prefer stronger keys and validators that don't yet
support the stronger keys.

The rule of thumb is that each key algorithm that appears
in the DNSKEY RRset, should also be used to sign each RRset
with at least one key of that type.

Thus, for example, when removing a signing algorithm, one
should first remove the DS RR, then the KSK and finally the
ZSK.  When adding a new algorithm, first add a ZSK, then a
corresponding KSK, and finally the DS.  In both cases with
various delays in between to allow updated records to displace
stale cached data.

I should perhaps also note that recently many zones employing
ECDSA P-256 (algorithm 13) have dispensed with having a separate
KSK and ZSK and use the KSK also for zone signing.  Their DNSKEY
RRset has just one key.  With RSA one generally wants a 2048-bit
"long-term" KSK and a shorter (1280-bit perhaps) ZSK that should
be rotated more frequently.  A 2048-bit ZSK would result in NSEC
and especially NSEC3 response sizes that exceed recommended UDP
response size limits.

KSK == ZSK is a valid choice for ECDSA P-256 that also keeps
the DNSKEY RRset reasonably small.

The single KSK == ZSK count is quite visible in my DNSSEC survey:

  https://stats.dnssec-tools.org/#parameter

    * 3477400 algorithm 13 "KSKs" ((flags & 257) == 257)
    * 2016046 algorithm 13 "ZKSs" ((flags & 257) == 256)

The 1.46 million domain discrepancy is domains with just one key.
 
-- 
	Viktor.