[dnssec-deployment] Fwd: [IP] Good Always Comes Out of Bad

[Paul Wouters]

>> But you do this only because you have no strong authentication to anyone you
>> are talking to, unlike the registry/registrar/domain holder model, where
>> they do have that and can leverage that.
>
> i think the sense of this discussion thread is that the regist{ry,rar,rant}
> strong authentication model isn't strong enough, and that something else is
> also needed "to prevent errors".  i submit that if we need a belt AND some
> suspenders, that joao's DLV approach might be a fine set of suspenders.

That's a bad analogy because with the stolen registrant's password, I have
full access to your hips, and any belts you have will be useless.

>> - If the Registrar or their customer accounts are hacked, nothing can save
>>   us.
>
> well, yes.  but we could "prevent errors".

Then you can do a simple DS query before continuing, but I think the general
opinion was that's a job of the Registrar, not the Registry.

>> - If the Registrar offers a GUI for DS on top of their GUI for NS records,
>>   then there is no need for any additional authentication or anti-spoof
>>   methods.
>
> based on other comments seen here today, i now believe that the EPP model is
> in fundamental conflict with DNS stability, robustness, and uptime.  the fact
> that mismatches between the delegating NS RRset and the apex NS RRset cannot
> be directly reported from registry to registrant, and that registrars are too
> thin in their margins to be able to act as intermediary for asynchronous
> notifications of this kind, means we're doomed to have a bazillion or so bad
> delegations at any given moment.  repeat for DS RRsets and apex DNSKEY RRsets.
> repeat for "glue" A or AAAA RRsets vs. the real RRsets held in real zones.

But those are mostly the registrant's own issues. If they run an unpatched
webserver from 1992, then we cannot help them either.

Paul