Re: off-list was Re: [ietf-provreg] Revision of 4310

[James Gould <jgould@verisign.com>]

Title: Re: off-list was Re: [ietf-provreg] 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
jgould@verisign.com
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: <Stephen.Morris@nominet.org.uk>
Date: Mon, 1 Feb 2010 11:51:55 -0500
To: <eduardo.duarte@fccn.pt>
Cc: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <eduardo.duarte@fccn.pt> 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