Subject: [provreg] Example of stupid inconsistencies between registries

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 11:43:30 +0100

According to RFC 5910, section 4, there are two alternative interfaces for managing DNSSEC key data when interfacing with a registry. The RFC does not explicitly say whether a registry must implement one or the other.

I have successfully implemented in a web interface, an API for registrants etc, the DS interface as the client do believe passing DS data is the easiest. After all that is what is to be signed by the parent.

I just encountered a registry that "want to set a limit on what digest algorithms to use" and to do that, they have decided to not implement the DS interface and only support the KEY interface.

I can accept limitations on what digest algorithms they accept, but not limitations by not supporting DS.

Reactions?

  Patrik

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Mon, 5 Mar 2012 10:59:43 +0000

Patrik

Welcome to our world :)

We see inconsistencies between registries all the time - it makes integration with new registry providers painful and as a result we tend to focus on the ones whose quirks we've already dealt with 

Regards

Michele

On 5 Mar 2012, at 10:43, Patrik Fältström wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 12:04:40 +0100

This one is specifically irritating as it requires in worst case massive explanations, education and web/REST interface implementations that are dependent on the TLD. I.e. something a registrar can not "hide" from the registrant.

I am not happy about differences that cost registrars hard work of various kinds. But I am definitely not happy of things that cost registrant things.

So, for this specific case, I would like to see a MUST in at least the DS interface.

   Patrik

---

From: Anthony Kirby <[email-masked]>
Date: Mon, 5 Mar 2012 11:32:33 +0000

Hi Patrik,

FWIW, we (Nominet / .uk) chose the DS interface for 2 reasons:
- compatibility; DS data can be generated from key data but not vice-versa
- simplicity & clarity of responsibility (we just publish what we're given)

On the other hand, we chose to be cautious about the set of algorithms/digest types/digests to allow for the DS record, because 3rd party components might allow nonstandard values on input, but then fail.  That said, no-one's yet asked for GOST support.

I haven't read the RFC recently, but I recall the choice of interface was an either/or - so a MUST implies the loss of the key interface (not that I'd cry for it).

Anthony

________________________________________
From: [email-masked] [[email-masked]] on behalf of Patrik Fältström [[email-masked]]
Sent: 05 March 2012 10:43
To: [email-masked]
Subject: [provreg] Example of stupid inconsistencies between registries

Reactions?

  Patrik

---

From: Peter Koch <[email-masked]>
Date: Mon, 5 Mar 2012 12:50:00 +0100

Patrik,

> According to RFC 5910, section 4, there are two alternative interfaces for managing DNSSEC key data when interfacing with a registry. The RFC does not explicitly say whether a registry must impleme…

exactly, this is an improvement over its predecessor RFC 4310 that mandated DS.

> I just encountered a registry that "want to set a limit on what digest algorithms to use" and to do that, they have decided to not implement the DS interface and only support the KEY interface.

Some registries have decided to operate on DNSKEY rather than DS. It appears
reasonable to me to reflect this in the provisioning protocol.
This is exactly not an EPP inconsistency, because EPP is policy neutral here
and can thus well be used for either way.

-Peter

PS: for "full disclosure": DENIC does not use EPP and we do DNSSEC provisioning
    based on the DNSKEY RRSet only

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 14:02:19 +0100

> and can thus well be used for either way.

...and as you understand I think that the fact that there seems to be an ability for registries to choose in their epp interface is extremely bad for the registrant.

I.e. why should a registrant have to send _different_ information to the registrar for example.A and example.B?

Where "example" is the same for both TLDs.

In one case DS, in another case KEY?

I want to admit that when I read the RFC in question, I read it as if both interfaces should exist. Not that a registry could say no to one. So I personally missed this during last call.

   Patrik

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Mar 2012 13:21:19 +0000

Patrik,

This was discussed on this list in late 2009.  Ulrich Wisser brought up on
the list on October 28, 2009 "that .SE and other registries considered to
become a "fat" registry and take in the public keys instead of the ds
records".  Support for a "thin" DNSSEC registry as a MUST with the option
for a "fat" registry was never discussed on the list.  I believe that a
mix of "thin" and "fat" would make things more complex since the
registrars would need to support both instead of one interface for the
registries that do support the "fat" model.  Think about handling
transfers between registrars where the gaining registrar supports only the
"thin" model and the losing registrar supports both "thin" and "fat".
There was support on this list and no concerns raised in adding support
for the key data interface to the draft.  You were active on the list
while this was being discussed and never expressed any concerns in support
for the key data interface.  What is in the RFC supports the models of
"thin" with the ds data interface and "fat" with the key data interface
with an either or option for the registries.  The registries that I work
on support the "thin" model with the ds data interface.

--
  
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/5/12 6:04 AM, "Patrik Fältström" <[email-masked]> wrote:

>This one is specifically irritating as it requires in worst case massive
>explanations, education and web/REST interface implementations that are
>dependent on the TLD. I.e. something a registrar can not "hide" from the
>registrant.
>
>I am not happy about differences that cost registrars hard work of
>various kinds. But I am definitely not happy of things that cost
>registrant things.
>
>> We see inconsistencies between registries all the time - it makes
>>integration with new registry providers painful and as a result we tend
>>to focus on the ones whose quirks we've already dealt with
>> 
>> Regards
>> 
>> Michele
>> 
>> 
>>> According to RFC 5910, section 4, there are two alternative interfaces
>>>for managing DNSSEC key data when interfacing with a registry. The RFC
>>>does not explicitly say whether a registry must implement one or the
>>>other.
>>> 
>>> I have successfully implemented in a web interface, an API for
>>>registrants etc, the DS interface as the client do believe passing DS
>>>data is the easiest. After all that is what is to be signed by the
>>>parent.
>>> 
>>> I just encountered a registry that "want to set a limit on what digest
>>>algorithms to use" and to do that, they have decided to not implement
>>>the DS interface and only support the KEY interface.
>>>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 14:31:36 +0100

