Re: [DNSOP] Changes since draft-ietf-dnsop-rfc4641bis-13

[Edward Lewis <[e-mail]>]

At 13:32 +0200 10/23/12, Antoin Verschuren wrote:

>1. Current practice proves that the majority of DNSSEC domains in the
>world today is provisioned by sending a DNSKEY record to te registry,
>and not DS. Running code for the majority of DNSSEC domains uses DNSKEY.

Do you have any proof of this?

I say this in the spirit that outside of .NL, I am not aware of any 
other TLD that takes the key.  I am sure there are others, and I am 
not measuring this factor.  But given what I know, I am surprised at 
the assertion made here.

>2. The old advice is based on the assumption that less errors are
>being made when cutting and pasting a DS in a webinterface or reading
>it since it is smaller than a DNSKEY. Current practice today however
>is that this is all automated, and while provisioning 1.3 M DNSSEC
>domains, we have not seen such errors.

OTOH, we haven't seen problems with the other approach.  We don't 
have 1.3M DNSSEC zones though so I can conclude nothing.

What would be meaningful is to find an example on par, size-wise, 
with your example that opts to accept only key records and show that 
it encounters errors (in significant numbers).

>3. With more algorithms used for DNSSEC today, and some no longer
>advised, registries want to hash the DNSKEY to DS themselves so they
>don't need to go through a "contacting every child" nightmare when an
>algorithm is no longer supported. The DS is owned by the parent, not
>the child. Our practice shows that hashing is a minor operation by the
>parent. It takes no real effort whatsoever in computation or time.

Hashing was never the question.  The rationale behind the suggestion 
to just take DS records was based on liability concerns and the 
thought that a registry is just about mapping information (from 
object to entity) and not about producing information.

>4. The most important motivation for us to use DNSKEY is consistancy
>with new processes that did not exist in 2009. DNSSEC secure transfers
>(http://tools.ietf.org/id/draft-koch-dnsop-dnssec-operator-change-04.txt)
>is the most important one. In a DNS-operator change, the operator
>initiating the change needs to send his new KSK (DNSKEY/DS) to the
>registry AND needs to relay his ZSK (DNSKEY). It is confusing that in
>bootstrapping a delegation a DS needs to be sent, but when transfering
>a DS AND ZSK DNSKEY needs to be sent. It is better to use DNSKEY in
>both processes so a child operator is never burdened with calculating
>a DS or having to think about 2 different fields in EPP that do not
>have the same meaning. So our advise is to use DNSKEY syntax for both
>KSK and ZSK when transfering to your parent.

There is a discussion to be had, no doubt, but even here you are 
citing a document that is "just" an internet draft as a basis.

>So my advise is to either delete paragraph 4.3.2 since it is bad
>advice (there is no convincing motivation given in this paragraph
>anyway), or use the motivation given above to advise for using DNSKEY
>over DS.

You'd have to demonstrate that it is "bad advice."  You've only 
justified why you have opted to design your operations to accept keys 
and not limit the input to DS records.  Not that your choice is wrong 
or invalid, but an example of one doesn't indicate consensus.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

2012...time to reuse those 1984 calendars!