Subject: [ietf-provreg] Revision of 4310

From: Eduardo Duarte <[email-masked]>
Date: Mon, 25 Jan 2010 14:56:53 +0000

Hello,

I work for the .PT ccTLD and I'm starting to add the DNSSEC extension 
under our EPP implementation.
For doing this I'm following the the new revision of the 4310 RFC and I 
was wondering something after reading it...

On our implementation of DNSSEC a domain can have multiple DS keys 
associated were some are active and other are in an inactive state.
On the secDNS.xsd I didn't see any way to have multiple keys send in the 
info command and have a way to show if they are active or not.

Was this matter discuss on the list already!?

If no can I propose a small change in XSD (I know that is probably to 
late for that....). My suggestion is to add a Active/Non-Active field on 
the DSdataType so the definition changes to the following:
<complexType name="dsDataType">
<sequence>
<element name="keyTag" type="unsignedShort"/>
<element name="alg" type="unsignedByte"/>
<element name="digestType" type="unsignedByte"/>
<element name="digest" type="hexBinary"/>
<element name="maxSigLife" type="secDNS:maxSigLifeType" minOccurs="0"/>
<element name="keyData" type="secDNS:keyDataType" minOccurs="0"/>
<element name="active" type="boolean" minOccurs="0"/>
</sequence>
</complexType>

Thanks and best regards,

Eduardo Duarte

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Jan 2010 10:28:28 -0500

> late for that....). My suggestion is to add a Active/Non-Active field on  

It's certainly not too late.  The document has been submitted, but
there's ample time for revision still.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: James Gould <[email-masked]>
Date: Mon, 25 Jan 2010 18:03:42 -0500

Eduardo,

I don't believe this was discussed, but what is the expected behavior of the
server?  Is the use case that the clients would pre-publish the DS as active
/ inactive to the server, and the server would in turn only publish the
active DS data?  The current draft has the server publish all passed DS
information, so the client would add / remove DS data instead of
pre-publishing and activating / deactivating them.  Now all records are
considered active.  Adding an additional attribute would be somewhat
challenging, since it would require the client to add and remove the same
DS, but with the activity flag set to a different value on the add.  This is
a corner case that came up with changing the maxSigLife.

-- 

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: Eduardo Duarte <[email-masked]>
> Date: Mon, 25 Jan 2010 14:56:53 +0000
> To: EPP Provreg <[email-masked]>
> Cc: 'WG-DNS' <[email-masked]>
> Subject: [ietf-provreg] Revision of 4310
> 
> Hello,
>

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Jan 2010 06:56:24 +0100

I think it is much better the way it is now, that all DS the registry know about are active. To turn the active/not active flag on and off epp transactions are needed anyways, so the client can as well remove/add the keys instead.

I.e. I do not see any need for the registry to keep track of active/not active keys, and need to get much more explanation why this is needed to be convinced we should change what we have today.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:06:17 -0500

On Tue, Jan 26, 2010 at 06:56:24AM +0100, Patrik Fältström wrote:

> I think it is much better the way it is now, that all DS the
> registry know about are active. To turn the active/not active flag
> on and off epp transactions are needed anyways, so the client can as
> well remove/add the keys instead.
> 
> I.e. I do not see any need for the registry to keep track of
> active/not active keys, and need to get much more explanation why
> this is needed to be convinced we should change what we have today.

Actually, I can think of a use for this, or something like it.  If you
wanted to pre-publish keys in the parent, and the parent is checking
for the corresponding key in the child zone, then you can't do that
with the bits available in the protocol now.  But if we had a way to
say, "Put this key in, but it's not active now," that would be a way
to pre-publish the DS without the corresponding DNSKEY in the child
zone, even if the parent had a policy to check the child zone (because
with the "not active" the parent could tell that the key just won't be
there).

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 09:44:40 -0500

Andrew,

I don¹t understand why the client wouldn¹t just add the DS when it becomes
active to the server instead of pre-publishing and activating.  Adding an
active attribute adds a new model that could cause confusion for the clients
interfacing with different servers and it doesn¹t really add anything that
can¹t be handled today by the client.  Adding another attribute that could
change frequently like an active flag could pose an issue of support with
the secDNS:add, secDNS:rem, and secDNS:chg, where the only way to change the
attribute is to use a secDNS:add and secDNS:rem of the same DS (or key), or
use the secDNS:chg to replace all DS (or key) data.  I believe this
interface is acceptable for the optional maxSigLife attribute, but would
become onerous for a more frequently used attribute like an active flag.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:06:17 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Revision of 4310

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:51:23 -0500