On 5 mar 2012, at 14:21, Gould, James wrote:

> I believe that a
> registries that do support the "fat" model.

Today that is obviously what we have as the registries do support either DS or KEY (and not both).

> Think about handling

Yup, that creates problems for the registrant as well.

>  The registries that I work

...and the registries I work with so far (which include .SE) support the DS interface.

But I stumbled upon one that only support KEY interface.

   Patrik

---

From: MICHAEL YOUNG <[email-masked]>
Date: Mon, 5 Mar 2012 08:38:50 -0500

James, I'm not sure from what you've written here, what your vote is, I think it's for the ds data interface?

I'm for the "thin" model and agree it should be a must. 

BTW, in all fairness, we all miss the opportunity to raise issues on these lists - it's tough to stay on top of the discussion flow when you have a day job as well.

-Michael

>>> Twitter: http://twitter.com/mneylon

MICHAEL YOUNG
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Mar 2012 08:45:03 -0500

On Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik Fältström wrote:

> According to RFC 5910, section 4, there are two alternative
> interfaces for managing DNSSEC key data when interfacing with a
> registry. The RFC does not explicitly say whether a registry must
> implement one or the other.

Of course it doesn't.  Registries are going to have policies, and
those policies might differ.  For instance,  

> registrants etc, the DS interface as the client do believe passing
> DS data is the easiest. After all that is what is to be signed by
> the parent.

even though the client might believe that passing the DS data is the
easiest, the registry might want the DNSKEY data.  The reason to
prefer the DNSKEY data is because the DS is authoritative _only at the
parent_.  In principle, then, it is a mistake to accept any old DS
data from the child side of the zone cut and publish it as
authoritative data: the registry can't be sure it has that right.
Therefore, it either should accept DS data with a DNSKEY that it can
validate the DS with, or else it should just accept the DNSKEY data
and generate the DS itself.

Many (most?) registries are drawing an analogy with NS and IP
addresses in A/AAAA records, and simply accepting what the client
sends them.  The problem with that analogy is that neither of those
types of data are actually authoritative (or anyway, only
authoritative) on the parent side.  The apex NS records, for instance,
are authoritative data (some implementations treat them as the _only_
authoritative data, checking the apex record after receiving the
delegation-NS RRset); and glue records are certainly not
authoritative, which is why we no longer promote glue from the
Additional section.

I find the complaints about inconsistencies across registries to be a
little odd: the whole point of EPP is supposed to be its
extensibility, and that will necessarily mean inconsistencies.  I'd be
more interested in arguments about why it is so difficult to find and
use the extensions.  It always seemed to me that the client libraries
were the problem: they don't have a good plugin architecture, which
should make the use of extensions easy.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Mar 2012 13:49:45 +0000

Michael,

I'm not voting but simply covering how the two interfaces made it into the RFC.  I can see the basis for both interfaces, but I certainty don't believe that a mix in a single registry is workable.

--

JG

James Gould

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: MICHAEL YOUNG <[email-masked]<mailto:[email-masked]>>
Date: Mon, 5 Mar 2012 08:38:50 -0500
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Patrik Fältström <[email-masked]<mailto:[email-masked]>>, "Michele Neylon :: Blacknight" <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Example of stupid inconsistencies between registries

-Michael

Patrik,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 3/5/12 6:04 AM, "Patrik Fältström" <[email-masked]<mailto:[email-masked]>> wrote:

So, for this specific case, I would like to see a MUST in at least the DS
interface.

 Patrik

Patrik

Welcome to our world :)

Regards

Michele

I can accept limitations on what digest algorithms they accept, but
not limitations by not supporting DS.

Reactions?

Patrik

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

Mr Michele Neylon
Blacknight Solutions ♞
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business
Park,Sleaty

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

MICHAEL YOUNG
[email-masked]<mailto:[email-masked]>

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 14:51:46 +0100

> and generate the DS itself.

Who is responsible for doing the validation? The registry or the registrar?

That is what you say, right? And sure, the view on that differs.

> should make the use of extensions easy.  

The problem here is that a registrant must give different data to the same registrar depending on the TLD. That is different from having the same registrar implement the same thing differently two two different registrars (so that the registrant can do for example transfer or renew the same way when talking with the same registrar regardless of registry).

That is creating problems and it does not matter what the registrar does to resolve this.

My point is that I clearly see that the chance that the same registrar will implement both DS and KEY interface to TLDs is extremely small. Simply because the interaction with the registrant is too complicated. Instead, I think we will see registrars supporting either DS or KEY, and because of that support for DNSSEC will differ depending on support at registry.

And as (as you say) most registries support DS, I see a risk registries that do not support DS will not get as many registrars support DNSSEC operations with them.

I.e. a non-harmonization that I think is of a much different kind than what we otherwise talk about on this list.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 14:52:15 +0100

> I'm not voting but simply covering how the two interfaces made it into the RFC.  I can see the basis for both interfaces, but I certainty don't believe that a mix in a single registry is workable.  

Similarly, I do not see a mix in a single registrar is workable.

   paf

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Mon, 5 Mar 2012 13:53:45 +0000

> BTW, in all fairness, we all miss the opportunity to raise issues on these lists - it's tough to stay on top of the discussion flow when you have a day job as well.

+1

Mr Michele Neylon
Blacknight Solutions ♞

---

From: Peter Koch <[email-masked]>
Date: Mon, 5 Mar 2012 14:54:30 +0100

> ...and as you understand I think that the fact that there seems to be an ability for registries to choose in their epp interface is extremely bad for the registrant.

quite frankly, I don't.  Since the registry is free(*) to decide to
support DNSSEC (or not) in the first place, there's probably other
things to worry about.

