-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18-04-11 21:01, George Barwood wrote: > I have a few comments. > > (1) It's my belief that almost all Zones except for the root zone should NOT > use a KSK/ZSK split.
I don't think this is true. I think the split of when to use a KSK/ZSK and when not is not that clear. But it depends on: - -Time and operational difficulty to communicate a new DS to parent - -Size of the zone, and frequency of updates to zone content. A large zone, that has frequent updates, and has a timeconsuming, difficult or strict parent-child relation is better off using KSK/ZSK. A small zone, that has very few updates, can just as well use 1 key. I have some more questions on the draft. In section 3.4.3 I read: "Although not mandatory, one could administer a zone using a "hidden master" scheme that minimize the risk. In this arrangement the master that processes the updates is unavailable from general hosts on the Internet; it is not listed in the NS RRSet, although its name appears in the SOA RRs MNAME field." This seems to me to define what should be listed in the SOA RRs MNAME field in case a hidden master is used. Another definition could well be that when you use a hidden master, one of the public nameservers should be appointed to be the public master, and it's name should be in the SOA RRs MNAME field, as that server should allways be accesible over the public Internet, and the name in the MNAME field should allways resolve (to a public IP) and be in the NS RRset. If would appreciate if someone could point me to standard-track text where this is defined. Section 4.3.5.2, first paragraph: "If the registry and registrars allow for DS records to be published, that do not point to a published DNSKEY in the child zone, the Double-DS KSK Rollover is preferred to resolve the non-cooperative case." I think this should be: "the Double-DS KSK Rollover is preferred to resolve the cooperative case." In the non-cooperative case even a Double-DS does not make sense, and one should go insecure. I have not finnished to review the complete document yet, but will do before the deadline. - -- Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, 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.10 (GNU/Linux) iQEcBAEBAgAGBQJNrVjlAAoJEDqHrM883AgnzzAH/0fB5pxb2RFZDw5pj+84Phcx er7wqozZh0RBQZN1DCdir6GiZe7ILcnWrl48Mbf9wMV4TwZrws7a08NP4zxLr3yp 2SB2kKK+lW6OEgtyx3T0RcuIEEubXZRgZRAvbrThAh5qvDXzwObzpsMWGu7jmVFc 7csFgQKVrn+ioVHIkIpx2CGlk++8gyJBiec2nf5slUz2DFPVWHEEi2141cuEpEYg j1LFx2B/F74Vobyq6vq8eb0rScT8F4NdywRyw/fcgMZPYGUcPEtGfE4DBicX7w7k +svTDcAd34pQucIjKpxabzyFz5YGE23FWkpgMjmSC7pvbADaf2oxkHW4itW4ReY= =XGYz -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
