[Dnsmasq-discuss] dnsmasq integration
simon at thekelleys.org.uk
Wed Jan 17 10:29:28 GMT 2007
richardvoigt at gmail.com wrote:
> I'm looking to run dnsmasq on a transparent packet filter, and I'd
> like to know how to do a couple things not directly described in the
> manual page. I'm willing to modify the code myself if these features
> currently aren't available, so I'd appreciate either pointers toward
> existing options or else directions to where in the code such a
> feature would be implemented.
> (1) DHCP reservations from external database. Can the "--dhcp-script"
> program supply these? Would it be only at startup, or it is possible
> to do after each request? If only at startup, can I send the dnsmasq
> process a signal to cause it to re-request the database?
This has been done before by putting the MAC<->IP mapping in /etc/ethers
and telling dnsmasq to read it using --read-ethers. SIGHUP will cause
dnsmasq to re-read /etc/ethers if required. If that isn't sufficient
then the best thing would be to extend the (under-used) dbus facility to
add a method to do this.
> (2) Managing the kernel ARP table to prevent IP spoofing. I'd like
> static entries added to the ARP table for each active DHCP lease. I
> suppose this would also be possible via "--dhcp-script" program. I
> intend to have ebtables filter traffic against these mappings as well
> (after permitting dhcp requests of course).
I can't see any problems doing that.
> (3) Possibility to immediately expire a lease, if say a MAC address
> gets shifted to static addressing, the next DHCP renew should receive
> the reserved address.
Comes as standard.
> (4) At some point I'll want a high-availability solution using
> heartbeat. I assume as long as the lease database is stored
> externally, then the standby server can start its instance of dnsmasq
> after the first fails, which combined with the --leasefile-ro option
> would cause the entire lease table to be migrated. Being unavailable
> for a few minutes wouldn't be a problem as long as recovery is
> automatic. Even giving different pools to each server is a definite
You might not need an external database maintained by the dhcp-script
mechanism. If you can arrange a suitably available filesystem,
accessible to both servers, you can keep the leasefile there. The
leasefile is written after any change, so there's little chance of
losing changes (and the design of DHCP makes losing the odd
lease-database update a non-event anyway.)
> Thanks for any guidance you can offer. I'm supposing that dnsmasq has
> no trouble managing several hundred simultaneous leases.
I'm running >500 leases on one installation without any problems.
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
More information about the Dnsmasq-discuss