> I.e. why should a registrant have to send _different_ information to the registrar for example.A and example.B?

Because that's already the fact regardless of DNSSEC?  And if as a registrar
you'd like to be of help, just accept the key and compute the DS. Or ask both
the DS and the DNSKEY from the registrant (or their DNS operator).

> I want to admit that when I read the RFC in question, I read it as if both interfaces should exist. Not that a registry could say no to one. So I personally missed this during last call.

The provisioning protocol should implement policy, not dictate it.
Otherwise you'd really end up with incompatible extensions.

-Peter

(*) Within the boundaries of the applicable policy process.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 14:59:02 +0100

> Otherwise you'd really end up with incompatible extensions.

Absolutely!

There is always a balance between freedom in protocol specifications and interoperability...

   Patrik

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 05 Mar 2012 14:53:37 +0100

On 05/03/12 14:02, Patrik Fältström wrote:
>>> algorithms to use" and to do that, they have decided to not implement the
>>> DS interface and only support the KEY interface.
>>
>> Some registries have decided to operate on DNSKEY rather than DS. It
>> appears reasonable to me to reflect this in the provisioning protocol. This
>> is exactly not an EPP inconsistency, because EPP is policy neutral here and
>> can thus well be used for either way.
>
> ...and as you understand I think that the fact that there seems to be an
> ability for registries to choose in their epp interface is extremely bad for
> the registrant.
>
> I want to admit that when I read the RFC in question, I read it as if both
> interfaces should exist. Not that a registry could say no to one. So I
> personally missed this during last call.
>
> Patrik
>
>

There are surely good reasons for each choice: for example, requiring DS data 
saves the registry from the duty of calculating the DS data with the 
responsibility for errors in this calculation. On the other hand, using DNSKEY 
data makes it easier for the registry to deal with IDN variants -- if they are 
not published via DNAMEs (or similar future xNAME) but via duplicated NS 
records, the submission of a single DNSKEY data record is sufficient for both 
the main domain and the variants (with the consequence that all zones need to be 
signed with the same key, of course).

I myself am a bit undetermined what I shall regard as the better solution, but I 
tend towards the second one. My original preference however was to allow both on 
a per-domain base, although RFC 5910 does not recommend this.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 05 Mar 2012 15:29:23 +0100

On 05/03/12 14:49, Gould, James wrote:
> Michael,
>
> I'm not voting but simply covering how the two interfaces made it into the RFC.
> I can see the basis for both interfaces, but I certainty don't believe that a
> mix in a single registry is workable.
>

Why? The only problematic situation is the transfer of a domain. But the DNSSEC 
related data is not deleted during the transfer, so it stays as long as the new 
registrar desires. And if the registrar wants to update the DNSSEC data, he can 
specify to delete all previous data (be it DS or DNSKEY) and replace it with his 
preferable representation.

Generally, I think the topic is overestimated -- I think it is more critical 
that the various registries allow different sets of algorithms for the DNSKEY 
and I cannot choose the same algorithm for all my domains.

Klaus

---

From: MICHAEL YOUNG <[email-masked]>
Date: Mon, 5 Mar 2012 09:34:17 -0500

Sorry I was being quip, I didn't literally mean "vote" :-)

I agree with you, a mix is not adding true value to the solution.

-M

On 2012-03-05, at 8:49 AM, Gould, James wrote:

> <86BF0728-DD04-4F90-8380-5AA8A9AB5D0B[22].png>
>  
> James Gould
> From: MICHAEL YOUNG <[email-masked]>
> To: James Gould <[email-masked]>
> Cc: Patrik Fältström <[email-masked]>, "Michele Neylon :: Blacknight" <[email-masked]>, "<[email-masked]>" <[email-masked]>

MICHAEL YOUNG
[email-masked]

---

From: MICHAEL YOUNG <[email-masked]>
Date: Mon, 5 Mar 2012 09:48:04 -0500

Ok I see this argument but on the other hand I have to ask how much responsibility does the registry want to take on?  Some ccTLDs won't even complete the registration process until the proposed child zone is up and verification checks are run by the registry. I can see a logical extension of that practice would be to verify the DS data.  However, lets face it, I can publish whatever I want to the registry and then later on mess my zone up because I mis-manage something.  

Besides, if the DS data is wrong, then DNSSEC validation is just going to choke anyways right? Seems like its a self-regulating problem that the registry doesn't need to try and solve.  The fact that most of the registries are going the  DS route implies they aren't that interested the job of verifying the data. 

Michael

