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

["Dickson, Brian" <[e-mail]>]

On 7/8/13 2:28 PM, "Patrik Fältström" <[e-mail]> wrote:

>I have also had a look at this document which I in general do believe is
>sound, although there are a few events I would like to have described in
>the document. Reason for this is that I see it being really important
>that it is implemented the same way in all usage scenarios.
>
>One such situation is what is to happen when NS records changes in the
>parent zone.


I think, perhaps, that a corresponding mechanism for NS change (or change
validation), will be what we eventually conclude is also a good idea (or
even necessary to provide some means of protection/validation to an
otherwise unprotected-but-critical element).

For the same kinds of reasons as parent/child DS vs DNSKEY "mismatch"
(pre-publication of DS without publication of DNSKEY), there are reasons
that parent and child NS sets are not always the same.

So, using the child NS set to directly validate the parent NS set is a
non-starter.

However, maybe something like a "PNS" (parent NS) in the child, where the
child is authoritative for the data, could signal {change | validation}
(depending on the RRR requirements), would do the trick?

Upon receiving a change request for the NS set, the zone publisher could
check the child for matching PNS records.

Facilitates automation, just as CDS would.

Thoughts?

Brian


>
>An immediate reaction is that change of NS records should trigger fetch
>of CDS record from the child zone so that the new DS can be included in
>the new version of the zone that have the new NS records. Careful
>thinking should say whether that is a correct thinking of me.
>
>Another situation is what to do (by the parent) when inconsistent CDS
>records are found from the authoritative servers for the zone (with and
>without identical serial numbers in the SOA).
>
>And a third if the auth servers queried at should be the ones that there
>are NS records for in the parent zone or the NS records that exists in
>the child zone.
>
>This to resolve inconsistencies between information in parent and child
>zones and between auth servers.
>
>Lastly, I think it should be very clear not only what the priority is
>between different versions of CDS records, but also between CDS records
>and epp commands. If different registries implement different policies
>here, the world might risk being much messier than what we want.
>
>Hope this helps.
>
>   Patrik
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop