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

[Antoin Verschuren <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 08-07-13 20:28, Patrik Fältström schreef:

> One such situation is what is to happen when NS records changes in
> the parent zone.
> 
> 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.

Why would DS records change when NS records change?
I guess you're thinking only one scenario here, and that is when NS
records change, the DNS operator of the master changes and the zone
will get different key material. But this is not the general case,
only the most difficult one to solve. Only changing one slave NS by
another does not change the operator maintaining the key material.

Changing the operator maintaining the key material does happen, and
when it does, changing the DS after changing the NS will not help you
autoprovision. The zone will get bogus if you change the DS after
changing the NS, and so no CDS change can be validated at all.
Changing the key material operator needs pre-publishing of the new key
material in the zone of the losing operator for the NS change to be
validated. The new NS RRset in the child is signed with the new key
material only.
I know you all wish the world was simpler, but it isn't, We've tried.

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

I agree with Andrew here that the NS RRset in the child zone is
authoritative, but it can only be used if validated.

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

Exactly my statement.


- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: [phone]  M: [phone]
Mailto: [e-mail]
XMPP: [e-mail]
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJR27+5AAoJEDqHrM883Agn4wsH/1xXv9FkndogVEbzUQdLZhLD
XB7JqT1QmKATKf+Ec6Rp1RLsA6QgA8XvyZOSzlUM/jEGARtldp1YncPsue/FO7an
oRaTi/vk4o1rR+e8A/LKZvl0Ix0RbVZ+yA2NS+TtXCKm/eMJOjZy5TA9oNwINhfA
55d+V+jVro5rdfNO8yRflpe+Np3M9AOWmPdTgLTlw6axwvh8bZeJJ4jHjmrxpQWm
GhXpVuRztG1+TJP+zBStKNNvvnMFps7oL3fdb+UlbI67f7KSpSfG4eyw3GSO/poA
0XF6nOfWZD/QFQoBIq8gWi4od2J9ImOcgsrCofnT+CdOP9+IBzQiYQqKxZHeDH0=
=34D4
-----END PGP SIGNATURE-----