MICHAEL YOUNG
[email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Mar 2012 14:55:20 +0000

Klaus,

Yes, the gaining registrar could delete and reset the DS or Key Data after
the transfer, but if the interface was consistent for the registry no
update would be required of the DNSSEC data after transfer.  Supporting a
mix of server-generated DS with the Key Data Interface as well as client
specified DS with the DS Data Interface across domain names or within
domain names of a single registry will add undue complexity for the client
and the server.  I believe if there is support for "thin" (DS Data
Interface) and "fat" (Key Data Interface) DNSSEC models in the protocol
that a server should choose just one model / interface.  Requiring the
"thin" model in the protocol would result in registries that want to
support the "fat" DNSSEC model to create custom extensions that would not
be beneficial to anyone.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Mar 2012 10:05:04 -0500

> Who is responsible for doing the validation? The registry or the registrar?

The registrar isn't publishing the authoritative zone, so it seems to
me that the registry is the one on the hook here.

Again, I want to emphasise the difference between DS and, say, NS.
There is nothing in the history of the DNS that is remotely analogous
to the DS record: nothing else is parent-side-only authoritative
data.  (One might lament that fact, but it's still the case).

> The problem here is that a registrant must give different data to
> the same registrar depending on the TLD.

Your complaint seems to be that a registrant has to provide different
data for different names.  I fail completely to see why that is a
problem.  (To put this slightly differently, you seem to be arguing
that a registrant shouldn't need to understand that example.com and
example.org are different domains.  This seems a little bit at odds
with your views on the many things people call "variants".)

> That is creating problems and it does not matter what the registrar does to resolve this.

Well, one possibility, it seems, is for the registrar to accept a DS
record for the name, look for the corresponding DNSKEY in the DNS,
pull that out, and send it along.  If the DNSKEY isn't there (see a
note downthread about this) then you have a problem.  But if the
registrant is too badly informed to understand the difference between
DNSKEY and DS, then I suspect s/he won't know how to prepublish DS
either.  

> My point is that I clearly see that the chance that the same
> registrar will implement both DS and KEY interface to TLDs is
> extremely small. Simply because the interaction with the registrant
> is too complicated. Instead, I think we will see registrars
> supporting either DS or KEY, and because of that support for DNSSEC
> will differ depending on support at registry.

Surely this is the point of having a competitive market?

Best,
A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Mar 2012 10:11:08 -0500

On Mon, Mar 05, 2012 at 09:48:04AM -0500, MICHAEL YOUNG wrote:
> Ok I see this argument but on the other hand I have to ask how much
> responsibility does the registry want to take on? 

The registry took on the responsibility for authoritative data in its
zone by virtue of accepting the delegation from its parent (usually
the root).  You might as well argue that the registry doesn't really
have to keep its apex records well-maintained.

> verify the DS data.  However, lets face it, I can publish whatever I
> want to the registry and then later on mess my zone up because I
> mis-manage something.

That's just irrelevant.  The issue here is data that is authoritative
_only_ in the parent-side zone.

> Besides, if the DS data is wrong, then DNSSEC validation is just
> going to choke anyways right? 

Could be, but you might not know it.

One rollover mechanism is to pre-publish a DS record on the parent
side of the zone cut before you publish the DNSKEY on the child side.
You generate RRSIGs with the stand-by key as well, but never publish
the new DNSKEY until the end; this way you always have a stand-by key
in place, so that if your active key is compromised you just publish
the new key and remove the old key.  Your exposure in that case is
only as long as the TTL on the DNSKEY record.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Howard Eland <[email-masked]>
Date: Mon, 5 Mar 2012 09:30:44 -0600

> have to keep its apex records well-maintained.

Yes - when working on this RFC, we were torn between two different realities: (1) that there were already many registries that either (1a) want to take the "registrar is responsible for the data they send to the registry" model, or (1b) are already working fine with accepting DS data, and don't want to change; vs.  (2) The DS record is a completely different dragon, and (2a) the registry should generate any data for which it is authoritative, or (2b) the registry wants to make sure that it has some control over which algorithms are in use (i.e. registry X does not want to see GOST, or registry Y wants to make sure they only see GOST).

Consensus was that both arguments (1) and (2) were valid, so the RFC was worded to allow either.

> _only_ in the parent-side zone.

Right - see (1a) above.

-Howard

---

From: Benoit Levac <[email-masked]>
Date: Mon, 5 Mar 2012 16:47:35 -0500

My name is Benoit Levac and I'm the new development manager at CIRA (.ca).  This discussion is quite timely for us since we are just in the process of specking our registry support for DNSSEC.  

It sounds to me like the following arguments are being made for each of the interfaces:

DS Data Interface: more commonly used by major Registrars and Registries so adoption is would probably be more favorable

Key Data Interface: seems more technically correct - if the registry is authoritative for the DS record, it should make sure that it is correct before publishing it to the zone (although it is understood that a change by the dns operator could later render it invalid)

For those registries that have taken the Key Data approach, have you found that it has been a barrier for registrars to start publishing DNSSEC information for their domains?

As well, does anyone have a list of use cases / scenarios used in the quality assurance process for the registry implementation of DNS SEC in the registry.

Thank you.

Ben 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Howard Eland
Sent: March-05-12 10:31 AM
To: [email-masked]
Subject: Re: [provreg] Example of stupid inconsistencies between registries

Right - see (1a) above.

-Howard

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 5 Mar 2012 22:57:42 +0100

> with your views on the many things people call "variants".)

No, I am just talking about how to design for example a web interface and instructions to the one that is to paste data into it. You have a number of fields, and different fields are mandatory depending on what TLD it is.

Same with for example an API. If you run a DNS hosting, would it not be easier if you can pass the same information to all registrars, and not have to do different depending on which one it is?

I am just talking about how much more difficult it is for everyone but the registry if it asks for something else than the DS, and in many cases it can also fetch the Key from the auth server if it want to validate the DS... Part from some cases where one want DS pre-published in the parent zone when the parent simply must trust whatever the registrar send anyway as it can not validate the data passed to it. As nothing is in the child zone that the data can be validated against.

   Patrik

---

From: James Mitchell <[email-masked]>
Date: Tue, 6 Mar 2012 10:10:16 +1100

You can solve your interface dilemma by always accepting key data and have your provisioning system generate the DS data in the background for the registries that require it :) Doing so also allows you to generate the DS using the algorithms required by the registry.

I don't believe that DS should be a must. As Klaus mentioned, server-side variants mean that key data may be preferred.

James

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Patrik Fältström
> Sent: Tuesday, 6 March 2012 8:58 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> No, I am just talking about how to design for example a web interface
> and instructions to the one that is to paste data into it. You have a
> number of fields, and different fields are mandatory depending on what
> TLD it is.
> 
> Same with for example an API. If you run a DNS hosting, would it not be
> easier if you can pass the same information to all registrars, and not
> have to do different depending on which one it is?
> 
> I am just talking about how much more difficult it is for everyone but
> the registry if it asks for something else than the DS, and in many
> cases it can also fetch the Key from the auth server if it want to
> validate the DS... Part from some cases where one want DS pre-published
> in the parent zone when the parent simply must trust whatever the
> registrar send anyway as it can not validate the data passed to it. As
> nothing is in the child zone that the data can be validated against.
> 
>    Patrik

