Simple problem is search of a simple solution

[Kevin Darcy]

Ronald F. Guilmette wrote:

> In message <3B1EAACA.90A677A0 at daimlerchrysler.com>,
> Kevin Darcy <kcd at daimlerchrysler.com>u wrote:
>
> >Neither the DNS protocol nor BIND supports automatic slaving currently.
>
> Thank you for confirming what my own, very limited research, had already
> indicated.
>
> >However, it would only be a minor protocol change to allow NOTIFYs to be
> >cryptographically signed. If NOTIFYs could be trusted, then I don't see any
> >reason why they couldn't be used to trigger automatic slave creation.
>
> Well, yea.  It's that last part that is of most concern to me at the moment...
> the ``automatic slave creation'' part.  We can't even do that (with the
> existing protocol) at the moment. :-(  That a showstopper right there,
> so I'm not even thinking about security issues.  That's secondary.  I
> can't even do what I want _at all_ right now, so I'm not worrying about
> how to do it securely.
>
> >In the meantime, plenty of folks have cobbled together solutions to this
> >problem. One common method is to have some sort of "zone list" in DNS,
> >composed of TXT or PTR records. The would-be slaves check that list
> >periodically and start/stop slaving zones as necessary.
>
> Uggg.  Sounds like unnecessary complexity.
>
> I think that I would rather just rdist or tftp a named.conf include file
> out to all of the slaves whenever there is a change in the master copy (of
> that named.conf include files) on the master server.  Then I have to work
> out how to kick the slaves, and get them to each do a named.reload right
> after they each get their (updated) copies.
>
> It really is rather a pity that BIND can't do this sort of stuff all on
> its own, instead of me having to kludge this together.  That would be a
> lot nicer.
>
> >... A more radical approach is to not use AXFR/IXFR for
> >master/slave replication at all. Use something like rsync-over-ssh to
> >replicate the zonefiles...
>
> Thanks, but at this point, I'm not even sure that I care about moving
> zonefiles around.  I _may_ perhaps just want to configure all of the
> slaves to forward queries for the relevant zones to some other place,
> in which case there aren't even any zonefiles anyway.
>
> Basically, I just want to get a hunk of named.conf stuff from point A
> to points B, C, D, and E every time the hunk changes on A.
>
> >Note that even if NOTIFYs *cannot* currently be trusted...
>
> Like I say, I'll worry about the security issues later on.
>
> For now, what I wish I had is something rather different from a
> traditional NOTIFY.  Instead of saying ``Hey!  Here is a new copy of an
> zone!'' I want server A to say to servers B, C, D, and E ``Hey!  Here is
> a new copy of _just_ the configuration file stuff for a BRAND NEW zone
> that you have never heard of before.''

But the latter is just a special case of the former. If a nameserver is
configured to automatically start slaving new zones that are mastered on a
particular server, and along with that configuration it has some sort of template
of how the zone { } statement should look for new slave zones, then when it gets
a NOTIFY from that master for a zone it's never heard of before, it could
automatically set itself up as a slave for the zone. At that point it just comes
down to the security issue -- how can I trust that this NOTIFY really came from a
trusted source? The NOTIFY-signing issue is the only protocol obstacle here. The
rest is just implementation.

In the absence of this capability in BIND itself, it shouldn't be too hard to
have a script watch the logfiles for these NOTIFYs, do the necessary
verification, and then modify named.conf and reload the nameserver.


- Kevin