Re: Example of stupid inconsistencies between registries

My name is Benoit Levac and I'm the new development manager at CIRA (.ca).  This discussion is quite timely for us since we are just in the process of specking our registry support for DNSSEC.  

It sounds to me like the following arguments are being made for each of the interfaces:

DS Data Interface: more commonly used by major Registrars and Registries so adoption is would probably be more favorable

Key Data Interface: seems more technically correct - if the registry is authoritative for the DS record, it should make sure that it is correct before publishing it to the zone (although it is understood that a change by the dns operator could later render it invalid)

For those registries that have taken the Key Data approach, have you found that it has been a barrier for registrars to start publishing DNSSEC information for their domains?

As well, does anyone have a list of use cases / scenarios used in the quality assurance process for the registry implementation of DNS SEC in the registry.

Thank you.

Ben 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Howard Eland
Sent: March-05-12 10:31 AM
To: [email protected]
Subject: Re: [provreg] Example of stupid inconsistencies between registries

On Mar 5, 2012, at 9:11 AM, Andrew Sullivan wrote:

> On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote:
>> Ok I see this argument but on the other hand I have to ask how much 
>> responsibility does the registry want to take on?
> 
> The registry took on the responsibility for authoritative data in its 
> zone by virtue of accepting the delegation from its parent (usually 
> the root).  You might as well argue that the registry doesn't really 
> have to keep its apex records well-maintained.

Yes - when working on this RFC, we were torn between two different realities: (1) that there were already many registries that either (1a) want to take the "registrar is responsible for the data they send to the registry" model, or (1b) are already working fine with accepting DS data, and don't want to change; vs.  (2) The DS record is a completely different dragon, and (2a) the registry should generate any data for which it is authoritative, or (2b) the registry wants to make sure that it has some control over which algorithms are in use (i.e. registry X does not want to see GOST, or registry Y wants to make sure they only see GOST).

Consensus was that both arguments (1) and (2) were valid, so the RFC was worded to allow either.

> 
>> verify the DS data.  However, lets face it, I can publish whatever I 
>> want to the registry and then later on mess my zone up because I 
>> mis-manage something.
> 
> That's just irrelevant.  The issue here is data that is authoritative 
> _only_ in the parent-side zone.

Right - see (1a) above.

-Howard


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

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