Re: New Version Notification for draft-gieben-epp-keyrelay-00.txt

Antoin Verschuren <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 25-01-13 15:22, Patrik Fältström schreef:
> 
> If you look at the epp commands, in reality the change of NS (and
> dnssec data, i.e. DS) in parent zone is made by one and only one
> registrar. Either it is made by the gaining or donating registrar.

Agreed

> I think you should explain in what order various things happens.

This is described in draft-koch-dnsop-dnssec-operator-change-04.
This EPP draft only describes the missing EPP command that does not
exist today and is needed as one of the steps in
draft-koch-dnsop-dnssec-operator-change-04. We need to get a key from
the gaining to the losing DNS operator.

> If you have two DS in the parent zone, and only one of them can
> validate the KSK, ZSK and signature, is that a failure?

Not to me.

> Ok, I now understand where the disagreement is. I do not think it
> has to move.

You are wrong.

> The trouble is to have a gaining registrar add a DS while keeping
> the old DS, and then only removing the old DS when one is pretty
> darn sure the zone data for the old zone has expired in all
> caches.

We should discuss this on the dnsops mailinglist.

> But I promise to talk with Peter Koch next time I meet him so that
> I get told that I am wrong :-)

Peter has writen down the text for the draft, but the issue originates
with me, so I can answer as well.

The problem is that a cache may have cached the DNSKEY RRset from the
old zone, and while that is still valid the NS RRset changes at the
parent and the resolver recieves a new NS (or other) RRset from the
new child zone with a new signature from the new ZSK that is not
present in the cached DNSKEY RRset thus failing validation. This can
only be solved if both DNSKEY RRsets contain both ZSK's from the new
and old child zone. Same as you would do with a pre-publish ZSK rollover.

Transferring and keeping the old zone data on the new nameserver does
not help, because at some point in time, at least the NS RRset needs
to change and a new signature needs to be generated over it by a new
ZSK that is not present in the DNSKEY RRset. A signature with the old
ZSK over this new NS RRset cannot be generated because the old private
ZSK is not available for signing by the new operator.

Further discussion on this please on the dnsops mailinglist.

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

iQEcBAEBAgAGBQJRAqT4AAoJEDqHrM883Agnum8H/0FYNE40Xa6t0q0euWWZYW/0
onhPlIrE+BRNpHfxtneIeiPIYOqzjbiAhJAu08ueBuwz0rxBGRHe+MSjpUKbe4vw
Y9e4CM4PqlZuRzwwIFcLhipWqaaDCsFslurJirfJ+PL1C1vxTfLcUpXa3aDOEPfI
IJ5ejHXktX2skmnTlaD/kyTnB9EWuDVAoAvzyl0cC9DG4U2/ac6c9cRsG8BIYCMI
twCurvy2SK1K4SGjhNwDoMEZGIQfHSJqpI0uUHyL//GzrX5s4/aT3ybwa5q1QpIo
BG7kdCJV6jmeFO5UP+q9g25lrly/EveZe3iI2rQTgbDloOfh487P5DFU4U6to4U=
=aHCZ
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.