Starting just a few days before the day the machine running dnsmasq in
my SOHO died, I was giving some thought to how I'd go about ensuring
a backup copy of dnsmasq could take over if my only running instance
died. Needless to say, the death of the machine left my small network in
shambles, because I couldn't connect to anything to fix things without
first configuring temporary static addresses; sans DHCP, stuff fails... :)

I'm anything but a DHCP specialist, but I want to bounce this idea off
you anyway, even if you mind. ;-)

The trick, as I understand it, in setting up more than a single dnsmasq
instance in a network, is to ensure that it uses --dhcp-script to STORE
the leases and --leasefile-ro to force the script to produce a list of
current leases ("init") from which a launching dnsmasq obtains its data
before going on its usual business.

If we were able to ensure the "data store" (i.e. lease database) were
available on two machines A and B (and up to date on both of course) the
solution would be easy, except for the fact that dnsmasq does not LOOKUP
(i.e. query) for a lease in the data store except upon startup.

I'm thinking along the lines of having a function lease_query() in
lease.c which dnsmasq invokes to determine whether a lease exists before
issuing a new lease for a device.

Being very lightweight, dnsmasq must not be bloated by having a huge
MySQL or other database attached to it. I've been searching the
Internets and finally landed upon Tokyo Tryant [1] which I've discussed a
long time ago [2].

What I'm basically getting at is providing dnsmasq with an optional very
lightweight replicating server which it (optionally) uses to ensure the
lease database can be propagated to a second (or third or fourth)
dnsmasq instance. The reason I'm suggesting Tryant is that, it too, is
lightweight and offers multi-master setups.

     +------------+                       +-------------+
     |   dnsmasq  |                       |  dnsmasq    |
     |     A      |                       |     B       |
     +-----+------+                       +-------------+
           |                                     +
           |                                     |
           |                                     |
     +-----v-------+                      +------v-------+
     |   Tryant    |                      |   Tryant     |
     |     A       |+--------------------->     B        |
     |             |<---------------------+              |
     +-------------+                      +--------------+

     +-------------+                      +---------------+
     |   leases    |                      |    leases     |
     |-------------|                      |---------------|
     +-------------+                      +---------------+

In other words, dnsmasq (A) reads/writes leases from Tryant (A) and
dnsmasq (B) read/writes from/to Tryant (B). If Tryant (A) and (B) can
speak to eachother, the database is replicated, irrespective of which
dnsmasq (A) or (B) has last written a lease.

I'll stop here, before boring you even more, but I'll gladly send you
snippets of code and a short "howto" set up a multi-master system. Most
important IMO is to keep things very light-weight in the spirit of
dnsmasq.

Best regards,

        -JP

[1] http://fallabs.com/tokyocabinet/tokyoproducts.pdf
[2] http://jpmens.net/2009/09/06/tokyocabinet-a-wow-replacement-for-dbm/

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to