On 9 jul 2013, at 09:46, Antoin Verschuren <[email protected]> wrote:
> Signed PGP part > 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. I am only saying change of the NS record should _trigger_ a fetch of the CDS. If the CDS has not changed, then the DNSSEC data in the parent should not change. > 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. The registry get an EPP update via a secure channel to change the NS. They can at that time (before the new zone is published) issue queries for CDS at the suggested new target of the NS, and if the CDS exists there they can fetch the CDS, see if key material changed, and incorporate the data in the zone that is to be published. > 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. For newcomers to this discussion, Antoin and myself is in the middle of this discussion about how to do a change of DNS operator (and because of that change of maintainer of key material) in reality. We have, as you can see, different opinion on the topic :-) > > 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. But it can be validated thanks to the trust in the epp channel. > > 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. Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
