Add hooks for AXFR/IXFR processing
- Program: Authoritative (
slave=yes) - Issue type: Feature request
Short description
Zone transfers happen in an asynchronous way. While you know exactly which records PowerDNS will serve on a MASTER zone by looking into the backend's database, you never really know when PowerDNS tries to transfer a SLAVE zone, actually completes successful or what kind of errors happen.
Steps to reproduce
- It is possible to trigger an AXFR request by the
axfr-retrievewebservice. - It is possible to trigger an AXFR request by the
retrieve DOMAINcommand of thepdns_controltool. - There's no follow up, though, once PowerDNS is put into action.
Expected behaviour
- There's a
lua-axfr-scriptsetting which allows to incept a zone transfer. - The same can be accomplished per domain via the domain metadata
LUA-AXFR-SCRIPTsetting - The hooks should be extended to allow interception when a transfer is being initiated, has been postponed, raised an error and completed successfully.
Actual behaviour
- Scripting in slave zone handling is limited to incepting individual records. While the Lua example script and the Recursor Lua Scripting provide an extensive set of hooks, the only one that is available during zone transfers is
axfrfilter. - Events will show up randomly as free-form text in the log file as the code for zone transfers is doing its job, but it's hard to trigger any further action by it.
Other information
As more hooks will be added, more actions than altering records need to be added as well. For example triggering events for RabbitMQ, calling an external webservice etc.
Usecase
When you have a slave or hidden primary DNS setup, you can add a zone to be regularly synced with a master, but it's hard to stay in the loop. Even once the initial transfer has been successful, there might be future errors you don't know of, like
- a master not accepting TCP requests
- a master not accepting AXFR requests from the slave
- the zone transfer being interrupted / unsuccessful
- the operator of a master applying changes to the zone but forgetting to increase the serial and thus impatiently waiting for the changes to be transferred to the slave
If you are even scaling this to tens of thousands of zones like in the setup of a hosting / DNS provider, things get cluttered very fast. You might want to
- tell your client about errors
- provide the timestamp about the last successful transfer
- provide a look into the actual records of the slave zone currently served, for reference and verification
- link actions to certain events, like sending push notifications, signing a zone, making sure the number of records per zone stay in a given limit etc.