On Tue, 19 Feb 2013, Marc Lampo wrote:
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)
I don't think these are worth the complexity.
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.
Because ZSK might be online, and KSK might be offline. It should come
from the KSK, not the ZSK, or else the ZSK can change an offline KSK.
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.
IMHO, al ofthat is implementation and does not belong in a protocol
specification.
4) Should the parental agent check all authoritative name servers of a
domain for a consistent CDS RRset ?
Yes, as I said in my previous email.
5) (this is tricky !) Security section states : "not for initial enrollment"
Why not ?
There is no path of trust!
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
