On Mar 1, 2013, at 18:58, Tony Finch wrote: > Edward Lewis <[email protected]> wrote: >> >> I'm hoping to avoid yet another too-large RRset that could cause >> problems in abuse situations. > > Hmm, I wonder if it would be enough to put only the key tag in the CDS > RDATA, and let the parent calculate the DS from the corresponding DNSKEY.
I would have liked to go that way, but there are reasons why not: There is an operational case of a TLD having a DS record in the root not pointing to a DNSKEY. (Just to establish that this is not hypothetical.) There's no requirement that the DS "point to" a published DNSKEY to allow for a key change that only wants to have one SEP at a time. This allows the child to choose the hash fields it wants. The key tag is not guaranteed to be unique. In fact, there have been keys present in TLDs that have the same key tag but different algorithms. To be clear, different TLD, different algorithm, different keys - same key tag/foot print. And finally - I have this "moral objection" to having the registry calculate the hash - a registry should just be recording the objects thrown it's way. Okay, pre-delegation checks, etc., but I draw the line at the parent "altering" data unilaterally. PS - If a registry insists on calculating the hash, well, it won't be able to support pre-publishing of DS records. But if the DNSKEY is there, it can ignore the hash and redo the work. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
