Hi there,
I have an oddball situation that I'm happy to work around in the short
term, but it is sufficiently flummoxing that it'd be nice to see it fixed
in a future version of dnsmasq. (Or I am simply missing something and y'all
can enlighten me.)
I have a single interface, e.g. eth0, with two addresses assigned to it:
192.168.0.1/24 and 192.168.0.20/24. The .1 is the primary address; the .20
is a VIP that floats around. This system uses iproute2 (i.e. `ip`) instead
of net-tools (i.e. `ifconfig`), and the interface is configured on boot by
systemd-networkd (via everyone's favorite netplan). Here's (roughly) what
the eth0.network file looks like:
[Match]
Name=eth0
[Network]
Address=192.168.0.1/24
Address=192.168.0.20/24
DNS=127.0.0.1
I am explaining this the long way to make it super clear that there exists
only a single eth0 interface with two addresses; there is no separate
eth0:<n> interface for the .20 address. This is an important distinction
because of how dnsmasq sets up its listening interfaces and addresses per
my understanding. Here's (roughly) how it looks on a live system:
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether dc:a6:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.0.20/24 brd 192.168.0.255 scope global secondary eth0
valid_lft forever preferred_lft forever
$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode
DEFAULT group default qlen 1000
link/ether dc:a6:de:ad:be:ef brd ff:ff:ff:ff:ff:ff
$ ip link show eth0:0
RTNETLINK answers: No such device
Cannot send link get request: No such device
$ ip link show eth0:1
RTNETLINK answers: No such device
Cannot send link get request: No such device
Here's my starting dnsmasq (2.79) configuration and then I'll actually
(finally!) explain what I'm trying to do:
bind-dynamic # needed for lxd
listen-address=127.0.0.1
listen-address=192.168.0.20
listen-address=192.168.0.1
no-dhcp-interface=lo
# DNS
no-resolv
server=1.1.1.1
server=1.0.0.1
bogus-priv
domain-needed
localise-queries
stop-dns-rebind
## performance
all-servers
cache-size=600
dns-forward-max=300
query-port=0
# DHCP
dhcp-authoritative
expand-hosts
read-ethers
## eth0
domain=powphoto.net,192.168.0.0/24
dhcp-range=tag:eth0,192.168.0.100,192.168.0.200,12h
dhcp-option=tag:eth0,option:router,192.168.0.1
dhcp-option=tag:eth0,option:dns-server,192.168.0.1,192.168.0.2
dhcp-option=tag:eth0,option:ntp-server,192.168.0.20
My ultimate goal is to have a single instance of dnsmasq (A) listening for
DNS queries on .1 and (B) listening for DHCP discovery and request messages
on .20 *and* using .20 as the server address (i.e. the SIADDR field in the
header and option 54 in the payload) for offer and acknowledgement
messages. *If* this system used net-tools *and* there existed a separate
eth0:0 interface for the .20 address, it would be a one-line configuration
change:
no-dhcp-interface=eth0
Unfortunately, with iproute2, this statement disables DHCP on both
addresses. And it seems as though this is the only configuration statement
available within dnsmasq to disable DHCP on a given interface or
listen-address. I've tried various solutions with no luck, such as:
1. no-dhcp-interface=192.168.0.1
*=> same result as `=eth0`*
2. only allowing DHCP to/from 192.168.0.20 via iptables
*=> dnsmasq seems to prefer this address if both are specified (and
won't even listen for DHCP discovery messages on the .20?)*
3. dhcp-relay=192.168.0.1,192.168.0.20
*=> this off-label use definitely did not work as intended*
It looks like iproute2 has the ability to label or alias an address, but
it's not clear whether this would play nice with dnsmasq's existing
interface alias logic. It doesn't seem to be supported in systemd-networkd
or netplan anyway.
As I said in my opening note, I have several workarounds that I'm tinkering
with, so this definitely isn't a show-stopper. Just thinking aloud, I
suppose what I'd really like is a more granular and/or flexible solution
for mapping service listeners to addresses/interfaces and vice-versa. Or at
least a way to say no-dhcp-listen-address!
Thank you,
Mike
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
