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 +1-571-434-5468
2012...time to reuse those 1984 calendars!
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
