Re: Example of stupid inconsistencies between registries

On Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik Fältström wrote:

> According to RFC 5910, section 4, there are two alternative
> interfaces for managing DNSSEC key data when interfacing with a
> registry. The RFC does not explicitly say whether a registry must
> implement one or the other.

Of course it doesn't.  Registries are going to have policies, and
those policies might differ.  For instance,  

> I have successfully implemented in a web interface, an API for
> registrants etc, the DS interface as the client do believe passing
> DS data is the easiest. After all that is what is to be signed by
> the parent.

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.

Many (most?) registries are drawing an analogy with NS and IP
addresses in A/AAAA records, and simply accepting what the client
sends them.  The problem with that analogy is that neither of those
types of data are actually authoritative (or anyway, only
authoritative) on the parent side.  The apex NS records, for instance,
are authoritative data (some implementations treat them as the _only_
authoritative data, checking the apex record after receiving the
delegation-NS RRset); and glue records are certainly not
authoritative, which is why we no longer promote glue from the
Additional section.

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.  

Best,

A

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