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
---
j...@sinodun.com
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