> active to the server instead of pre-publishing and activating.  Adding an

Because of caches, and the TTL on the parent zone which is not
controllable by the client.

If you have to do an emergency key rollover, you _can't_ stop using
your old key until the longest TTL in the system without your zone
validating bogus.  If the parent at the start only has the old DS, and
you've yanked the corresponding DNSKEY because you know it to be
compromised, then anyone who hits a cache containing the old DS will
get it until it has expired.

If the parent-held DS RRSet contains a DS corresponding to a new
DNSKEY, then you can cycle that DNSKEY in immediately.  You might not
have been using it, or even publishing it in the DNSKEY RRSet because
you might have wanted to keep your response size reasonably small.

The EPP extension as it stands just doesn't support this option. 

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 11:13:44 -0500

Andrew,

What is the fundamental difference between a deactivate and a remove?  It
sounds like exactly the same from a DNS perspective and the TTL.  The
emergency key rollover use case that you present will be handled exactly the
same way if the client were to remove the DS from the Registry as opposed to
deactivating it and than later removing it.  The deactivate from my
understanding will not remove it from the zone any faster then the existing
remove.  Please explain the difference.

Thanks,

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 09:51:23 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Revision of 4310

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 11:41:21 -0500

> remove.  Please explain the difference.

It's the other way around.  Having a bad key around that you're not
using does no harm.  But _adding_ a key isn't instant either.

If I validate your key, I look up the DS from the parent.  That DS
RRSet ends up cached in the cacheing resolver in front of me.

If you now add a new DNSKEY in an emergency, and stop using your old
key, then the DS that is cached is still the one I use when
validating.

Now, if you have a short TTL on your own DNSKEY record, your old
DNSKEY will expire from my cache quickly.

But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
zone.

That means that the fastest you can roll your key is the maximum TTL
on the DNSKEY or DS records.  So if the parent has long TTLs, you're
stuck with the TTL on the DS record.

Now, if you can add a DS into the parent _before_ you add the DNSKEY
to your zone, then the DNSKEY need not actually be in your zone when
the DS is available in the parent.

Now, some zone operators have said they want to validate that the
DNSKEY is available in the child before publishing the corresponding
DS in the parent.  But if EPP were to offer a mechanism whereby you
could say, "I want you to have this DS record in the DS RRSet, but
_don't_ expect a DNSKEY in the child yet," then the parent would know
not to perform that check when adding the DS record.  (By policy, I
suppose, the "activation" bit could cause the check against the
child.)

So that's the use case.  I don't know how important this is to
operators, however.

A

---

From: Gavin Brown <[email-masked]>
Date: Tue, 26 Jan 2010 17:03:33 +0000

> But AFAIK, no TLD allows clients to set the TTL on RRs in the parent

This is something that CentralNic allows. We created an EPP extension
for it but haven't produced a schema document or an internet draft (this
is something we are thinking of doing if there is interest in it, at the
moment it is little used by our registrars, and when they do use it,
they do it wrong).

The documentation we have for this is here:

https://www.centralnic.com/company/labs/epp/ext/ttl

Regards,

-- 
Gavin Brown
Chief Technology Officer
CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 12:09:35 -0500

> moment it is little used by our registrars, and when they do use it,

Heh.  This is one of the things I'd worry about.  There's a potential
load issue, too, of course: if some huge registrar sets all the TTLs
to 5 seconds, your DNS servers are going to be swamped.

Nevertheless, I find this interesting (and I'd sure like to see this
be one of the extensions that gets documented by any new provreg2 WG).

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 12:19:06 -0500

Andrew,

Ok, so you¹re saying the difference is that the active flag only drives the
server validation of the DNSKEY but the server would still publish it.  The
term active and inactive is sort of misleading in this case.  An ³inactive²
DS (or key) does not exclude the DS from being published in the zone, but
simply removes the validation.  So why would the client ever ³activate² a
DS, if the validation is being done as part of a server policy and the
active flag controls the application of the policy?  The client would most
likely want the server to do what they want and always set the flag to
false.  In either case would a better name of the attribute be ³validate²
instead of ³active²?

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 11:41:21 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Revision of 4310

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 13:30:59 -0500

On Tue, Jan 26, 2010 at 12:19:06PM -0500, James Gould wrote:

> server validation of the DNSKEY but the server would still publish
> it.  

The idea that I had was that this was a way for the client to signal
to the parent what role the key is going to play, yes.  I don't
actually care what we call it, no.

