pdns icon indicating copy to clipboard operation
pdns copied to clipboard

Add hooks for AXFR/IXFR processing

Open martenlehmann opened this issue 6 years ago • 0 comments

  • 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

Expected behaviour

  • There's a lua-axfr-script setting which allows to incept a zone transfer.
  • The same can be accomplished per domain via the domain metadata LUA-AXFR-SCRIPT setting
  • 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.

martenlehmann avatar Aug 29 '19 16:08 martenlehmann