-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Antoin,
On 04/19/2011 11:42 AM, Antoin Verschuren wrote:
> 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.
Would it be resolved if we use the following text?
s/appears/may appear/
...; it is not listed in the NS RRSet, although its name may appear
in the SOA RRs MNAME field.
> 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.
You are right.
Best regards,
Matthijs
> I have not finnished to review the complete document yet, but will do
> before the deadline.
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNrWFqAAoJEA8yVCPsQCW5cHMH/1Owj4PBlDByl4Qm/HzjWnSh
WRXgrvTuwlsPomSbyUSSF7wSYZbq3S2MsRMizTR+IonGCBtbtlPC3WhKSZ4ZKyrd
kDzzHthLauplspFZ8pwVZMQ9dzfZZ73PUErlpM2Jt1qnXeuWvAPK+G/0WboUnPkS
iorowB/llIL+bXu9ugfagehk3m8XvlaEgMLNm5X6rzeZnrpl5osbFVMhaeOagzhV
6+QvwAEBBIc3Ttro1cz3rCtzqFdt6GOAUDC1yT15v1L6f6yDW6bCtdvwFUAaGYrQ
WqqH/ZcxjOZtpOepmuRjX9N/YD1TWupOSccQochfqKTLLILQsAw4M6GDVP7/MXU=
=6MqR
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