---

From: Jay Daley <[email-masked]>
Date: Thu, 8 Mar 2012 14:28:15 +1300

On 5/03/2012, at 11:43 PM, Patrik Fältström wrote:

> [snipped]

If we start with the recognition that some registries want thin DNSSEC while others want thick and this difference is currently irreconcilable then what we are really talking about is the balance between consistency and choice in EPP and whether that's good now and will it get better over time.  Your complaint in essence is that in this case balance is not good now as choice has won out over consistency.  

I tend to agree with you that this is not good enough now because, in my view, policy and protocol have been too tightly coupled. 

To explain what I mean, here's a simple idea - could the protocol have been designed to better minimise pain for registrars while maintaining the choice for registries?  For example, could the interface have required registrars to provide both the DS records and the keys with registries using whichever of the two they want?  The implication of doing so is that we get consistency of interface while individual registries maintain choice on policy.  Is a registrar more or less likely to be confused by this than by two variants of the protocol?  My view is that they have to learn the policy difference anyway but they don't need to learn policy from implementing the protocol.

The second question is whether this balance is going to get better in future, where again I am not that hopeful.

With two variants of the protocol as tightly coupled to policy as this, then when a registry changes policy it has to change interface.  For a start that's a disincentive to change as it imposes a cost on registrars.  There's also the issue that they registry making the change doesn't have the historical data to conduct a 'what if our policy had been different' exercise.

The more general problem is that there is a strong school of thought around EPP that goes
- the core protocol is done and does not need changing
- everything else we need can go in an extension
- competition will sort out what extensions (or variants within extensions) dominate

I would suggest that is insufficient because policy, which eventually drives the technology, works differently and so the core will gradually become less suitable and the cruft of undead extensions (and variants) will become unmanageable.  Instead a more methodical process is needed that periodically reviews the core and extensions and where appropriate change the core and kills extensions.  Some of this review needs to be quite rapid to keep pace with the rapid pace of policy change.

cheers
Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 8 Mar 2012 07:02:12 +0100

On 8 mar 2012, at 02:28, Jay Daley wrote:

> To explain what I mean, here's a simple idea - could the protocol have been designed to better minimise pain for registrars while maintaining the choice for registries?

I think this is a case that creates a problem for the _registrant_. If it was only a registry/registrar battle (as in most cases we discuss on this list ;-) ) I would not have spent so much time on this.

> With two variants of the protocol as tightly coupled to policy as this, then when a registry changes policy it has to change interface.

A registry that want to be "thick" can still receive the DS, then fetch the DNSKEY from DNS which they validate against the DS. If they want create a new DS they can do so with whatever digest algorithm they want and not even publish the DS that the client passes to them.

So the DS should be enough. Everything else is bonus. Or am I completely confused before enough coffee here in the morning?

Btw, I will be at the ICANN meeting in Costa Rica and do not mind talking with people about this.

   Patrik

---

From: Jay Daley <[email-masked]>
Date: Thu, 8 Mar 2012 19:35:48 +1300

On 8/03/2012, at 7:02 PM, Patrik Fältström wrote:

> I think this is a case that creates a problem for the _registrant_.

How?

> If it was only a registry/registrar battle (as in most cases we discuss on this list ;-) ) I would not have spent so much time on this.
> 

You are assuming a particular sequence of provisioning (i.e. that there are published DNSKEY records when the DS is received).  Many registries make no assumptions and so don't expect to contact delegated nameservers during the provisioning process.

cheers
Jay

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 8 Mar 2012 07:41:10 +0100

>> I think this is a case that creates a problem for the _registrant_.

Because compared to other discussions we have, this implies the registrant (or, more correctly, the DNS hosting provider) have to do completely different actions depending on the policy of the TLD.

> You are assuming a particular sequence of provisioning (i.e. that there are published DNSKEY records when the DS is received).  Many registries make no assumptions and so don't expect to contact de…

Correct, just like many registries already today require delegations to be made before registration can be done. I.e. some registries do not allow registration without delegation.

My point is that without delegation, sending KEY does not make any sense. It is when delegating the dnssec data is needed and because of that the KEY can be fetched at time of delegation.

   Patrik

---

From: Peter Koch <[email-masked]>
Date: Thu, 8 Mar 2012 09:16:04 +0100

Patrik,

> A registry that want to be "thick" can still receive the DS, then fetch the DNSKEY from DNS which they validate against the DS. If they want create a new DS they can do so with whatever digest algo…

i'm not sure what exactly you mean by thick (or "fat", as others have said)
vs. thin here since in the realm of registries these terms are already occupied.
I think the validation is related to, but otherwise independent of the type
of object passed.
In your scenario any DNSKEY that would end up in the registry db would have
to be present at the apex at the time of registration, which prohibits
pre-publication of a DS RR for a DNSKEY not yet present at the apex DNSKEY RRSet.

I don't understand how the DNSKEY would be worse for the registrant than the DS given that
the DNSKEY is what they already have in their hands.

-Peter

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 8 Mar 2012 09:36:00 +0100

> I think this is a case that creates a problem for the _registrant_. If it was only a registry/registrar battle (as in most cases we discuss on this list ;-) ) I would not have spent so much time on…

Patrick,

I think you are correct that multiple options are confusing for the
users. In fact that is why we chose for DNSKEY in stead of DS, let me
explain.

In the beginning of DNSSEC, where procedures were not well worked out
yet, registries chose for DS because that's what they minimally need to
enter into the parent zone for a new DNSSEC delegation to work, and it's
shorter and perhaps easier to copy-paste.

