multi-signer prep

[johanix]

There are a number of things needed for tdnsd to be a viable "signer" in a multi-signer context. Among them:

• [x] A more sophisticated model for a zone's DNSKEYs. Must include a distinction between internal keys (that may be rolled) and external keys that belong to another signer and should just be kept in the RRset.
• [ ] Same thing for the NS RRset: internal and external NS.
• [ ] Either add support for TSIG or add SIG(0) support to MUSIC or add API support to both so that they communicate. API support probably best alternative.
• [ ] Add support for sending NOTIFY(DNSKEY) sideways (to either a central MUSIC or a sidecar MUSIC) when the contents of the DNSKEY RRset changes.

Initially we will not add any key rollover support to TDNSD.

[johanix]

How should a MUSIC sidecar and TDNSD shake hands? In the API case we can do whatever we want, but in the tdns-agent + DDNS updates the communication is more limited. The base line things that need to be established are:

• [ ] TDNSD/tdns-agent should notify MUSIC about DNSKEY events for the following zones ...
• [ ] TDNSD/tdns-agent should notify MUSIC about changes to delegation data (i.e. same trigger as will initiate a sync with the parent) for the following zones ...

For DNSKEYs it would seem suitable to send a NOTIFY(DNSKEY) when changing ZSKs, but perhaps a NOTIFY(CDS) when changing KSKs. For changes to the delegation data, why not send a NOTIFY(CSYNC) to MUSIC (in addition to sending it to the parent).

How to know where to send these notifications? TDNSD/tdns-agent could look for the DSYNC RRset in the zone, but for a new scheme, perhaps "MULTI-SIGNER NOTIFY", aka scheme=4.