Re: Example of stupid inconsistencies between registries

I'm not sure why as a DNS operator I would want to either send a ZSK (signed
by my KSK) or receive a ZSK signed by a KSK I don't control through the
domain registry.

I tend to think this should stay between the two DNS operators, as the keys
are being managed in the delegate zone, all the TLD zone should care about
is that whoever controls the domain has submitted what they consider to be a
valid DS.  As Patrik said, if the registry wants to be generous, it can
validate the DS  against the key by looking it up in the subordinate zone -
but that should be at the decision (option) of the registry.

DNSSEC is only one of numerous out of (registry) band activities that happen
around a transfer.

Personally, if I was processing a DNS operator transfer for a signed zone,
and I was the losing DNS operator, I would prefer the requesting DNS
operator to provide a ZSK that they generated and I would incoporate that
into my key rollover.

I don't think the registry's responsibilities should try and overreach, for
example, what if I am switching registrars but not DNS operators?  I could
run a transfer with no related DNS/DNSSEC changes.  What if I change DNS
operators but stay with the same registrar? Again, other than switching up
DS records through my registrar, the registry doesn't need to be involved
any further.

I think the registry's role should stay constrained to what it's
responsibilities are at it's level of the hierachary.  Now I suppose we
argue about what those responsibilities really should be, but I think it
starts and ends with what they can control.    


Best Regards,

Michael Young
M:+1-647-289-1220


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Antoin Verschuren
Sent: March-08-12 3:36 AM
To: [email protected]
Subject: Re: [provreg] Example of stupid inconsistencies between registries

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

On 08-03-12 07:02, Patrik Fältström wrote:

> I think this is a case that creates a problem for the _registrant_. If it
was only a registry/registrar battle (as in most cases we discuss on this
list ;-) ) I would not have spent so much time on this.
> 

Patrick,

I think you are correct that multiple options are confusing for the users.
In fact that is why we chose for DNSKEY in stead of DS, let me explain.

In the beginning of DNSSEC, where procedures were not well worked out yet,
registries chose for DS because that's what they minimally need to enter
into the parent zone for a new DNSSEC delegation to work, and it's shorter
and perhaps easier to copy-paste.

However we encountered problems with other procedures when dealing with
DNSSEC, like the transfer issue. Please read
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-03

To deal with the dns-operator change, users need to relay ZSK's, which is a
KEY and not a DS. The losing operator needs the KEY from the gaining
operator.

So when we chose to use DS or DNSKEY, one of the rationales was that users
need to send DS with no transfer, but need to send a KEY (ZSK) as well when
there is a transfer. Let's just use KEYs all the time, it's less confusing.

When the draft describing the transfer issue is done, I expect a new
standard EPP extension that contains the "DNSKEY to be relayed" to the
losing DNS operator, that contains a KEY (Any volunteers to take that up in
this group ?). I also expect by that time that registries will see that it
makes no sense to ask for a KEY one time, and a DS another time.
The only reason to still support DS is then legacy support.

- --
Antoin Verschuren

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

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email protected]  xmpp:[email protected]
http://www.sidn.nl/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPWG9sAAoJEDqHrM883AgnRa4H/jc79//8AiFTV0q/UYUUsFkw
a4U/pevfcbs8TLU0QzdCDie0nuPO7Eeg/aF5FXY3uFknTgS+nWDAkatAXKBNFNQZ
vzdICrxLY905wO9sOmV9nuAPTEvy4ae42tt4TRwid8/5Q6BOnhgglPt/oYc1qb5d
Ga+V6YUDEYRYEVLdEPPOdXfAzwEPFbtvObKvF6cKayiNr+a4szxSH7YAaLSkkwdy
u0Vc19h9Ztpi06Ohm4ZfzMyxEEqS7ec1qEG3H5bDZt2UFi2C9f60f1KoUtWU3EXa
QYiP+oT3ThgwpT9qOrwZRjlIhp88JsG4AhOEg3D4fpqhgPmyuMbaQ6IvsxgEz20=
=ktvM
-----END PGP SIGNATURE-----
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg