[Dnsmasq-discuss] Details of the --dhcp-optsdir=<path> option

Chris Green cl at isbd.net
Sat Sep 4 08:31:32 UTC 2021


On Fri, Sep 03, 2021 at 02:32:06PM -0700, Michael wrote:
> 
> > So the normal 'everything working' situation will be system A (say on
> > 192.168.1.2) is a DNS and DHCP server.  System B (say on 192.168.1.3)
> > provides only DNS.  System A's DHCP server will give out both
> > 192.168.1.2 and 192.168.1.3 as DNS servers.
> > 
> > If 192.168.1.3 fails or is off line everything continues to work OK
> > except maybe some slowing down of DNS because of requests to
> > 192.168.1.3 having to timeout before retrying on 192.168.1.2.
> > 
> > If 192.168.1.2 fails I will add the DHCP configuration to it
> > 'manually' and then I'll have a working system while I fix
> > 192.168.1.2.
> > 
> 
> I think it is important to understand the DNS doesn't really have the
> concept of primary and secondary nameservers.    They are all expected to be
> equal and the client can choose which one it wants to try.   So, your
> servers have to have the ability to give the same responses or you will go
> crazy trying to figure out why somethings aren't working right.
> 
Yes, that's why I intend to have both DNS servers running when things
are 'normal'.  Both should respond pretty quickly so it shouldn't
matter which gets asked first.
> 
> In your scenario, you could sync the leases file over regularly as a
> backup.   Then when the failure occurs, you would update the secondary box
> to add the dhcp options, stop the redirection above, and begin
> owning/managing the DHCP leases file.   When the primary comes back online,
> you have to reverse the whole process or leave it this way until the next
> failure, but sync the files the other way.
> 
Ah, I think I can see the issue you're trying to point me to.

If a client X gets its IP etc. from server A then server B won't have
its details and if another client Y makes a DNS request for the name of
the client X then server B won't know it.

If I copy the leases file back and forth regularly will server B know
client X's IP?

Maybe it would actually be better to run only one dnsmasq and just
keep its configuration and lease files in sync with the other
installation.  If server A fails then just start up dnsmasq on server
B.  This is simpler as both dnsmasq configurations can be identical,
the only issue is that I need to change server B's IP address to that
of server A.  It might actually be easier/quicker to add the second IP
in promiscuous mode (or run dnsmasq in a docker container in macvlan
mode, but this adds a whole layer of complexity, especially as the
servers will probably be different hardware).

-- 
Chris Green



More information about the Dnsmasq-discuss mailing list