Hello Daniel,

We don't have a strong reason for signing CDS/CDNSKEY RRset with a ZSK.
I would agree with your interpretation of the RFC and it also makes more
sense to me. So we will probably change it after a discussion with my
colleagues.

Regards,
Daniel

On 2018-03-19 17:03, Daniel Stirnimann wrote:
Hello all,

I noticed that Knot (2.6.5) creates an RRSIG for the CDS/CDNSKEY RRset
with the ZSK/CSK only.

I was wondering if this is an acceptable behavior as RFC 7344, section
4.1.  CDS and CDNSKEY Processing Rules states:

   o  Signer: MUST be signed with a key that is represented in both the
      current DNSKEY and DS RRsets, unless the Parent uses the CDS or
      CDNSKEY RRset for initial enrollment; in that case, the Parent
      validates the CDS/CDNSKEY through some other means (see
      Section 6.1 and the Security Considerations).

Specifically I read that "represented in both the current DNSKEY and DS
RRsets" means that the CDS/CDNSKEY RRset must be signed with a KSK/CSK
and not only with a ZSK and a trust chain to KSK <- DS.

I tested both BIND 9.12.1 and PowerDNS Auth 4.0.5 as well. PowerDNS Auth
behaves the same as Knot 2.6.5 but BIND 9.12.1 always signs the
CDS/CDNSKEY RRset with at least the KSK.

Do I read the RFC rule too strict? To be honest, I see nothing wrong
with the CDS/CDNSKEY RRset only signed by the ZSK but BINDs behavior and
the not so clear RFC statement keeps me wondering.

Thanks,
Daniel
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Reply via email to