Re: Example of stupid inconsistencies between registries

On 05/03/12 14:02, Patrik Fältström wrote:
> On 5 mar 2012, at 12:50, Peter Koch wrote:
>
>>> I just encountered a registry that "want to set a limit on what digest
>>> algorithms to use" and to do that, they have decided to not implement the
>>> DS interface and only support the KEY interface.
>>
>> Some registries have decided to operate on DNSKEY rather than DS. It
>> appears reasonable to me to reflect this in the provisioning protocol. This
>> is exactly not an EPP inconsistency, because EPP is policy neutral here and
>> can thus well be used for either way.
>
> ...and as you understand I think that the fact that there seems to be an
> ability for registries to choose in their epp interface is extremely bad for
> the registrant.
>
> I.e. why should a registrant have to send _different_ information to the
> registrar for example.A and example.B?
>
> Where "example" is the same for both TLDs.
>
> In one case DS, in another case KEY?
>
> I want to admit that when I read the RFC in question, I read it as if both
> interfaces should exist. Not that a registry could say no to one. So I
> personally missed this during last call.
>
> Patrik
>
>

There are surely good reasons for each choice: for example, requiring DS data 
saves the registry from the duty of calculating the DS data with the 
responsibility for errors in this calculation. On the other hand, using DNSKEY 
data makes it easier for the registry to deal with IDN variants -- if they are 
not published via DNAMEs (or similar future xNAME) but via duplicated NS 
records, the submission of a single DNSKEY data record is sufficient for both 
the main domain and the variants (with the consequence that all zones need to be 
signed with the same key, of course).

I myself am a bit undetermined what I shall regard as the better solution, but I 
tend towards the second one. My original preference however was to allow both on 
a per-domain base, although RFC 5910 does not recommend this.

Regards,

Klaus



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