[nsd-users] Multi-master mode NSD

Fri Jan 27 10:09:31 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
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?

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

> 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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPInfbAAoJEJ9vHC1+BF+N+V4QAIWIWG7abEFaydWgyujYQRWp
jEWjYh9S2O/emACAx1qISXOw1uEsau8EGnDWoA5kulwCdCG0Lyg9xbfrfRj+gqds
CMBdKHQNI/FTSDC3872bHHyG2CiR7J4eNf5O7LnvDp4J2G1FPA6UaVy7mPWyt+EM
isSFg1vbrcrhCB5JQJJsktYy8fWsCvM8qfV3Db7U44NYb7tsfPX2tts8I6GI+pEg
qbLvbygvlsslBV4X91bFbDLu2vbizv3jtnfDPlTzcUkcYHZ+FDeeav6RjcapbPMX
iboIs1Np3yhUA87LyyCjUBvUR6n1VQWcsSbdZ9rhsNB2vUNL57/gW8Ex87U/9Ta6
51VQPvw5h5ZE9uxX4wE18KfyEL7q84tHRwlhk8TH10YljQC0XhrvRC8k5yeNapzU
FxkPenD2mn5fb/OgNPdpizPZfmv4GsL2v+/diCZ0c/SphylK3bisl3crCiOLdriM
oVIzyX56wuHOA4RqlkCtL5EhGu5azF9j1PkOUFMcJYn1HZq/37VBMQqIo3zNxshA
EavY7Go9nmAXpsfeU97AQx6tKwY2ZG0sSIdH8McUonumVIp4HGeAHY8R1j4u2ovL
KphhE5pQ5La1c7SqCg/0IwUKkmpWg0kfUR+annvhvhHxF8JSz3Yf3/oDCYtkubN/
f94qiXRHZwaUKxcvp62n
=g14f
-----END PGP SIGNATURE-----