However we encountered problems with other procedures when dealing with
DNSSEC, like the transfer issue. Please read
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-03

To deal with the dns-operator change, users need to relay ZSK's, which
is a KEY and not a DS. The losing operator needs the KEY from the
gaining operator.

So when we chose to use DS or DNSKEY, one of the rationales was that
users need to send DS with no transfer, but need to send a KEY (ZSK) as
well when there is a transfer. Let's just use KEYs all the time, it's
less confusing.

When the draft describing the transfer issue is done, I expect a new
standard EPP extension that contains the "DNSKEY to be relayed" to the
losing DNS operator, that contains a KEY (Any volunteers to take that up
in this group ?). I also expect by that time that registries will see
that it makes no sense to ask for a KEY one time, and a DS another time.
The only reason to still support DS is then legacy support.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Mark Elkins <[email-masked]>
Date: Thu, 08 Mar 2012 12:52:18 +0200

On Thu, 2012-03-08 at 07:02 +0100, Patrik Fältström wrote:

> A registry that want to be "thick" can still receive the DS, then fetch
> the DNSKEY from DNS which they validate against the DS. If they want
> create a new DS they can do so with whatever digest algorithm they want
> and not even publish the DS that the client passes to them.
> 
> So the DS should be enough. Everything else is bonus. Or am I
> completely confused before enough coffee here in the morning?

I'd agree with you. A DS record over EPP (I'd thus assume a SSL/TLS type
of secured link) gives the Registry enough validatable information to
fetch DNSKEY records via unsigned DNS and then validate them.

Personally - just sending a trigger to the Registry to come fetch my
DNSKEY from me would statistically be enough.  The Registry has my
Nameservers - they can ask each NS in turn for my DNSKEY - if all
Nameservers agree - its most probably correct... OK - so I'll send a
valid DS record as a trigger.

Once signed, a simple trigger should be enough though? The Registry can
ask via DNSSEC for any new DNSKEY records as then the DNS transaction is
signed (as in the AD bit is set)... OK - It'll still be a DS Record
trigger.

This is probably of insignificance to anyone running a properly
configured Registry<-->Registrar systems but for anyone doing EPP type
updates via a web portal, the less one has to type - the better. 
-- 
  .  .     ___. .__      Posix Systems - (South) Africa
 /| /|       / /__       [email-masked]  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 8 Mar 2012 12:52:06 +0100

> signed (as in the AD bit is set)... OK - It'll still be a DS Record

We have discussed such a principle some time ago, but it is/will be
rejected by the politics of ICANN registrars.
In our technical vision, EPP only needs to be used for bootstrapping the
original delegation and chain of trust. After that, all technical stuff
can be done over (secure) DNS, and EPP is only needed for administrative
data.
ICANN registrars disagree. According to their contract, ALL changes to
the delegation may only be done by submission by the registrar over EPP
to the registry, so that they are aware and can intercept technical
changes. Even if that means the delegation is technically incorrect. NS
changes can also be done over DNS if that is a secure channel, but
registrars want to be able to block technical changes when f.e. a bill
has not been paid. The motivation they use is that provisioning the
registry data then comes from 2 channels, DNS and EPP, and the
discussion may arise which one is authoritative.

- -- 
Antoin Verschuren

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Mar 2012 13:29:55 +0000

This has been a very interesting thread.  The key is what the provisioning
interface should be for the DNSSEC information.  I don't believe that the
Registrar should provide a hint to the Registry to go retrieve information
from DNS.  EPP is the secure provisioning protocol that should be used for
passing information that makes it into the resolution services provided by
the Registry.  In RFC 5910 the two interfaces define what objects in the
Registry are managed by the Registrars.  The DS Data Interface has the
Registrar manage the DS Data that is directly placed into the parent zone
by the Registry.  The Key Data Interface has the Registrar manage the Key
Data and the Registry generates the DS Data to place in the parent zone.
RFC 5910 supports passing both DS Data and the associated Key Data for
validation purposes by the Registry, but that still is considered the DS
Data Interface.  Back when we started working on the update to RFC 4310
that eventually became RFC 5910, the concept of supporting a Key Data
Interface was discussed with no concerns expressed at the time or as RFC
5910 went through the standards process.  The only real discussion was
around supporting a mix of the DS Data Interface and the Key Data
Interface which resulted in having the server support one or the other and
only a mix during a transition period.  Support for both models in RFC
5910 is no different than support for multiple models for hosts (host
objects or host attributes) or contacts (thin or thick) in RFC 5731, where
the protocol does not dictate the model but supports the different models.
 If the registries are going to support the different models, as in this
case, the only alternative would be the creation of a one or more custom
extensions for the less popular model, which as I posted previously
wouldn't benefit anyone.

--
  
JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

---

From: "Michael Young" <[email-masked]>
Date: Thu, 8 Mar 2012 12:50:40 -0500

I'm not sure why as a DNS operator I would want to either send a ZSK (signed
by my KSK) or receive a ZSK signed by a KSK I don't control through the
domain registry.

I tend to think this should stay between the two DNS operators, as the keys
are being managed in the delegate zone, all the TLD zone should care about
is that whoever controls the domain has submitted what they consider to be a
valid DS.  As Patrik said, if the registry wants to be generous, it can
validate the DS  against the key by looking it up in the subordinate zone -
but that should be at the decision (option) of the registry.

DNSSEC is only one of numerous out of (registry) band activities that happen
around a transfer.

Personally, if I was processing a DNS operator transfer for a signed zone,
and I was the losing DNS operator, I would prefer the requesting DNS
operator to provide a ZSK that they generated and I would incoporate that
into my key rollover.

I don't think the registry's responsibilities should try and overreach, for
example, what if I am switching registrars but not DNS operators?  I could
run a transfer with no related DNS/DNSSEC changes.  What if I change DNS
operators but stay with the same registrar? Again, other than switching up
DS records through my registrar, the registry doesn't need to be involved
any further.