> The
> simply removes the validation.  

Maybe.  I figured the "active" meant "actively in use", and is
strictly speaking a property of the DNSKEY and not the DS.  The DS
happens to correspond to a DNSKEY that is in active use, or not.  

A different name (with maybe a different meaning) is "published".
This one corresponds more exactly with the kind of use I'm thinking
of, because it tells the parent whether the DNSKEY appears in a public
zone.

> So why would the client ever ³activate² a DS, if the validation is
> being done as part of a server policy and the active flag controls
> the application of the policy?  The client would most likely want
> the server to do what they want and always set the flag to false.

Could be.  There's an advantage to the sponsor telling the repository
which keys are _supposed_ to be available, however, because that gives
the two parties responsible at the zone cut a mechanism for properly
co-ordinating their actions.  I haven't thought it through completely,
but it strikes me that this might also make life easier at domain
transfer time, also, because the target DNSKEY could be sent to the
parent and made available as a DS without actually being published.
(What bugs me about this is the potential for hijacking, so I'm not
yet convinced it's a good idea.)

> In either case would a better name of the attribute be ³validate²
> instead of ³active²?

Whatever we use, not "validate", please.  That word's already
meaningful in a DNSSEC context, and I don't want to overload it.

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 13:56:12 -0500

>associated were some are active and other are in an inactive state.

I am not sure what active/inactive means.

Does an inactive DS record appear in the parent zone?

In my view - active/inactive could mean

1) published/not-published in the parent zone
2) tthe corresponding DNSKEY is published/not-published in the child zone
3) that the DNSKEY set in the child zone is signed/not-signed by the 
corresponding private key.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 14:04:40 -0500

>be one of the extensions that gets documented by any new provreg2 WG).

When you consider extensions in individual, it's not compulsory 
(required) that all extensions to EPP be put through a standards 
process.  There's probably some subjective benchmark at which a 
standard definition is a good idea.

But looking at the population of such extensions, I become concerned 
that the protocol could become an architectural nightmare.  This has 
happened before, extensions in DNS spurred BIND 8 to replace BIND 4, 
in operating systems this happened too about 15-20 years ago.

I'm not singling out this extension, but throwing another thought out 
there regarding whether we want to request a BoF this summer and rev 
up a provisioning protocol wg.

(I'm certainly not trying to rope in innovations out there - such as 
4310bis - progress shouldn't be stopped.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 14:32:58 -0500

On Tue, Jan 26, 2010 at 02:25:51PM -0500, James Gould wrote:
> setting or using the secDNS:chg to replace all).  I don’t want to rework the
> interface to add this optional attribute, so will the existing interface
> work for this additional attribute?

See my other note in response to Ed: I think we need to figure out
whether anyone might really want this feature before we start making
it work :-)

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 14:25:51 -0500

Andrew,

You not saying  that the DS is active or not active, but that the associated
DNSKEY in the child zone exists.  The term active is really misleading and
certainly should not be used in this case.  Your proposing that the client
tell the server whether they’ve published their DNSKEY for validation based
on server policy?  I guess based on this something like childKeyActive is
more appropriate since this is not an attribute of the DS.  I still have a
concern about the interface that needs to be used to change the attribute (
secDNS:add and secDNS:rem the same DS or key with a new childKeyActive
setting or using the secDNS:chg to replace all).  I don’t want to rework the
interface to add this optional attribute, so will the existing interface
work for this additional attribute?

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 13:30:59 -0500
To: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] Revision of 4310

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 14:31:52 -0500

> I am not sure what active/inactive means.

Yeah, I don't know if this is the best term.  Before we go fine-tuning
the terminology, however, we prolly oughta figure out whether this is
worth doing.

> 1) published/not-published in the parent zone

Like James, I can see no reason to have two ways to do this.

> 2) tthe corresponding DNSKEY is published/not-published in the child zone

I can see a reason to do this.

> corresponding private key.

I don't think I understand this one.  Do you mean that there's no
RRSIG for that DNSKEY record?

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 15:23:15 -0500

>the terminology, however, we prolly oughta figure out whether this is

I think my message was unclear.  I wasn't trying to fine tune the 
terminology.  I was trying to offer possible interpretations of the 
words in an attempt to understand the requirement.  (Note I went back 
to the first message in the thread.)

>RRSIG for that DNSKEY record?

