[dns-operations] dns-operations Digest, Vol 91, Issue 33

[Bob Harold]

Joe wrote:


> Date: Tue, 27 Aug 2013 11:27:56 -0400
> From: Joe Abley <jabley at hopcount.ca>
> ...
> Cc: dns-operations at lists.dns-oarc.net
> Subject: Re: [dns-operations] Implementation of negative trust
>         anchors?
>
> ...
>


> I've long wished for a more general facility where upon successful [AI]XFR
> I could shell out to an arbitrary local executable and do whatever checks I
> wanted before signaling with exit status that "this zone is ok to serve".
> With a bit of state held on disk about previous zones you could include
> some of those temporal checks and perhaps catch a few more problems.
>
> Joe
>
>
In BIND 8, at a previous company, I renamed the "named-xfer" executable to
"named-xfer-real", and put a script at "named-xfer" that called
"named-xfer-real" with a temporary output file, then checked the zone for
sanity, and saved a diff log, then copied the file to the real file
location and signaled BIND that it had transferred. The master had some
automation that occasionally produced only a partial zone, so the checks
were an absolute necessity.  And the diff log told me exactly when changes
hit my servers.  (All my DNS servers had this setup.)

I don't think BIND 9 uses a separate zone transfer program, so it would be
more difficult now.  I could have a separate script check for updates, do
the transfer, move the file into place, and signal BIND, where BIND is
configured to think it is the master, and reads the zones from files.  Or I
could have a second copy of BIND on a different IP as a slave, and watch
the log for transfers, then copy them to the main BIND configured as master.

The extra checking is nice, but it increases the complexity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130827/26ca2133/attachment.html>