I think the registry's role should stay constrained to what it's
responsibilities are at it's level of the hierachary.  Now I suppose we
argue about what those responsibilities really should be, but I think it
starts and ends with what they can control.    

Best Regards,

Michael Young
M:+1-647-289-1220

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Antoin Verschuren
Sent: March-08-12 3:36 AM
To: [email-masked]
Subject: Re: [provreg] Example of stupid inconsistencies between registries

On 08-03-12 07:02, Patrik Fältström wrote:

> I think this is a case that creates a problem for the _registrant_. If it
was only a registry/registrar battle (as in most cases we discuss on this
list ;-) ) I would not have spent so much time on this.

Patrick,

I think you are correct that multiple options are confusing for the users.
In fact that is why we chose for DNSKEY in stead of DS, let me explain.

In the beginning of DNSSEC, where procedures were not well worked out yet,
registries chose for DS because that's what they minimally need to enter
into the parent zone for a new DNSSEC delegation to work, and it's shorter
and perhaps easier to copy-paste.

To deal with the dns-operator change, users need to relay ZSK's, which is a
KEY and not a DS. The losing operator needs the KEY from the gaining
operator.

So when we chose to use DS or DNSKEY, one of the rationales was that users
need to send DS with no transfer, but need to send a KEY (ZSK) as well when
there is a transfer. Let's just use KEYs all the time, it's less confusing.

When the draft describing the transfer issue is done, I expect a new
standard EPP extension that contains the "DNSKEY to be relayed" to the
losing DNS operator, that contains a KEY (Any volunteers to take that up in
this group ?). I also expect by that time that registries will see that it
makes no sense to ask for a KEY one time, and a DS another time.
The only reason to still support DS is then legacy support.

- --
Antoin Verschuren

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJPWG9sAAoJEDqHrM883AgnRa4H/jc79//8AiFTV0q/UYUUsFkw
a4U/pevfcbs8TLU0QzdCDie0nuPO7Eeg/aF5FXY3uFknTgS+nWDAkatAXKBNFNQZ
vzdICrxLY905wO9sOmV9nuAPTEvy4ae42tt4TRwid8/5Q6BOnhgglPt/oYc1qb5d
Ga+V6YUDEYRYEVLdEPPOdXfAzwEPFbtvObKvF6cKayiNr+a4szxSH7YAaLSkkwdy
u0Vc19h9Ztpi06Ohm4ZfzMyxEEqS7ec1qEG3H5bDZt2UFi2C9f60f1KoUtWU3EXa
QYiP+oT3ThgwpT9qOrwZRjlIhp88JsG4AhOEg3D4fpqhgPmyuMbaQ6IvsxgEz20=
=ktvM

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Mar 2012 13:17:08 -0500

> starts and ends with what they can control.    

If that's your position, then you must agree that they should require
the DNSKEY and generate the DS themselves, because the DS is data for
which they are authoritative.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Young <[email-masked]>
Date: Thu, 8 Mar 2012 13:35:44 -0500

Nice turn Andrew, reminds that you have a background in logic :-)

However I would say the dnskey belongs to the subordinate zone and the DS is an artifact of that key - making them responsible, not the registry. Having a bad DS in the registry breaks the  validation path but then so does have the wrong delegated nameservers. The registry IMHO authenticates the party authorized to make changes regarding a registration, not determine if the registrant set their related DNS data right ( and yes I know that there are ccTLDs that prevent registration if this isn't right.) I think monitoring, testing and notifying registrars of mistakes is great and everyone should do it.  But ultimately if they get it wrong it's their zone that breaks, not the TLDs hence why it's their job,......

Michael Young

M:647-289-1220

---

From: Peter Koch <[email-masked]>
Date: Thu, 8 Mar 2012 19:50:29 +0100

Michael,

> by my KSK) or receive a ZSK signed by a KSK I don't control through the

may i humbly ask whether you have read the draft Antoin pointed to?

> I tend to think this should stay between the two DNS operators, as the keys

Absolutely, but in the process of the operator change, these two entities for
which we cannot safely assume an authenticated, secure channel to exist,
need to exchange ZSK information. Old data can be gathered DNSSEC secured
from the DNS but there is no generic way for the losing operator to access
the gaining operator's ZSK.  That's where the registry comes in providing
a dropbox that both operators (at least through their registrars) have
access to. In that sense, the ZSk is not registered and is not processed by
the registry other than being relayed.
I'd hope that the draft is clear about this and the difficulties
arose from the fact it was dropped inmidst this discussion about which object
to register.  If the draft is not explaining that background well, that's
a pity, and we'd appreciate feedback.  That said, a -04 version is in
preparation and while there is a provisioning (read: EPP) component to it
that would go into a separate document, we are most likely going to ask for
feedback on the DNSOP WG mailing list to address the key timing issues first.
Other comments are of course welcome, just trying to avoid the spread.

Best regards,
    Peter

---

From: "Michael Young" <[email-masked]>
Date: Thu, 8 Mar 2012 14:52:31 -0500

I did read it, I was basically agreeing with the process that document lays
out, except I don't like the registry being the dropbox for the zsk exchange
from old to new operator.  Clearing I wasn't expressing that well enough!

However I suppose since I have an opinion, I should suggest another
alternative then, let me think on that and I'm happy to comment on your next
version.

-M

-----Original Message-----
From: Peter Koch [mailto:[email-masked]] On Behalf Of Peter Koch
Sent: March-08-12 1:50 PM
To: Michael Young
Cc: [email-masked]
Subject: DNSSEC operator change [Re: [provreg] Example of stupid
inconsistencies between registries]

Michael,

