Petr Menšík wrote:
That might create a regression in special case. If you are running by default systemd-resolved, it listens already on domain port on address 127.0.0.53 address. But if bind-interfaces or bind-dynamic is not used explicitly, dnsmasq will try to listen on wildcard address 0.0.0.0 and just filter incoming requests, accepting only those arriving on interface eth0. But if any service already listens on port domain, it will fail to listen on it and fail to start.
But we run systemd-resolved by default these days, don't we? So making dnsmasq attempt by default to serve the same requests does not sound like a good idea to me.
On a server I administer for work, I have dnsmasq serving the DNS for an ocserv (OpenConnect) VPN, listening only on the VPN interface. Any request for a host not within the VPN network (coming in from clients with no or broken split DNS support, e.g., old GNU/Linux distros without systemd- resolved, or Windows, where the OpenConnect client is still unable to set up split DNS) is forwarded to systemd-resolved, which in turn forwards it to the upstream DNS from the datacenter. Relying instead on the filtering would not have worked exactly for the reason you describe above. But that server is not running Fedora anyway.
Kevin Kofler