-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16-10-12 16:03, Matthijs Mekking wrote: > Hi all, > > The document draft-ietf-dnsop-rfc464bis-13 has seen some issues > while being in AUTH and RCF-EDITOR state. This e-mail will list all > the suggested changes to address those issues.
While reading the proposed changes and the whole document again, I noticed another paragraph that is no longer desired. My question is that now that we do make some changes, it is advised that this paragraph is also adjusted to fit current day practices. The paragraph is 4.3.2. The advice in this paragraph, which hasn't changed since 2009 when it was first written down, has been overtaken by new insight and practices. It advises registries to store only DS in stead of DNSKEY material in their database. This has proven to be impractical when deploying DNSSEC on a large scale: 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. 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. 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. 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. 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. If needed, I'm willing to write text. - -- 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:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQhoBVAAoJEDqHrM883AgngBMH/1e5LxpQrZNLJ/lV5kp2OJFx WWsKM2joRSSpW+fc/CMp6gQ5kMs32TqjAk3SLGcUEnKKU1L4zBOPIPzHNfyryqEp +Mckt+LGtC9/OngjTtfKGvfejLmUormu0zmwSTW5hJqUi16lz4chHosJtvI3JNpZ s73gDUW11zAxomyJw3bkBOQQgPklpV+7IOAGMeRkxXPUWvhMaPYsGwppZFI4nX49 Bw5zYytnL9YbfdK+LzY7DY5j3ZoEVV6056w7Gn2U4or8IBTQxquR9rpA0XHmrYPv C07lSeDdwu7jGrv4Qt2ORcZwjvSVYmDD5q3q84w8ZAe7/LU7JAiRaTPIrOBHmoc= =HVX8 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