> I'm not sure why as a DNS operator I would want to either send a ZSK 
> (signed by my KSK) or receive a ZSK signed by a KSK I don't control 
> through the domain registry.

> I tend to think this should stay between the two DNS operators, as the 

Absolutely, but in the process of the operator change, these two entities
for which we cannot safely assume an authenticated, secure channel to exist,
need to exchange ZSK information. Old data can be gathered DNSSEC secured
from the DNS but there is no generic way for the losing operator to access
the gaining operator's ZSK.  That's where the registry comes in providing a
dropbox that both operators (at least through their registrars) have access
to. In that sense, the ZSk is not registered and is not processed by the
registry other than being relayed.
I'd hope that the draft is clear about this and the difficulties arose from
the fact it was dropped inmidst this discussion about which object to
register.  If the draft is not explaining that background well, that's a
pity, and we'd appreciate feedback.  That said, a -04 version is in
preparation and while there is a provisioning (read: EPP) component to it
that would go into a separate document, we are most likely going to ask for
feedback on the DNSOP WG mailing list to address the key timing issues
first.
Other comments are of course welcome, just trying to avoid the spread.

Best regards,
    Peter

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 8 Mar 2012 21:52:38 -0300

On Thu, Mar 08, 2012 at 09:16:04AM +0100, Peter Koch wrote:
...
> In your scenario any DNSKEY that would end up in the registry db
> would have to be present at the apex at the time of registration,
> which prohibits pre-publication of a DS RR for a DNSKEY not yet
> present at the apex DNSKEY RRSet.

Which basically proofs that the DNSKEY interface is not suitable for
pre-publications too. Remember the purpose of this is to not
pre-expose the public-key, so why show it to your registry.

So plain DS, without DNSKEY fetch and check, is the only suitable
interface for this corner case scenario.

...
> -Peter

Fred

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 8 Mar 2012 17:58:03 +0100

> vs. thin here since in the realm of registries these terms are already occupied.

Well, I use it because other people started using it ;-) I think people have used "thick" or "fat" for registries that want to have the DNSKEY for all the DS they have, and "thin" if they just have the DS.

> to be present at the apex at the time of registration,

No, not at the time of registration. At the time the DS is to appear in the zone (after validation that the DNSKEY and DS matches each other). Just like NS records, they can be added much later than time of registration. The validation is similar to the validation some registries do for lame delegation (at time of addition of NS to the parent zone).

It has nothing to do with registration per se, although some registries require delegation at time of registration.

> which prohibits

This is correct.

If the registry want to hold the DNSKEY and they only get the DS and the DNSKEY is not in the apex DNSKEY RRSet, then...

A lot of "if" there ;-)

I see such policies be policies that a registry can implement anyway with the DS interface. For example, I sort of can understand that a registry only want to accept some digest types. That can be done by only accepting some digest types when DS is passed to them. In the case of pre-publication of DS, the registry can say that "if you use the DS interface, the DNSKEY must be present in the DNSKEY apex RRSet at time of passing the DS via epp". I think both of those solutions would be better than refusing to support the DS interface.

That said, I do not understand registries that do not accept DS interface and "just" pass that to their zone and sign it. It seems to much much easier than the for me more complicated DNSKEY interface.

> the DNSKEY is what they already have in their hands.

Correct, we could as well have always passed the DNSKEY to the registry. The problem is not even that some registries ask for DS, some for DNSKEY, but that some refuse to accept DS (in my case). It could, as you say, also have been that some refuse to accept DNSKEY.

To repeat, I have encountered a number of registries accepting DS (they might accept DNSKEY as well) and now suddenly one that only accept DNSKEY and not DS.

I felt that was a situation complicated enough for the registrar (me) and the registrant (our customers) that I wanted to discuss the situation on this list.

Which I thank you all for the ability to do. It has been a good conversation.

   Patrik

---

From: Peter Koch <[email-masked]>
Date: Fri, 9 Mar 2012 15:23:48 +0100

Fred,

> pre-expose the public-key, so why show it to your registry.

i was not referring to the purpose of hiding the key (a myth anyway)
but to what 4641bis (4.1.3) calls "double DS rollover".  That
section explains why there is not always a DNSKEY RR in the DNS
for a DS to be published at the parent.

-Peter

---

From: Howard Eland <[email-masked]>
Date: Fri, 9 Mar 2012 10:39:59 -0600

> Correct, we could as well have always passed the DNSKEY to the registry. The problem is not even that some registries ask for DS, some for DNSKEY, but that some refuse to accept DS (in my case). It…

Ah, but this gets back to registry policy.  Earlier in this thread, someone had mentioned that protocol should not (as far as possible) dictate policy.  Because the ultimate party responsible for the DS RR is the parent, they should have the flexibility to set policy on how they want to generate this record - either have it handed to them, or to generate it themselves.  As I've stated earlier, both have valid points, so the protocol was written to allow either.

> To repeat, I have encountered a number of registries accepting DS (they might accept DNSKEY as well) and now suddenly one that only accept DNSKEY and not DS.

... and this sounds like a poor (or non-existant) transition plan, not a fault of the protocol.

> Which I thank you all for the ability to do. It has been a good conversation.

Indeed it has.  

-Howard

---

From: Ulrich Wisser <[email-masked]>
Date: Sat, 10 Mar 2012 22:58:48 +0100

Hello everybody,

sorry I am late for the party. :-)

In my opinion we did quite well with 5910. We allowed both policies and 
made it possible for registrars to interact with hundreds of registries 
with only two distinct interfaces.

Maybe we could have done better on EPP implementation policies. Maybe 
Postel's Law, "be conservative in what you do, be liberal in what you 
accept from others" could be applied here. If a registrar sends both DS 
and DNSKEY interface the registry should choose one and ignore the 
other. And not reject the command. Although I am not really convince 
that this would be a good thing.

/Ulrich