Description of problem: Given a reasonable configuration of dnsmasq running on any non-isolated network (i.e. if using interface=<whatever>), dnsmasq fails to start. In at least some cases Version-Release number of selected component (if applicable): Not applicable (applies to Fedora package). How reproducible: Always given certain configurations. Steps to Reproduce: 1. Set up dnsmasq to be bound to a particular interface. 2. Reboot Actual results: dnsmasq failed to start due to being unable to find the specified interface. Expected results: dnsmasq should be running. Additional info: See also https://unix.stackexchange.com/questions/377381 which contains a possible fix for dnsmasq.service.
Consider using bind-dynamic for watching interfaces up and down. It should use even interfaces not yet ready, but which might be setup later. It is intentionally started before network-online.target in order to provide local caching required for connectivity. It might not be desired in other cases, but it cannot serve every situation in default configuration. So possibilities are two: - Use bind-dynamic: cat << EOF > /etc/dnsmasq.d/interface.conf interface=enp2s0 bind-dynamic EOF - Start dnsmasq once interface is available. $ systemctl edit dnsmasq [Unit] After=network-online.target Both should fix your problem. Btw. "rpm -q dnsmasq" command provides nice version to include in bug report. I think it is just configuration issue. Can you please confirm above fixes your issue? If it does, please close the bug as NOTABUG.
Ugh, apparently bugzilla search is awful (or broken?). Duplicate of #1502081. (And my configuration repository already has bind-dynamic, but it seems that somehow never made it to my live configuration.) *** This bug has been marked as a duplicate of bug 1502081 ***
I take that back... No, I can't use bind-dynamic; the shipped configuration using bind-interface makes it incompatible. Trying to use bind-dynamic gives a configuration error. ***As shipped***, it is impossible for dnsmasq to start if bound to a specific interface. I am skeptical of the implied assertion that the number of users with exotic setups where bringing up the network relies on dnsmasq being live exceeds the number of setups in which dnsmasq is bound to a specific interface. Use of bind-interfaces in the default configuration certainly implies that the latter is the expected case. Either don't use bind-interfaces in the shipped configuration, or fix the .service to start dnsmasq *after* the network is up. Or change the code so that bind-dynamic trumps bind-interface. (Or some combination thereof.) Yes, I am asserting this is a configuration issue, but with the *Fedora shipped* configuration, which is why I filed this against Fedora rawhide (the most recent / rawhide .service¹ still specifies the wrong systemd dependency), and also why I'm specifically filing it against *the Fedora package* and not dnsmasq itself. Fedora should not ship this in a configuration that is unusable by default. Using dnsmasq-2.85-1.fc34.x86_64. (¹ https://src.fedoraproject.org/rpms/dnsmasq/blob/rawhide/f/dnsmasq.service)
bind-interface and bind-dynamic are similar instructions but mutually exclusive. Just comment out bind-interfaces and use bind-dynamic. bind-interface is minimal requirement needed for default listening on just lo interface. lo usually does not go up and down during lifecycle of Fedora server or workstation. There is no need for it in localhost use. Localhost use is still useful and works by default as forwarding DNS cache. Because there is no simple way to determine public or private interface, it leaves such decision to administrator. It is okay, you are using dnsmasq Fedora package. But I think current default configuration makes sense for SOME uses, not all of them. bind-interfaces does not require dnsmasq to watch interfaces when it does care only about localhost. I think it is good for that case. I might add comment about bind-dynamic and interface=enp0s0, maybe also After=network-online.target to dnsmasq.service just to uncomment. I am sure they are good for default configuration as it is used. Fedora rule is to offer safe defaults for its services. That is why bind-interfaces and interface=lo is present. bind-dynamic would require additional resources without proper justification. If nameserver 127.0.0.1 is in resolv.conf, network-online.target might depend on working DNS resolution. That case needs configuration to stay current way. I admit example of proper configuration should be noted somewhere. I found out dnsmasq.service does miss nss-lookup.target.
> Just comment out bind-interfaces and use bind-dynamic. That's going to get nuked the next time the package updates, is it not? > If nameserver 127.0.0.1 is in resolv.conf [...] Is that even a functional configuration? I would actually *like* to use dnsmasq for local name resolution, but I've never gotten it to work. (Not if the upstream name server is assigned by DHCP, anyway.)
(In reply to Matthew Woehlke from comment #5) > > Just comment out bind-interfaces and use bind-dynamic. > > That's going to get nuked the next time the package updates, is it not? No, any custom changes of configuration is kept. New updates are stored as /etc/dnsmasq.conf.rpmnew if original file has local modifications. > > If nameserver 127.0.0.1 is in resolv.conf [...] > > Is that even a functional configuration? I would actually *like* to use > dnsmasq for local name resolution, but I've never gotten it to work. (Not if > the upstream name server is assigned by DHCP, anyway.) Why not? It has to work, just enable it after start. On Fedora 33 or later systemd-resolved is enabled by default. To use dnsmasq instead, it has to be disabled first: $ systemctl disable --now systemd-resolved Then edit NetworkManager to use dnsmasq for DNS. $ cat << EOF > /etc/NetworkManager/conf.d/50-dns.conf [main] dns=dnsmasq EOF $ rm /etc/resolv.conf $ systemctl restart NetworkManager $ systemctl status NetworkManager This way, it would start dnsmasq configured by Network Manager. A little confusing is NetworkNamespace.service is used to start it, because it has to enable dbus interface. Alternative would be to provide manually resolv.conf with first localhost address, then bunch of nameservers to forward to. Dnsmasq reads /etc/resolv.conf and would skip localhost address. $ systemctl disable --now systemd-resolved $ rm /etc/resolv.conf $ cat << EOF > /etc/resolv.conf nameserver 127.0.0.1 # Replace following with local DNS servers DHCP would offer to you. # nmcli nameserver 8.8.8.8 nameserver 1.1.1.1 EOF $ systemctl enable --now dnsmasq This should work both for your host or any on your lan, if firewall allows remote queries and public interface is enabled. That can be done by specification of interface=<int> or just commenting out interface=lo line in default configuration.
FEDORA-2021-6ca42042d1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6ca42042d1
FEDORA-2021-6ca42042d1 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6ca42042d1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6ca42042d1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-6ca42042d1 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.