Bug 2258062

This proposal were sent to upstream: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q4/017352.html
And it was acknowledged to be likely merged: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q4/017357.html

It is not yet merged, but I would like to have it tested a bit already, because it seems it would be merged anyway.

Related issues:
- https://issues.redhat.com/browse/RHEL-6517
- https://issues.redhat.com/browse/RHEL-9516

This change will change effective default configuration from:

# grep -v '^[[:space:]]*\(#.*\)\?$' dnsmasq.conf.example 
user=dnsmasq
group=dnsmasq
interface=lo
bind-interfaces
conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

to:

# grep -v '^[[:space:]]*\(#.*\)\?$' dnsmasq.conf.example 
user=dnsmasq
group=dnsmasq
local-service=host
conf-dir=/etc/dnsmasq.d,.rpmnew,.rpmsave,.rpmorig

Built this change into Rawhide. Would like to push it also into Fedora 39, unless some issues arise.

Given some confusion announcement on devel list [1] caused, let me explain when conflict with default services.

1) if default configuration is not changed, dnsmasq will listen on 127.0.0.1 and ::1 before and also after this change. It does *not* conflict with systemd-resolved enabled in Fedora by default.

2) if configuration is changed properly, it will on interface or addresses specified. Because systemd-resolved listens on address not configured explicitly on interface address, it will not conflict either.
# /etc/dnsmasq.d/iface.conf
interface=lo
bind-interfaces

You can obtain listening addresses by command: sudo ss -lnp sport = :domain

3) if configuration uses bind-dynamic, it will work fine as well. Useful when interface is using DHCP and is not prepared immediately when starting.
# /etc/dnsmasq.d/iface.conf
bind-dynamic
interface=eth0


4) if configuration is changed only partially, conflict might arise. without explicitly used bind-interfaces or bind-dynamic option in configuration or in command-line, dnsmasq will listen on address 0.0.0.0 and ::. It then tries to drop requests not allowed by interface option, if they are specified.
# /etc/dnsmasq.d/iface.conf
interface=lo

In this case dnsmasq will conflict with systemd-resolved listening on address 127.0.0.53. One of them will fail to start this way, but behaves exactly according to configuration provided. It would conflict also with alternative dnsmasq instances used by libvirt networks, or any other program listening on port 53 on any address. If this is not what you want, please modify your configuration to use 1), 2) or 3) variant.

Very similar result will happen if just local-service=host is commented out in /etc/dnsmasq.conf, but no interface or listen-address is specified to limit served networks. This will make your dnsmasq open resolver, which can be misused by anyone having access to it for attacks against other recursive service. It is possible to restrict access just by firewall and it should be enabled by default on Fedora, but configuring dnsmasq more explicitly is considered better alternative.

Running dnsmasq without any interface=<name> or listen-address=<address> options is *not* recommended.

1. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2ZPFK3JNU5XW6E7OCOA4CUGQETRNRRMU/

FEDORA-2024-b359bbdf87 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b359bbdf87

FEDORA-2024-b359bbdf87 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-b359bbdf87`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-b359bbdf87

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-b359bbdf87 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.