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

Op 09-07-13 10:05, Patrik Fältström schreef:
> 
> 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.

That CDS record will not validate at that point in time, so it will
always be ignored.
The pre-requisite for CDS is that the record can be validated, and the
new zone is not yet in the chain of trust if the DNSKEY RRset that is
present in the validating resolver does not contain the key by which
the CDS record in the new zone is signed.

You could do a theoretical validation of that record with the assumed
future state of the zone and delegation at the parent, but all
validating resolvers in the real world will have a DNSKEY RRset cached
from the past, and are not aware of any future change until after it
has happened. So during the DNSKEY TTL all records that should
validate against the DNSKEY RRset will have a chance of being bogus,
depending on from which zone the signatures come and which DNSKEY
RRset is cached..
Unless you have pre-published a DNSKEY RRset that contains the ZSK's
of both zones, so both signatures validate.

But then there is no need to query the CDS record, because you cannot
do a simultaneous second key rollover during a key maintainer change.
You'll have to wait at least one child NS TTL after the NS change at
the parent until it's safe to remove the old key and do another key
rollover, so querying CDS immediately after changing the NS at the
parent will always result in zero changes if you want your zone to work.


- -- 
Antoin Verschuren

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

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email protected]
XMPP: [email protected]
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJR295eAAoJEDqHrM883AgnFC4IANZXG6Rl8HB3U6U7UZS3URxf
ham8o3+5hi9nx1s1KN4zljBWjnL0O0N2jBK+keSWLHLmmWzinFMjtHEv4RFaE9Ho
++jC0kZT2Z0Re65A2ZOh9lewpSvzBul9axcrD10w/yehVJhm5L4mAOhoL29dsegv
PMsHpqDy1DJ0MvWrx+wdzGKTCG0S79SAbUedt0kLPt8tH0FFMAFUON1yFj3cYp2W
ovpWGN1R0ex7g66CCSBWcx5otp8GJx1wIs1pra1xt3QmhOHTxKzGkuRIUjRRpMf7
AoogKu6i1LnxFVwGmlZab2Gebkx0g5aY3whrxZ65g30Wn1kPcFS1QBeHrQO+vDI=
=A5ER
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to