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
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
