[nsd-users] Multi-master mode NSD

[Rick van Rein]

Hello,

I am setting up NSD on systems that I intend to replicate
to locations.  Due to replication, the distinction between
a master and slave, and whether it is needed, becomes
interesting.  It got me thinking that multi-master mode DNS
could be possible.  And as far as I can see, NSD3 can, or
can almost, support this mode of operation.  Has anyone
tried this before?


--> But why?

You might wonder why multi-master mode is a good idea.  I
think it can be useful because it limits the dependency on
a single master (which effictively is a single point of
failure).  Of course there should be a replicated version
of the signing infra as well.

Additional places where this might be interesting is when
a DNSSEC signer is added to the master mix; when it starts
exporting signed zones it could be picked up by name servers,
simply because the SOA serial number of the signed zone is
higher.  IOW -- it aids simplicity of DNS infrastructure
(but it also looks at it in a different manner, which may
take some getting used to).


--> But how?

First, NSD does not configure master/slave distinctions
with a flag, but merely adds allow-notify and request-xfr as
a way to retrieve zone data, which is functionally the
requirement for a slave.

I was thinking that setting up the master's IP on all locations
would not hurt, as a notify to oneself (and a possible xfer for
any reason) would not actually update the zone, as the data would
be the same as it was.  That's what you get when you are talking
to yourself -- you won't hear anything you didn't know yet.

If multiple master IPs are configured, the highest SOA serial will
determine the winning zone data.  This also applies when making
changes locally.  So if an _other_ site has been updated, this pulls
that data into NSD.  Sending NOTIFY or otherwise being patient does
ensure that data is passed from _any_ host that was last edited to
all the other authoritative servers.

Of course you should only edit the latest & greatest zone file.
This should be ensured by running nsd update and nsd-patch prior
to doing the edits.  And sanity checking your input would help
too, of course.


What I am left wondering is if SOA expiry would ruin this
scenario and retract the zone from publication.  Slaves store
their expiration timers in xfrd.state and there is no problem
if that file is removed while NSD is down.  To avoid having to
do that all the time, the setting "xfrdfile: /dev/null" might
be useful.  But actually, retrieving a copy from oneself may
do the trick just as well --it looks like an update and it
will therefore restart timers-- and that is better because it
becomes a per-zone setting.


If this works or could be made to work, it could simplify the
setup and crash recovery for authoritative name servers, by
making them all the same.  Even key management would mix in
beautifully, because it uses a symmetric scheme.  And NSD
appears so capable of this scenario that I wonder if it was
designed with this approach in mind?


To summerise my questions:

Q: Should we expect trouble (such as deadlocks or files being
   overwritten while they are read) if NSD does a request-xfr
   to oneself?

Q: Upon NOTIFY, will NSD retrieve the latest zone from _all_
   configured request-xfr hosts?  If not, I would argue that
   it is more consistent to try all sources and let the latest
   SOA serial number win.

Q: Is it correct that editing a zone is possible with a sequence
   nsd-update ; nsd-patch ; vi ; nsd-update?

Q: Upon NOTIFY or nsd-update, will NSD read the zone file, even
   if it has request-xfr setup for that zone?  Clearly, I would
   argue that an nsd-update should always be processed.

Q: Would the redirection of xfrd.state to /dev/null work?

Q: Would an xfer from oneself keep xfrd.state happy and thus
   avoid zone expiry on secondaries (which are also masters)?


It's a bit wild, I know.  But I don't think this is plain stupid.
Any opinions?


Thanks!
 -Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120127/5acb7ee9/attachment.bin>