Re: Example of stupid inconsistencies between registries

On 8 mar 2012, at 09:16, Peter Koch wrote:

>> 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.
> 
> i'm not sure what exactly you mean by thick (or "fat", as others have said)
> vs. thin here since in the realm of registries these terms are already occupied.

Well, I use it because other people started using it ;-) I think people have used "thick" or "fat" for registries that want to have the DNSKEY for all the DS they have, and "thin" if they just have the DS.

> I think the validation is related to, but otherwise independent of the type
> of object passed.
> In your scenario any DNSKEY that would end up in the registry db would have
> to be present at the apex at the time of registration,

No, not at the time of registration. At the time the DS is to appear in the zone (after validation that the DNSKEY and DS matches each other). Just like NS records, they can be added much later than time of registration. The validation is similar to the validation some registries do for lame delegation (at time of addition of NS to the parent zone).

It has nothing to do with registration per se, although some registries require delegation at time of registration.

> which prohibits
> pre-publication of a DS RR for a DNSKEY not yet present at the apex DNSKEY RRSet.

This is correct.

If the registry want to hold the DNSKEY and they only get the DS and the DNSKEY is not in the apex DNSKEY RRSet, then...

A lot of "if" there ;-)

I see such policies be policies that a registry can implement anyway with the DS interface. For example, I sort of can understand that a registry only want to accept some digest types. That can be done by only accepting some digest types when DS is passed to them. In the case of pre-publication of DS, the registry can say that "if you use the DS interface, the DNSKEY must be present in the DNSKEY apex RRSet at time of passing the DS via epp". I think both of those solutions would be better than refusing to support the DS interface.

That said, I do not understand registries that do not accept DS interface and "just" pass that to their zone and sign it. It seems to much much easier than the for me more complicated DNSKEY interface.

> I don't understand how the DNSKEY would be worse for the registrant than the DS given that
> the DNSKEY is what they already have in their hands.

Correct, we could as well have always passed the DNSKEY to the registry. The problem is not even that some registries ask for DS, some for DNSKEY, but that some refuse to accept DS (in my case). It could, as you say, also have been that some refuse to accept DNSKEY.

To repeat, I have encountered a number of registries accepting DS (they might accept DNSKEY as well) and now suddenly one that only accept DNSKEY and not DS.

I felt that was a situation complicated enough for the registrar (me) and the registrant (our customers) that I wanted to discuss the situation on this list.

Which I thank you all for the ability to do. It has been a good conversation.

   Patrik

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