To clarify - Yes.  In this instance, "in-active" would cover having a 
DS appear, the DNSKEY appear, but no RRSIG created by the private 
key.  That would make the DS "in-active" in terms of building a chain 
of trust.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 15:37:36 -0500

On Tue, Jan 26, 2010 at 03:23:15PM -0500, Edward Lewis wrote:
> To clarify - Yes.  In this instance, "in-active" would cover having a DS 
> appear, the DNSKEY appear, but no RRSIG created by the private key.  That 
> would make the DS "in-active" in terms of building a chain of trust.

I like this idea better than just not putting the DNSKEY in the DNSKEY
RRset.  Is anyone doing their deployment this way?

On the other hand, I suppose it doesn't really matter whether one does
it this way or by just not including the DNSKEY on the child side.  In
either case, you have to use the old key until the TTL expires
(because without an RRSIG, the new key won't be useful either).  So
why add the key to the DNSKEY RRset at all?

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 16:24:45 -0500

I think this has veered off-topic for EPP. ;)

At 15:37 -0500 1/26/10, Andrew Sullivan wrote:
>(because without an RRSIG, the new key won't be useful either).

If you are doing SEP=KSK and ZSK for all other keys, the best (IMO) 
thing to do is to add the SEP to the DNSKEY set and include the 
signature when you begin the process of changing.  After appropriate 
timing, add the new DS and remove the old DS (or swap in one atomic 
transaction).  After more appropriate time, revoke and later remove 
the old key.

We plan to always have an emergency key on-line.  So, add new key #3 
to the set of #1 and #2.  Later swap #1 with #2.  Eventually revoke 
#1.  One cycle later, add new key #4, swap #2 with #3, retire #2. 
And so on.  From add new key to remove there are three KSK 
signatures, two otherwise.  There is always just one DS record (per 
key algorithm and DS hash).

If one does not have a KSK/ZSK model, things will be different.  I 
haven't thought through that though.

>So why add the key to the DNSKEY RRset at all?

So the validator can get the key.  (If it weren't there, it's not 
going to be anywhere.)

Put the key at the parent...you're back to RFC 2065...;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 17:00:43 -0500

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.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 17:12:06 -0500

> the implications it has to a registry.

Agreed.  It seemed to me we needed the DNSSEC details for that,
though, but I'm happy if we say we don't.

A

---

From: James Gould <[email-masked]>
Date: Tue, 26 Jan 2010 17:22:06 -0500

Yes, we kind of got into the weeds of DNSSEC specifics.

I believe the request was to add a flag to the draft to allow the client to
indicate to the server that the DNSKEY is active in the child zone.  The
definition of this needs to be clearly defined, but I would assume that it
is that the DNSKEY is published in the child zone DNSKEY RRset.  This is an
optional attribute that the server can use for additional validation based
on server policy.  If the attribute is supported by the server it should be
returned in the secDNS:infData of the domain info response.  This optional
attribute would be added to the secDNS:keyData and the secDNS:dsData
elements.  I recommend calling this attribute childKeyActive.  I also
recommend that there are no changes to the secDNS interface to optimize
changing this attribute in a domain update.

Do registries in general need this and do clients want to add this
complexity to the draft?

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Jan 2010 16:24:45 -0500
To: Andrew Sullivan <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: off-list was Re: [ietf-provreg] Revision of 4310

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Jan 2010 17:33:39 -0500

> Yes, we kind of got into the weeds of DNSSEC specifics.

In my view, if we're making software to support DNSSEC, we need to
understand how it's going to be used.  For all I (or anyone else,
AFAICS) knows, this proposed feature is a bad idea, because nobody
will use it.  We need to understand whether there's a compelling use
case for communicating the status of a DNSKEY or it RRSIG across the
zone cut.  If not, then the feature is a bad idea & we should argue
against it.  If it is likely to be used, that's a different story.
 
> indicate to the server that the DNSKEY is active in the child zone.  

That's one idea of three.  See Ed's initial message.  What I'm trying
to see is whether, of the two actually useful ideas we've discussed,
whether any of them are really useful and whether one is to be
preferred to the other.  For sure, the suggestions that "inactive"
means "don't publish DS" is silly, for the reasons you already
suggested.

A

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 26 Jan 2010 23:53:40 +0100

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

---

From: Eduardo Duarte <[email-masked]>
Date: Wed, 27 Jan 2010 11:08:55 +0000

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 27 Jan 2010 11:43:21 -0500

(Altered the subj line as we are back on topic. ;))

At 11:08 +0000 1/27/10, Eduardo Duarte wrote:

>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

