Re: Example of stupid inconsistencies between registries

Jay Daley <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
On 8/03/2012, at 7:02 PM, Patrik Fältström wrote:

>> To explain what I mean, here's a simple idea - could the protocol have been designed to better minimise pain for registrars while maintaining the choice for registries?
> 
> I think this is a case that creates a problem for the _registrant_.

How?

> 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.
> 
>> With two variants of the protocol as tightly coupled to policy as this, then when a registry changes policy it has to change interface.
> 
> A registry that want to be "thick" can still receive the DS, then fetch the DNSKEY from DNS which they validate against the DS. If they want create a new DS they can do so with whatever digest algorithm they want and not even publish the DS that the client passes to them.
> 
> So the DS should be enough. Everything else is bonus. Or am I completely confused before enough coffee here in the morning?

You are assuming a particular sequence of provisioning (i.e. that there are published DNSKEY records when the DS is received).  Many registries make no assumptions and so don't expect to contact delegated nameservers during the provisioning process.

cheers
Jay

> 
> Btw, I will be at the ICANN meeting in Costa Rica and do not mind talking with people about this.
> 
>   Patrik
> 


-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

_______________________________________________
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.