Re: Example of stupid inconsistencies between registries

This has been a very interesting thread.  The key is what the provisioning
interface should be for the DNSSEC information.  I don't believe that the
Registrar should provide a hint to the Registry to go retrieve information
from DNS.  EPP is the secure provisioning protocol that should be used for
passing information that makes it into the resolution services provided by
the Registry.  In RFC 5910 the two interfaces define what objects in the
Registry are managed by the Registrars.  The DS Data Interface has the
Registrar manage the DS Data that is directly placed into the parent zone
by the Registry.  The Key Data Interface has the Registrar manage the Key
Data and the Registry generates the DS Data to place in the parent zone.
RFC 5910 supports passing both DS Data and the associated Key Data for
validation purposes by the Registry, but that still is considered the DS
Data Interface.  Back when we started working on the update to RFC 4310
that eventually became RFC 5910, the concept of supporting a Key Data
Interface was discussed with no concerns expressed at the time or as RFC
5910 went through the standards process.  The only real discussion was
around supporting a mix of the DS Data Interface and the Key Data
Interface which resulted in having the server support one or the other and
only a mix during a transition period.  Support for both models in RFC
5910 is no different than support for multiple models for hosts (host
objects or host attributes) or contacts (thin or thick) in RFC 5731, where
the protocol does not dictate the model but supports the different models.
 If the registries are going to support the different models, as in this
case, the only alternative would be the creation of a one or more custom
extensions for the less popular model, which as I posted previously
wouldn't benefit anyone.

--
  
JG
 

 
James Gould
Principal Software Engineer
[email protected]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 3/8/12 5:52 AM, "Mark Elkins" <[email protected]> wrote:

>On Thu, 2012-03-08 at 07:02 +0100, Patrik Fältström 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.
>> 
>> So the DS should be enough. Everything else is bonus. Or am I
>> completely confused before enough coffee here in the morning?
>
>I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type
>of secured link) gives the Registry enough validatable information to
>fetch DNSKEY records via unsigned DNS and then validate them.
>
>Personally - just sending a trigger to the Registry to come fetch my
>DNSKEY from me would statistically be enough.  The Registry has my
>Nameservers - they can ask each NS in turn for my DNSKEY - if all
>Nameservers agree - its most probably correct... OK - so I'll send a
>valid DS record as a trigger.
>
>Once signed, a simple trigger should be enough though? The Registry can
>ask via DNSSEC for any new DNSKEY records as then the DNS transaction is
>signed (as in the AD bit is set)... OK - It'll still be a DS Record
>trigger.
>
>This is probably of insignificance to anyone running a properly
>configured Registry<-->Registrar systems but for anyone doing EPP type
>updates via a web portal, the less one has to type - the better.
>-- 
>  .  .     ___. .__      Posix Systems - (South) Africa
> /| /|       / /__       [email protected]  -  Mark J Elkins, Cisco CCIE
>/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496
>
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg

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