-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 04-03-13 18:16, Joe Abley schreef: > Hi Antoin,
Hi Joe > It's clear that we have different opinions on this, and I don't > want to argue for the sake of noisemaking. However, I have a couple > of clarifying questions (see below). And I'm shouting a bit too acting as a devil's advocate. Please don't get me wrong in that I'm not trying to see your points. I just think that a tree is either experimental or production, but it's unwise to be both. The discussion is on where the subtree starts. > How is it safer for the operator of a parent zone to generate DS > RRSets from supplied DNSKEY RRSets (constrained to only those > algorithms the parent has blessed) than to accept any DS RRSets > from children? There are some parents that check/verify the RDATA in their zone. As a service to help children notice their mistakes or misconfigurations. This service is often appreciated, except for children that willingly want to be able to enter invalid data into the parent zone, and want to force the parent to accept that. For a parent to be able to validate, they need to understand and have implemented the algorithm in their validation software. If the parent generates the DS, he knows he understands that algorithm, so there's one less thing to worry about. Creating the DS yourself is easier than trying to verify a DS and refusing the ones that are not understood. And when we want to change the algorithm in the future with one that is more secure or cheaper for our zone, we can do that ourselves without a painful migration process that involves all our child operators. > So, to clarify, can the operator of a child zone who prefers to use > an algorithm 14 DNSKEY send you that key, confident that you will > accept it? What about algorithm 253? No. If the child prefers to use an experimental algorithm as a SEP for it's own experiment, he can happily enter that into his DNSKEY RRset. And he can generate or accept DSes for all the children under that zone that want to experiment with that algorithm in that tree. The chain of trust for that experiment starts at that subtree. But we don't accept that algorithm for the delegation in our chain of trust that starts at the root until that algorithm is widely deployed in the validating resolvers we serve. That's our local policy. We do DNSSEC because we want all end users be able to validate the delegations we make. DNSSEC is only adopted if it works and is reliable. Our zone is not (partly) experimental. So we validate delegations, and receive validation errors from ISP's that we distribute to the registrars so they can fix their errors. We currently accept a wide range of algorithms we know are implemented in most of the validating resolvers. Using an algorithm we know is not widely implemented will cause validation errors in the majority of resolvers we serve, and we feel responsible that at least our zone and the delegations we make work. What happens in trees below is the responsibility of the delegated party and their local policy. We wouldn't have seen the gigantic uptake of DNSSEC under .nl if we didn't guarantee to our constituency that we would actively make DNSSEC work for at least our zone. Our zone is not experimental anymore, it's production. > Rather than "historical" I would have said "common practice > today". Yes, I must agree if you count number of registries and not the number of delegations. I must say we could have lived with the "sending DS" with the knowledge we had 5-10 years ago. We then thought that sending DS was less error sensitive because of the shorter string, and we would still be verifying DS submission over the phone. But our recent experience with DNSSEC, where automation has improved, shows that this is hardly an issue. More errors are being made within smaller incapable operators creating and matching their DS from a DNSKEY then when they just send in their DNSKEY and we create the DS for them. So I also have a bias towards "sending DNSKEY" out of experience and not theory. But our major motivation for "sending DNSKEY" is the secure DNS operator change I mentioned. This has not been implemented yet by these registries, so there's no real world experience with most of the registries that now only accept DS. Sending a key format for a DNS operator change, and a DS format for a delegation request makes matters complex for the child operators. That's why we accept key format for all. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRNcgkAAoJEDqHrM883AgnepAIAJIMwS3Yp49KkXLt8IyZKsRJ mpXsYy9Z3eKUELc50uCXoAWI2eHhuHTwxS5lhj2/UBfLF5qLCgBeJmJ47Zkn0Jr3 MBM+jdASp31/mR1/dU3jkfDINo0nIZ59OAQEu/rMUDjrnf8lovHXLQ2OJeFwLhIf Czsaqc0ywRlO0gEIuy4yKsuC1mIgsQAV08lhOOrpZhbZaYdYxDQySRjgN+jvHhyB GNILrEuBcNdCxowo3TN0kYYY29Vy1/eIboJzmHKQpS7N58vj2HUJAPZVNLOeUEjG WbemKk2gY2hiNX6/wgjmS0wTE7PN+pQIX5OsK+Ej2OXWrPD9CdI/jQAKIo84T0I= =RwKJ -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
