Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

[Olafur Gudmundsson <[e-mail]>]

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 <[e-mail]> 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
> 
> ---
> [e-mail]
> 
> http://sinodun.com
> 
> Sinodun Internet Technologies Ltd.
> Stables 4, Suite 11,
> Howbery Park,
> Wallingford,
> Oxfordshire,
> OX10 8BA,
> U.K.
> 
> [phone]
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop