Hi,
I support publication of this document, but I agree that some things
should be improved before its ready to do so. Mainly the RFC2119
language (raised by Patrik), the rule of removing the CDS/CDNSKEY RRset
at the child and missing/no clear guidelines to prevent "DS flapping".
Besides some nits which I will send the editors off-list, here are my
comments:
2.1. DNS delegations
But this
fails to meet some operating needs, including the child having no
influence what DS digest algorithms are used and DS records can only
be published for keys that are in the DNSKEY RRset.
The reason why that is bad is because it then would not be compatible
with the Double-DS key rollover method. Perhaps it is good to add that
explicitly.
4.1. CDS / CDNSKEY processing rules
If there are no CDS / CDNSKEY resource records in the child, this
signals that no change should be made to the current DS set. This
means that, once the child and parent are in sync, the child DNS
operator SHOULD remove all CDS records from the zone.
I would rather see MAY here, having the retain RRset be the normal case,
agreeing with Patrik Faltstrom earlier comments.
Following acceptance rules are placed on the CDS / CDNSKEY records as
follows:
o Signer: "MUST be signed with a key that is represented in both the
current DNSKEY and DS RRset's."
In other words: The CDS and CDNSKEY RRsets MUST be signed with an active
KSK. This introduces new tasks for keys that have the role of KSK. In
current software, a KSK only signs the DNSKEY RRset. Basically, with
this rule you are extending the role to also sign the CDS and CDNSKEY
RRsets. I am fine with that, they all are there for the same main
purpose: maintaining the chain of trust. But I think this can be
mentioned more explicitly in the document.
Now do we also require the ZSK have signing these RRsets? I don't think
so. So also the signing rules for ZSKs can be adjusted.
5. Child's CDS / CDNSKEY Publication
A child MAY publish both CDS and CDNSKEY. If a child chooses to
publish both, it MUST attempt to maintain consistency (a matching CDS
for each CDNSKEY).
Another weak RFC2119 requirement: MUST attempt. I think you have to get
rid of the word attempt.
6.2. Using the new CDS / CDNSKEY records
Regardless of how the Parental Agent detected changes to a CDS /
CDNSKEY RR, the Parental Agent MUST use a DNSSEC validator to obtain
a validated CDS / CDNSKEY RRset from the Child zone. It would be a
good idea if the Parental Agent checked all NS RRs listed at the
delegation.
Patrik already asked what the RFC2119 equivalent for 'good idea' would
be. Perhaps this is a SHOULD. This way the parental agent can be more
sure of things being in-sync at the child name servers.
The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
RRset do not overwrite newer versions. This MAY be accomplished by
checking that the signature inception in the RRSIG for CDS / CDNSKEY
is newer and/or the serial number on the child's SOA is greater.
This may require the Parental Agent to maintain some state
information.
Or use the good idea from above, to prevent maintaining state.
Best regards,
Matthijs
On 04/02/2014 09:07 PM, Tim Wicinski wrote:
> Greetings,
>
> This is the starting of the WGLC on Automating DNSSEC delegation trust
> maintenance. This was briefly covered in London and these are ready for
> WGLC. The current versions of this documents can be found here:
>
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
>
> http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt
>
>
> We'll have a 2 week period for comments, closing on April 16th, 2014.
>
> thanks
> tim
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