This was as I suspected.  (Read: I'm about to jump on a soap box.)

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

I'm going to argue about registry practice here.  I don't mean to 
criticize, but I feel compelled to express my opinion.

I think it is a good idea for a registry to ONLY collect information 
that is supposed to be in or support the public DNS or WhoIs.

I need to really explain this blanket statement.

"supposed to be in" includes data about suspended/blocked/reserved 
domains (those not actively delegated but still being associated to 
an entity).  So a domain name that that has elapsed is okay - it is 
"supposed to be in" except that something else went wrong - and 
retaining it's last known NS set is a good idea.

"supports" refers to data that is related to functions like billing 
or contacts that are used to make sure the registration is "fresh (as 
in active, live, the guys out there are still runnning a server, 
etc.)."

"public" besides the usual stuff we think is public, I mean to 
included here (quasi-)confidential information that is disclosed to 
authorized third parties such as law enforcement.  I include this 
because not all registries have an Internet accessible, publicly 
viewable WhoIs but do have the requirement to identify registrants to 
authorities (legal or otherwise).

More to the point, I think it is very unwise for a registry to act as 
a data escrow facility for its registrants (unless you want to expand 
your mission or business to include that).  More precisely what I'm 
trying to say is that escrow is not part of provisioning.  IMO - 
registration should be about the "here and now" the relationship of 
entities to objects and vice versa.

Because of that opinion, I wouldn't think to add such a flag - a flag 
of "show this, don't show that."

(Again, please don't be offended, this is just a feature I feel adds 
complexity and burden to the registration interface and I want to be 
clear why I say the rest of the things.)

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

The true authority of a domain registered in your domain is the 
registrant.  Outside of you "granting" them the title to the name, 
they call the shots.  That is, the registry should do nothing 
"automatic" to the domain.  (Yes, refreshing DNSSEC signatures is the 
parent's job - but that's a statement about the parent's DNS data, 
not the child's.)  All actions regarding the registrant's domain 
should come from the registrant (or their agent, etc., /registrar).

And remember - keys don't expire in DNS, just signatures.

So I don't think you should need this flag.  Or anyone should need 
this flag.  (Not that adding it is a bad idea, and it can be done.  I 
am cautioning against ever using it.)

>But lets say the owner of the domain keep just adding keys!

And then there is that.  If you become an escrow agent, you enter 
another level of, well, hell.  You have to worry about registrants 
DOS'ing you, eating up your disk and memory.  What's your data 
retention policy, privacy policy, etc?  How do you back things up? 
How long do you store stuff?  When is data deleted?  This is more of 
a repeat of my "don't escrow while provisioning" message.

>keys and that was why I asked if this was already been discussed...

We do not want to touch any keys of our registrants, much less manage 
them.  That is why we only will take the DS record - the hash of the 
key.  We are very clear not to even see private keys, not public 
keys.  That is all the registrant's misery.  We just (plan to) 
register the hashes of the keys as the registrant submit them.

The registrants are completely in control of their key management. 
If they do frequent key changes, so be it.  If they never change the 
key, so be it.  We just report what they tell us to report.  Just 
like the NS records - we don't mess with them, we don't mess with the 
DS records.

(I don't mean to go commercial but to be clear I am writing this 
thinking solely as part of the registry team, not the managed DNS 
services team.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: James Gould <[email-masked]>
Date: Wed, 27 Jan 2010 14:47:27 -0500

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 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Eduardo Duarte <[email-masked]>
Date: Wed, 27 Jan 2010 06:08:55 -0500
To: EPP Provreg <[email-masked]>
Cc: WG-DNS <[email-masked]>
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Hello,

Best regards,

Eduardo Duarte

---

From: Eduardo Duarte <[email-masked]>
Date: Thu, 28 Jan 2010 18:10:27 +0000

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
> [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: *Eduardo Duarte <[email-masked]>
> *Date: *Wed, 27 Jan 2010 06:08:55 -0500
> *To: *EPP Provreg <[email-masked]>
> *Cc: *WG-DNS <[email-masked]>
> *Subject: *Re: off-list was Re: [ietf-provreg] Revision of 4310
>
> Hello,
>

---

From: James Gould <[email-masked]>
Date: Thu, 28 Jan 2010 14:16:04 -0500

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 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Eduardo Duarte <[email-masked]>
Date: Thu, 28 Jan 2010 18:10:27 +0000
To: James Gould <[email-masked]>
Cc: EPP Provreg <[email-masked]>, WG-DNS <[email-masked]>
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 
>