PowerDNS "passthru-notify" Patch Release

[Habbie]

This patch will allow you to redirect PowerDNS notify messages away from
neighboring NS servers to a "passthru" server. It is intended to fix
notify/axfr behavior in anycast clusters of PowerDNS auth servers
however it may be useful for other situations.

The configuration option "passthru-notify" has been added to the
pdns.conf parser. The option accepts multiple IPv4 and IPv6 address values.

The patch was based of the latest stable release so we can contribute this to the PowerDNS community. It tested OK with the latest
trunk as well (only a few offset warnings). The patch is expecting to
find a "pdns-3.1" directory so if you name it something else use -p1 and
patch from the root of the distribution.

Patched servers carry a "3.1-ptn" in their version.bind by default.

pdns.conf:

passthru-notify IP address we send notifications to

passthru-notify=127.0.0.1, ::1

LATEST STABLE:

~$ patch -p0 < pdns-3.1-ptn.patch
patching file pdns-3.1/configure.ac
patching file pdns-3.1/pdns/common_startup.cc
patching file pdns-3.1/pdns/mastercommunicator.cc
patching file pdns-3.1/pdns/misc.cc
patching file pdns-3.1/pdns/misc.hh
patching file pdns-3.1/pdns/pdns.conf-dist

TRUNK:

~/pdns-trunk$ patch -p1 < ../pdns-3.1-ptn.patch
patching file configure.ac
patching file pdns/common_startup.cc
Hunk #1 succeeded at 121 (offset -1 lines).
patching file pdns/mastercommunicator.cc
patching file pdns/misc.cc
Hunk #1 succeeded at 777 (offset 12 lines).
patching file pdns/misc.hh
Hunk #1 succeeded at 438 (offset 1 line).
patching file pdns/pdns.conf-dist

Version report:

version.bind. 5 CH TXT "Served by POWERDNS
3.1-ptn $Id: packethandler.cc 2631 2012-06-20 10:12:20Z peter $"

Ralph Covelli
Hurricane Electric / AS6939
rcovelli@he.net

[Habbie]

Attachment 'PowerDNS "passthru-notify" Patch' (pdns-3.1-ptn.patch) https://gist.github.com/5466846

[Habbie]

Attachment 'PowerDNS "Passthru-Notify v6" Patch Release' (pdns-3.2-ptn6.patch) https://gist.github.com/5466847

[Habbie]

Author: anon
Brief timeline:

(failed) Version 1 was only able to redirect notifications from the originator. This was not sufficient for our needs.
(failed) Version 2 attempted to use the notification queuing system to send the relays. This is not what we wanted.
(failed) Version 3 attempted to bypass the notification queuing system and send the relays with the notification sockets directly. These sockets only exist when the communicator system has been initialized.
(failed) Version 4 used individual resolver objects to relay the notifications. This worked on production servers but did not scale.
(failed) Version 5 used the regular slave check code before relaying to a passthru server. This version suffered the same scaling problems Version 4 did.
(succeeded) Version 6 uses a static passthru resolver object. It scales correctly and appears to run stable on the production servers.