[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Eduardo Duarte <eduardo.duarte@fccn.pt>
CC: EPP Provreg <ietf-provreg@cafax.se>, WG-DNS <wg-dns@fccn.pt>
From: James Gould <jgould@verisign.com>
Date: Thu, 28 Jan 2010 14:16:04 -0500
In-Reply-To: <4B61D313.5020802@fccn.pt>
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcqgTlW/1GN6bOODiUqez5Prg9/nuw==
Thread-Topic: off-list was Re: [ietf-provreg] Revision of 4310
User-Agent: Microsoft-Entourage/12.23.0.091001
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

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

So this is purely informational for the client to understand the status of publishing DS or a key when the server is doing scheduled zone cuts?  There is inherent delay between the provisioning system and DNS with or without dynamic updates, where the value in the central provisioning system doesn’t guarantee that all of the DNS servers have fully propagated the update and that the recursive resolvers have refreshed their cache.  The client is responsible for managing their keys (scheduled or emergency) based on multiple timed values (time it takes the client to send the update to the server, the time it takes the server to update the master zone, the time it takes to update all of the slave zones, and then taking into account the TTL).  An additional attribute returned from the provisioning system is just one piece of the puzzle that by itself won’t address the issue.  I can see the argument for adding a client specified flag to drive server-side validation of when the DNSKEY is published in the child zone, but I really don’t see the need for a flag for the server to indicate to the client that the DS has been published to the parent zone.  Do others feel differently about this?  

--


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: Eduardo Duarte <eduardo.duarte@fccn.pt>
Date: Thu, 28 Jan 2010 18:10:27 +0000
To: James Gould <jgould@verisign.com>
Cc: EPP Provreg <ietf-provreg@cafax.se>, WG-DNS <wg-dns@fccn.pt>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

Well in our case there is always a small steps in the middle...  We still don't have dynamic updates running so there will always be a small delay from the publishing to the releasing in the zone, and 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.
So you see that between adding a record and publishing it on the zone are some steps in the middle!

I Think this is what you where asking but if you have any more doubts, don't hesitate to ask them! ;)

Best regards,

Eduardo Duarte


James Gould wrote, On 27-01-2010 19:47:
Re: off-list was Re: [ietf-provreg] Revision of 4310 Eduardo,
 
I’m getting a little bit confused with the request.  Can you describe the use case step-by-step on the usage of the active flag?  The current RFC and draft assumes that the server publishes the DS as soon as possible after receiving it from the client, where it would be considered active (with some delay to propagate) from a provisioning perspective.  Is there additional server-side logic that I’m not aware of?  
 
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: Eduardo Duarte <eduardo.duarte@fccn.pt>
 Date: Wed, 27 Jan 2010 06:08:55 -0500
 To: EPP Provreg <ietf-provreg@cafax.se>
 Cc: WG-DNS <wg-dns@fccn.pt>
 Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310
 
Hello,
 
First of all sorry not to have contributed yesterday but I had no time
to read all the emails... :(
 
Well when I was thinking of this flag I was thinking that it would mean
if the key is publish in the parent zone and I was not thinking to much
on the create/update commands but more on the info... :P
On our work model a domain can have more then one key associated with
domain and they can be in a active or inactive state where active means
publish or unpublished  in the parent zone.
When adding a key I dont see the problem of it becoming automatically
publish in the parent zone and the old key to be unpublished as soon at
is expire or remove.  But lets say the owner of the domain keep just
adding keys! After a while if in the info command you send back all the
keys associated with the domain you will not have a good hint of wich
ones are publish... Or if a domain change onwer also will be a bit
difficult to understand witch of the keys are publish without consulting
directly the DNS server...
Also you can say for me to send on the info command just the active key,
but then I will be not sending all the associated data with the domain...
So to cover this ground of sending all the data back and the state of
the DS I proposed the active/inactive flag, that I supposed that is
backwards compatible.
 
I know that some other registries use this model for managing the client
keys and that was why I asked if this was already been discussed...
 
Best regards,
 
Eduardo Duarte
 
 
Jaap Akkerhuis wrote, On 26-01-2010 22:53:
>      Was meant to be off-list.  Because I'm diving into the details of
>      DNSSEC itself.  (And not saying anything new.)
>
>      To come back to EPP, I think we need to revisit "active/inactive" and
>      the implications it has to a registry.
>
> Well, since Eduardo Duarte from the .PT registry proposed it, maybe
> he should starts to explain what problems he wants to solve with this.
>
>       jaap
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to ietf-provreg-request@cafax.se
>
>   
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se
 
 
 


Home | Date list | Subject list