Hello,
a couple of constructive remarks :
1) Should the CDS RR have the same fields as the DS ?
Or : is there any benefit in adding a field with some "operation
code" (failing a better name)
Suppose a code is added :
0 could mean : corresponding KSK created - this will be the DS -
don't publish yet
1 could mean : I'm hold data for a DS to be published
2 could mean : IKSK is retiring - no longer publish this data in a DS
Might help for troubleshooting :
like - why is the DS no longer there --> look at CDS records.
In the present draft : no CDS records <-> no corresponding DS (but
there is no history info)
Also, the present draft suggest "@ IN CDS 0 0 0" to go unsigned.
But the situation where "@ IN CDS 0 0 0" appearrs *together* with
another CDS that does hold data is not described.
If there will be no "operation code", handling of above error case
should be in the draft, I think.
2) "SIgned with a DNSKEY that has the SEP bit flag set" ?
Why ?
If there is chain-of-trust up till and including the ZSK of the zone,
why not "trust" that information.
On one side : some name server implementations use KSK's only to
sign DNSKEY RRset's.
It requires extra arguments or change in the code to consider CDS's as well.
On the other side : would it be an error to publish 2 KSK's, but
sign CDS RRset with only one of them ?
I think this point needs more motivation - or there should be no
insisting on signing with KSK's.
3) Periodic check by parental agent
I think this should be extended by stating that logging of "somehow
rejected" CDS RRset should be done.
At what time,
from with authoritative NS,
wich CDS RRset received
and why it was not used for publishing.
4) Should the parental agent check all authoritative name servers of a
domain for a consistent CDS RRset ?
Perhaps just mention, in the draft, what the expected behavior is.
I remember from previous contributions I made - while still at a
top-level-domain myself -
that some reactions might/will be : "not our responsibility".
I'm OK with that, but I'd suggest the draft states what is to be expected.
5) (this is tricky !) Security section states : "not for initial enrollment"
Why not ?
If it is "not our responsibility" (if a DNS operator messes up the
signed zone) anyway,
why not "detect" the presence of :
DNSKEY RRset
valid RRsig's
CDS RRset (properly signed with a published DNSKEY)
(for validation, use the DNSKEY the RRSIG refers to, "believe"
it without chain-of-trust being in place)
(if there is no CDS RRset - or there is with some "operation code" == 0,
then, don't publish)
This would overcome the initial 12 steps to bootstrap a zone with DNSSEC.
6) Please correct the address of author George Barwood
(or you get too much email, Warren ;-)
Kind regards,
Marc
On Mon, Feb 18, 2013 at 11:35 PM, Warren Kumari <[email protected]> wrote:
> Hi all,
>
> This is a compilation of two earlier drafts, draft-barwood-dnsop-ds-publish
> and draft-wkumari-dnsop-ezkeyroll.
>
> The basic idea remains the same -- allow operators to publish new (and
> standby) DS records at the parent by publishing them in their zone, signed
> with their current key.
>
> This new draft explains the problem a little better, and also that, in the
> "registries shouldn't talk to registrars" model the registrar can do the
> magic instead.
>
> We believe that there is a need / desire for this -- apart from the fact that
> *I* hate having to click all over the GoDaddy web site to change keys, we
> have heard a number of registrars and registrars asking for it...
>
> W
>
> Begin forwarded message:
>
>> From: [email protected]
>> Subject: New Version Notification for draft-kumari-ogud-dnsop-cds-00.txt
>> Date: February 18, 2013 4:06:00 PM EST
>> To: [email protected]
>> Cc: [email protected], [email protected]
>>
>>
>> A new version of I-D, draft-kumari-ogud-dnsop-cds-00.txt
>> has been successfully submitted by Warren Kumari and posted to the
>> IETF repository.
>>
>> Filename: draft-kumari-ogud-dnsop-cds
>> Revision: 00
>> Title: Easy DNSSEC Key Publish
>> Creation date: 2013-02-18
>> Group: Individual Submission
>> Number of pages: 8
>> URL:
>> http://www.ietf.org/internet-drafts/draft-kumari-ogud-dnsop-cds-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-kumari-ogud-dnsop-cds
>> Htmlized: http://tools.ietf.org/html/draft-kumari-ogud-dnsop-cds-00
>>
>>
>> Abstract:
>> This document describes a method to allow DNS operators to more
>> easily publish updated DNSSEC Key Signing Keys. This document does
>> not address the initial configuration of trust anchors for a domain.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>
> --
> Life is a concentration camp. You're stuck here and there's no way out and
> you can only rage impotently against your persecutors.
> -- Woody Allen
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
