The reason for the tdns-agent is for the (very reasonable) case where a zone owner doesn't trust tdns-server enough to be willing to move the primary role to an experimental piece of code. However, this leaves tdns-agent with a situation where it may need to update the zone in the primary end (in the child role it could be adding a KEY RR, in the parent role it could be adding a DSYNC RRset, or changing the delegation data for a child zone, or ...).
Sofar then plan has been to just save the changes in a DB and report on them when queried.
However, a better, or at least more powerful mechanism would be to configure tdns-agent to send the changes as DNS UPDATEs to the primary. This would obviously require a configuration in the primary with a suitable update policy. It would also require the tdns-agent ZoneUpdaterEngine() to have a third mechanism for dealing with a change request: in addtition to the existing "apply directly to zone data" and "store in a DB table" we also need "apply via DNS UPDATE to the primary".
The good thing is that we already have lots of support for DNS UPDATE in the code base. The bad thing is that we likely should add support for TSIG in addition to SIG(0).
[ ] Steal the TSIG code from MUSIC and put into the tdns lib. Will require various modifications.
[ ] Add a new zone option, something like "agent-update-primary" that is ignored unless this is tdns-agent.
[ ] Add TSIG details somewhere in the config for the zone.
[ ] In the ZoneUpdater(), when running as tdns-agent check whether the option is set and then send a TSIG-signed update to primary, otherwise store update in DB.
The reason for the tdns-agent is for the (very reasonable) case where a zone owner doesn't trust tdns-server enough to be willing to move the primary role to an experimental piece of code. However, this leaves tdns-agent with a situation where it may need to update the zone in the primary end (in the child role it could be adding a KEY RR, in the parent role it could be adding a DSYNC RRset, or changing the delegation data for a child zone, or ...).
Sofar then plan has been to just save the changes in a DB and report on them when queried.
However, a better, or at least more powerful mechanism would be to configure tdns-agent to send the changes as DNS UPDATEs to the primary. This would obviously require a configuration in the primary with a suitable update policy. It would also require the tdns-agent ZoneUpdaterEngine() to have a third mechanism for dealing with a change request: in addtition to the existing "apply directly to zone data" and "store in a DB table" we also need "apply via DNS UPDATE to the primary".
The good thing is that we already have lots of support for DNS UPDATE in the code base. The bad thing is that we likely should add support for TSIG in addition to SIG(0).