systemd-resolved is unfortunately known to broken. I would recommend having systemd-resolved forwarded to dnsmasq, which can then be forwarded further.
Dnsmasq does not break DNSSEC, systemd-resolved does. But this
change should create conflict with systemd-resolved only in case
it was improperly configured. In all other cases, it should work
independently on the same machine just fine.
Anyway, dnsmasq will listen by default on 127.0.0.1, as every
standard resolver does. You can use listen-address=127.0.0.53 if
you like, but then it will conflict with systemd-resolved.
No, dnsmasq will serve addresses 127.0.0.1 and ::1. If you do not want it listening on wildcard address, please configure it explicitly by using bind-interfaces or bind-dynamic options. Otherwise make sure no other program listens on port 53 (domain), be it systemd-resolved, named, unbound or anything similar.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
--
Unfortunately broken are clients having systemd-resolved enabled.
I would recommend to skip systemd-resolved stub and using resolv-file=/run/systemd/resolve/resolv.conf
in such case. It would use servers configured by systemd-resolved, but without using broken port domain at address 127.0.0.53. Alternatively use server=127.0.0.54, which should not break incoming queries so much.
Consider using unbound as a cache for other VPN clients. dnsmasq is great for its integration with DHCP server, but is targeted to use minimal resources. Unfortunately at cost of some design issues. Unbound is a high quality cache, while still relatively small compared to bind's named.service.
Cheers, Petr
-- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ 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
