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