Re: off-list was Re: Revision of 4310

Pre-publishing the DS is a valid use case, but I guess it boils down to how
the servers are going to handle the pre-published DS.  I know for our
registries that we¹ll publish what is given to us or do the validation
inline with the EPP transaction.  Validation could be done inline with the
EPP transaction so that DS is not stored in the database unless it has the
corresponding DNSKEY in the child zone or in the case of .PT it could be
done asynchronously which leads to accepting DS that might not be published
based on server policy.  So the real question is whether the rfc4310-bis
needs to add an additional flag element to support the ladder?  I personally
don¹t like the term ³active² for this, since ³active² does not effectively
reflect the purpose.  I believe that published is more accurate, since the
server is making a decision related to what is published and what is not
published.  This should be an optional attribute to support servers that
publish everything, where the default is true.  I would like to pose the
following options to the list for consideration in rfc4310-bis:

1. Don¹t include any additional elements.  This means that the server would
either validate the passed DS inline with the EPP transaction or would
publish all DS that is passed.
2. Add a new optional element in the secDNS:dsData (DS Interface) and
secDNS:keyData (Key Interface) elements of secDNS:infData.  I propose the
use of the secDNS:published element.
3. Add a new optional secDNS:childKeyPublished element in the secDNS:dsData
(DS Interface) and secDNS:keyData (Key Interface) elements of secDNS:create,
secDNS:update, and secDNS:infData.  This element would be specified by the
client to inform the server which DS has a corresponding DNSKEY published in
the child zone.  It would be up to the server to decide the validation and
publishing scheme based on this flag.  Option #2 might have to go along with
this as well in the event that the server will publish a different set of DS
based on offline / asynchronous processing.

I would like to hear from those interested in this topic either from
messages to the list or to me privately.

Thanks,

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.



From: <[email protected]>
Date: Mon, 1 Feb 2010 11:51:55 -0500
To: <[email protected]>
Cc: EPP Provreg <[email protected]>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <[email protected]> wrote:

> ... we are thinking of adding a
> DS validator in order to publish only the correct DS's. Also we always have
> our data in the database and there we keep the multiple keys associated with
> the domain some in publish state and other in a unpublished state. So when a
> user adds a DS to our system he is adding it to the database and not to the
> zone itself and after, when generating the zone the script, will only pick-up
> and add to the zone the "actives" DS's.

As has been pointed out elsewhere, there are valid reasons for publishing a
DS record in the parent without a corresponding DNSKEY in the child (e.g.
key rollover). If you are going to validate the DS/DNSKEY correspondences,
then a better check would be that at least one of the DS records being
published in the parent corresponds to a DNSKEY currently in the child.

Stephen