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

[John Dickinson <[e-mail]>]

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.

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
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".
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?
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.



regards
John

---
[e-mail]

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

[phone]