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