[Dnsmasq-discuss] Answer DHCP requests when dnsmasq is not bound to the 1st IP of an interface
Simon Kelley
simon at thekelleys.org.uk
Sat Nov 26 17:22:49 GMT 2011
On 23/11/11 23:53, dnsmasq.20.masuefke at spamgourmet.com wrote:
> Hello,
>
>> This stuff doesn't just affect access control, it affects address
>> allocation and things like the default gateway supplied to DHCP clients.
> That's a field I have not yet dug into. Why is the server's address
> important in this regard ? Does the --dhcp-range depend on the server IP
> that answers the request ?
For local interfaces, it doesn't really matter at all: the local address
of the interface which is in the same subnet as the IP address of the
DHCP lease is used. Where it does matter is for clients which send DHCP
requests to dnsmasq via a DHCP relay. In that case the "DHCP server-id"
and possibly the address of the DNS server sent (unless that's
overridden) will be the primary address of the interface. That's OK
unless that address isn't routable: then the DHCP client won't be able
to talk to the server to renew an address.
> As far as the DHCP optons are concerned, e.g. default gateway, ntp
> server, i don't think it is much importatant.
> These options can be set with --dhcp-option if needed. Considering the
> complexety of a network that uses multiple IPs on a single interface
> (some simple firewall configuration scripts/helpers will choke on
> this!), an administrator can be expected to configure these options by hand.
> As far as the selection of the broadcast address option goes, that is
> locked with the used subnet, the --dhcp-range and thus also a fixed thing.
>
> I should have elaborated on my network config some more.
> My DHCP servers IPs are like 192.168.0.10/24 and 192.168.0.11/24 , so
> the broadcast 192.168.0.255 and the gateway 192.168.0.1 is the same for
> all DHCP replies, no matter which IP the requests had been received on.
> For running two entirely differnet networks like a 192.168.10.0/24 and
> 192.168.20.0/24 I'd recomend running two instances of dnsmasq on the
> respective DHCP server IP address. Managing the "battle for the clients"
> between the servers will be another issue, then (think of using --dhcp-mac)
>
>> -Maybe there should be explicit configuration?
>> --dhcp-interface-address = <interface name>, <IP address>
> Befeore you spent time on that, I'd rather request an option to have an
> interface with DHCP service but no DNS service; but with other
> interfaces with both DHCP and DNS (on their default ports!) .
> Short: Something like --no-dhcp-interface= but for DNS, maybe
> "--no-dns-interface=" ?
> That option would have solved all the troubles I went through with the
> two interfaces. dnsmasq would only provide dhcp, leaving the other dns
> resolver alone on that interface, and being able to query the DHCP
> clients host names via DNS on another interface (e.g. lo)
It would make sense to do that. In the meantime, I re-implemented your
patch to fit in a bit better with the existing code and tidy up some of
the network access code. In most cases, it will still use the primary
address for the server-id in the case I talked about above, but if there
is a --listen-address for a secondary address, and _no_ listen address
for the primary address, it will used the secondary address. I think
that should avoid surprises in most cases.
http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.60.tar.gz
I'd be grateful if you could test it and see if it works as expected.
Cheers,
Simon.
More information about the Dnsmasq-discuss
mailing list