Re: Example of stupid inconsistencies between registries

Antoin Verschuren <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
-----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
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.