John,
Thanks for a excellent and timely review we just about pushing out a new
version when it arrived.
We have accepted most of your edits and suggestions except when the text was
already removed/reworded.
Instead I want to focus on your Q1: "How will a ``Child'' know if the
``Parent'' is doing CDS?"
IMHO, we need to figure out how/if to place a flag in parent saying what kinds
of "sync" it is willing to do from signed children.
Olafur
On Jul 8, 2013, at 7:54 AM, John Dickinson <[email protected]> wrote:
> Hi,
>
> I have read draft draft-kumari-ogud-dnsop-cds-02. (Unfortunately, I have not
> had time to read all the on list discussion, so apologies if I duplicate
> comments)
>
> IMHO:
>
> Section 1.2 and 2.2.1 (Highlighted roles) should be combined and used
> consistently through-out.
>
> Section 2.1 refers to parties, section 2.2 refers to entities. One should be
> chosen and added to 1.2/2.2.1.
>
> 2.2:
> - last instance of the word organization should be plural
> - s/same as operates the enterprises DNS servers/same as that which operates
> the enterprises DNS servers/
> - "A domain name holder (child)" - It is not immediately obvious if this is
> the
> child defined in the subsequent section.
>
> 2.2.1:
> - Remove the "word" DNS from the end of both DNS operator definitions.
> - s/clutural/cultural/
> - s/child delegation/Child/
>
>
> 2.3:
> - s/In number/In a number/
> - s/A further complication is when the DNS Operation is separate from the
> Registrant./A further complication is when the Child DNS operator is not the
> Child./
> - The sentence, "There are two common cases of this, registrar handles
> the DNS operation and a third party takes care of the DNS operation." would
> be clearer if it read something like "There are two common cases of this
> a) the registrar handles the DNS operation or b) a third party takes care
> of
> the DNS operation."
> - reorder the following sentences to reflect the order a,b above.
> - "the Registrant either needs to relay changes in DNS delegation" are we
> changing the delegation (implies NS to me)?
> - "we will use the word "Child Operator", is this the same as Child DNS
> operator
> defined in 2.2.1? Also s/word/phrase/
>
> 2.4:
> - "After a DNS operator first signs its zone" whose zone, which DNS operator?
>
> 3:
> - First paragraph has nothing to do with the CDS (Child DS) record definition
> and should be (re-)moved.
>
This paragraph was moved to background section.
> 3.1:
> - Add a reference to the DS wire and presentation format. Also is there a
> need
> to give a reference for the RR code?
>
> 3.1.1:
> - Given the difficulties that can occur with going unsigned, I think this
> section should be removed.
>
> 4.1
> - much of the text in this section is not really about CDS Publication. The
> first
> sentence talks about consumption as does the final paragraph. Remove all text
> except the Location, Signer and Continuity sections. Keep the text "the
> absence of CDS record signals "No change" in the current DS set. The use of
> CDS is optional." Remove the MUST from Continuity - You can not tell a
> child
> DNS operator not to break their or their customers own zone - It might be a
> bad idea, but if that is what they want to do then so be it. It might be
> better if Continuity was at least in part the parents responsibility
>
> 4.2 and 4.3
> - Move the final paragraph of 4.2 to section 4.1
> - Move the third paragraph of 4.3 to section 4.1
> - I dislike the wording in these 2 sections especially the
> term, "Parental Agent" who is this in 1.2/2.2.1?
> I suggest the following text:
> --------------------------------------------------------------------------------
> 4.2. CDS Consumption
>
> 4.2.1 Detecting a changed CDS
> How the Parent DNS operator (or registrar??? I will just use the term
> Parent DNS operator from now on) detects changes to a CDS record may
> differ,
> below are two examples of how this can take place.
>
> Polling The Parent DNS operator operates a tool that
> periodically checks each delegation that has a DS record to see
> if there is a CDS record.
>
> Pushing The Parent DNS operator in its user interface has a button
> {Fetch DS} that when pushed initiates the CDS processing. If the
> Parent zone does not contain a DS for this delegation then the
> "push" MUST be ignored.
>
> In either case the Parent DNS operator may apply additional rules
> that defer the acceptance of a CDS change, these rules may include a
> condition that the CDS must remain in place and valid for some time period
> before it is accepted. It may be appropriate in the "Pushing" case to assume
> that the Child is ready and thus accept changes without delay.
>
> If the CDS RRset does not exist, the parent MUST take no action.
> Specifically it MUST NOT delete or alter the existing DS RRset.
>
> 4.2.2 Using the new CDS
> Regardless of how the Parent DNS operator detected changes to a CDS RR, the
> Parent DNS operator MUST use a DNSSEC validator to obtain a validated CDS
> RRset from the Child zone. It would be a good idea if the Parent DNS
> operator
> checked all NS RRs listed at the delegation. However, due to the use of
> technologies such as load balancing and anycast, this should not be taken
> as
> proof that the new CDS is present on all nodes serving the Child zone.
>
> The Parent DNS operator MUST ensure that old versions of the CDS RRset
> do not overwrite newer versions. This MAY be accomplished by checking that
> the signature inception in the RRSIG for CDS is newer and/or the serial
> number on the child's SOA is greater. This may require the Parent DNS
> operator to maintain some state information.
>
> The Parent DNS operator MAY take extra security measures. For example, to
> mitigate the possibility that a Child's key signing key has been
> compromised.
> The Parent DNS operator may, for example, inform ( by email or other
> methods ) the Child DNS operator of the change. However the precise
> out-of-band measures that a parent zone SHOULD take are outside the
> scope of this document.
>
> Once the Parent DNS operator has obtained a valid CDS it
> MAY double check the publication rules from section 4.1. In particular the
> Parent DNS operator MUST double check the Continuity rule and do its best
> not
> to invalidate the Child zone. Once checked and if the CDS and DS ``differ''
> it may apply the changes to the parent zone.
>
> --------------------------------------------------------------------------------
>
> section 4.3 no longer exists
>
> 4.4
> - Again terminology is a bit inconsistent
>
> General Comments:
> 1. How will a "Child" know that the "Parent" is 'doing" CDS?
> 2. Section 4.4 makes this situation worse in requiring The DNS Parent to
> publish
> guidelines for the children as to what digest algorithms are acceptable
> in the CDS record
see above.
> 3. Given the vast range of possible interactions described in 2.2.1 I am not
> sure that this is any better than a child sending an "update".
Open issue "where to send update to?"
> 4. Maybe I have missed this discussion, but, would it be better if
> the "Child" published a "CDS" containing the DNSKEY and left it up to
> the "Parent" to digest?
Religion issue, CDS is 'easier' to compare than DNSKEY
> 5. I know I am biased! There is no discussion of key timing. I think
> that 4.1 should contain at least a reference to at least one of
> the excellent (expired but could be resurrected) drafts on the subject.
>
good suggestion, added reference
>
>
> regards
> John
>
> ---
> [email protected]
>
> http://sinodun.com
>
> Sinodun Internet Technologies Ltd.
> Stables 4, Suite 11,
> Howbery Park,
> Wallingford,
> Oxfordshire,
> OX10 8BA,
> U.K.
>
> +44 (0)1491 834957
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
