Re: off-list was Re: 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
[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: Eduardo Duarte <[email protected]>
Date: Thu, 28 Jan 2010 18:10:27 +0000
To: James Gould <[email protected]>
Cc: EPP Provreg <[email protected]>, WG-DNS <[email protected]>
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
>  [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: Eduardo Duarte <[email protected]>
>  Date: Wed, 27 Jan 2010 06:08:55 -0500
>  To: EPP Provreg <[email protected]>
>  Cc: WG-DNS <[email protected]>
>  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 [email protected]
>> >
>> >   
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to [email protected]
>  
>  
>