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

From: [email-masked]
Date: Mon, 1 Feb 2010 16:51:55 +0000

Eduardo Duarte <[email-masked]> 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

---

From: James Gould <[email-masked]>
Date: Wed, 03 Feb 2010 18:18:55 -0500

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-masked]
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-masked]>
Date: Mon, 1 Feb 2010 11:51:55 -0500
To: <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <[email-masked]> wrote:

> 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

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

---

From: Eduardo Duarte <[email-masked]>
Date: Thu, 04 Feb 2010 11:20:56 +0000

Hello,

Well I think you know here I stand here. For me the hypothesis number 3 
will be the best option. But I think number 2 will also be a good 
approximation where I can make some adjustments to work with it. But the 
number 1, for me, will be a bad choice. :(
So depending on what the list chose I will follow it.

Best regards,

Eduardo Duarte

James Gould wrote, On 03-02-2010 23:18:
> 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.
>
>
> *James F. Gould
> **Principal Software Engineer
> *VeriSign Naming Services
> [email-masked]
> *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-masked]>
> *Date: *Mon, 1 Feb 2010 11:51:55 -0500
> *To: *<[email-masked]>
> *Cc: *EPP Provreg <[email-masked]>
> *Subject: *Re: off-list was Re: [ietf-provreg] Revision of 4310
>
> 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

---

From: Ulrich Wisser <[email-masked]>
Date: Fri, 05 Feb 2010 14:18:09 +0100

Hi,

>    1. Don’t include any additional elements.  This means that the server
>       would either validate the passed DS inline with the EPP

This would be my favorite option. Sorry Eduardo!

>       secDNS:keyData (Key Interface) elements of secDNS:infData.  I
>       propose the use of the secDNS:published element.  

At least I can see a use case here, but even if you know when the ds 
record is published there is still so much guessing about cache updates 
that the option doesn't really help.

>       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.  

In that case I see a major clash with EPP semantics. The 
childKeyPublished flag should be update able. The current extension 
doesn't allow for this. So the ds record in question would have to be 
removed and added again. If the registry doesn't publish ds records of 
unpublished keys it seems that you shouldn't send the ds record to the 
registry in the first place. If the registry does publish ds records of 
unpublished keys the flag has no function. If the registry checks if the 
key is published before putting it in the zone file, the flag has no 
function either.

Given my above assessment I would prefer to not put in such a flag.

/Ulrich

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 10 Feb 2010 14:14:58 +0100

>> propose the use of the secDNS:published element.

Hi all,

I have to admit that I have not yet fully understood the purpose of the 
<published> element for each key/DS entry in the domain:info response.

Shall it reflect the outcome of an asynchronous verification of the specified 
key data against the actual data in the child zone? Or shall it simply denote 
that the respective DS record is now visible on all name servers of the parent zone?

In both cases, I see the problem that the registrar needs to periodically check 
the domain in order to detect a "magical" change of the value from "false" to 
"true". Being responsible for thousands to millions of domains, a registrar 
might create a considerable extra load on his and the registry's servers for the 
periodical submission of <domain:info> requests. Wouldn't it be better to create 
a poll message for that state change which can be retrieved via the <poll> request?

In the first case, I wonder whether this would match the general processing 
model of EPP. If an asynchronous check is performed, wouldn't the respective 
<domain:create> and <domain:update> requests be required to return a 
1001/"Command completed successfully; action pending" response, enter the 
"pendingCreate"/"pendingUpdate" state until completion, with the respective poll 
message at the end?

In the second case, I would like to also refer to a posting of myself to the 
list last November[1].

Regards

Klaus

[1] http://www.cafax.se/ietf-provreg/maillist/2009-11/msg00028.html