On 7/8/13 9:39 PM, "Andrew Sullivan" <[email protected]> wrote:
>On Mon, Jul 08, 2013 at 06:49:53PM +0000, Dickson, Brian wrote:
>>
>> Thoughts?
>
>My immediate thought is, "What problem is this trying to solve?"
Automating NS changes on the parent side, via child-signed-and-signalled
in-zone data. If the CDS keys are needed for a change of DNS provider,
it implies a new NS set on the parent (as well as the apex of the child).
E.g. if someone needs to move a bunch of domains from one set of name
servers
to a different set, tools are likely better than doing it manually. CDS
addresses the DS/DNSKEY part, but leaves the NS part unchanged.
It's a problem which I presume exists or might exist, which goes along
with the CDS problem: how do you automate "X", where "X" is currently
done via web form? ("Automate" might merely be "integrate into a
provisioning
system").
I don't know if the problem actually exists, so until someone says,
"Yeah, it is a problem", it is probably premature.
It would really only make sense (or add value) if the domains were
already DNSSEC delegations, and already doing CDS.
If the key roll is being prompted by NS changes, then tying (loosely or
tightly) the NS move with the CDS change, then the process reduces the
probability of resolution breaking for any of the bunch.
It would make sense basically only if the "PNS" RRset was signed, and
would provide cryptographic protection on it, allowing for an in-band
method of changing the NS on the parent side.
It's not necessary, merely a convenience, or a way of facilitating better
provisioning tools.
Brian
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
