[nsd-users] Multi-master mode NSD

W.C.A. Wijngaards wouter at nlnetlabs.nl
Fri Jan 27 10:09:31 UTC 2012

Hash: SHA1

Hi Rick,

Incomplete answers, below.

On 01/27/2012 10:42 AM, Rick van Rein wrote:
> 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?

Yes more complicated mesh of zone transfers is designed for.  But that
does not necessarily make such complication a good idea.

> 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?

No, it should work.

> 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.

If the NOTIFY did not contain a soa serial: first try the master that
sent the notify, then subsequent masters, until the first one that has
a 'newer' serial number.  Transfer it, end of algorithm.

If the NOTIFY did contain a soa serial: first try the master that sent
the notify, then subsequent masters, pick up improved soa serials and
transfer those zones, until you manage to fetch the serial number (or
better) from the notify.  This could result in multiple zone
transfers, and probing many masters.

> 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.

nsd-update?  NSD-3 does not read the zonefile, unless you run zonec
(nsdc rebuild).  NSD-4 can read the zonefile (and precompile that file
by itself), when you tell it to, with nsd-control read-this-zone, or
with SIGHUP (checks ftimes).  NSD3 and NSD4 will send a NOTIFY to
slaves if a zone is updated from file and it has notify: actions

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

Not sure about reading from it... Could take a very very long time or
give parse errors.

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

Yes, probably.  This is also considered a problem with loops in the
zone-transfer-graph.  There exists a draft in the IETF to fix
non-expiry with transfer-loops (with an EDNS option I believe).

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

So, the design explicitly intends to work with mixed actions;
request-xfr and also provide-xfr, and so on, this is useful for
'intermediate' or 'distribution masters'.  Making loops in the
master-slave topology can spell trouble, I have no experience with this.

Best regards,
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the nsd-users mailing list