Re: Example of stupid inconsistencies between registries

On 5 mar 2012, at 14:45, Andrew Sullivan wrote:

> even though the client might believe that passing the DS data is the
> easiest, the registry might want the DNSKEY data.  The reason to
> prefer the DNSKEY data is because the DS is authoritative _only at the
> parent_.  In principle, then, it is a mistake to accept any old DS
> data from the child side of the zone cut and publish it as
> authoritative data: the registry can't be sure it has that right.
> Therefore, it either should accept DS data with a DNSKEY that it can
> validate the DS with, or else it should just accept the DNSKEY data
> and generate the DS itself.

Who is responsible for doing the validation? The registry or the registrar?

That is what you say, right? And sure, the view on that differs.

> I find the complaints about inconsistencies across registries to be a
> little odd: the whole point of EPP is supposed to be its
> extensibility, and that will necessarily mean inconsistencies.  I'd be
> more interested in arguments about why it is so difficult to find and
> use the extensions.  It always seemed to me that the client libraries
> were the problem: they don't have a good plugin architecture, which
> should make the use of extensions easy.  

The problem here is that a registrant must give different data to the same registrar depending on the TLD. That is different from having the same registrar implement the same thing differently two two different registrars (so that the registrant can do for example transfer or renew the same way when talking with the same registrar regardless of registry).

That is creating problems and it does not matter what the registrar does to resolve this.

My point is that I clearly see that the chance that the same registrar will implement both DS and KEY interface to TLDs is extremely small. Simply because the interaction with the registrant is too complicated. Instead, I think we will see registrars supporting either DS or KEY, and because of that support for DNSSEC will differ depending on support at registry.

And as (as you say) most registries support DS, I see a risk registries that do not support DS will not get as many registrars support DNSSEC operations with them.

I.e. a non-harmonization that I think is of a much different kind than what we otherwise talk about on this list.

   Patrik

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

iD8DBQFPVMTyrMabGguI180RAtfAAJ9pNsJYKWYzln2eyhCrvDRoX6KhkACfYp/k
YQuDrKKNTm9p7fpqQgZrqJQ=
=OUeP
-----END PGP SIGNATURE-----