[Dnsmasq-discuss] dyndns-style addition of names

richardvoigt at gmail.com richardvoigt at gmail.com
Fri Apr 13 06:10:36 BST 2007

On 4/10/07, Simon Kelley <simon at thekelleys.org.uk> wrote:
> richardvoigt at gmail.com wrote:
> >
> > Instead of adding code to persist the configuration, why not use the
> > existing external script capability, and provide an example script?
> >
> > Then a dbus method to cause dnsmasq to re-run its external script to
> > learn any reservations, as it does during startup.
> This facility already exists, in a slightly different form: sending
> SIGHUP will make dnsmasq re-read /etc/ethers, which contains DHCP
> address reservations.
> Getting this information via the external script is problematic for a
> few reasons: the current information returned is existing DHCP leases,
> which is not the same as DHCP address reservations. Extending the

If you return a lease with a far future expiration, would that not
effectively reserve the address?  Would dnsmasq report that long
timeout to the client next time it renews, or use the configured lease
time?  I guess that then when the renewal expired, before the
expiration reported by the script, the lease could be reassigned, so
that's no good.

It would be extremely useful to be able to report address reservations
via the external script.  The script accepts a parameter indicating
startup vs. new lease vs. lease expiration, right?  Then a new command
could be added for enumerating reservations, which should be ignored
by existing scripts and hence backward compatible.

Seems like that is necessary for managing reservations in an external
database (well, you could update /etc/ethers from a trigger procedure
I suppose).

Does SIGHUP also re-read /etc/ethers?  I don't see that mentioned in
the man page, but I skimmed it rather quickly.  Just that /etc/ethers
is treated as if it were commands in the config file, and the config
file isn't reread.  I guess there would be trouble with reservations
accumulating each time /etc/ethers was read, but not being able to
remove unlisted ones due to the fact that they could have been taken
from the config file (store a flag indicating the source of the
reservation?  config file vs /etc/ethers?)

More information about the Dnsmasq-discuss mailing list