> On Nov 11, 2019, at 2:39 PM, Дилян Палаузов <dilyan.palau...@aegee.org> 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
