Bug 2258062 - dnsmasq: use local-service=host to configure initial secure configuration [fedora-all]
Summary: dnsmasq: use local-service=host to configure initial secure configuration [fe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnsmasq
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1852373
Blocks: CVE-2020-14312
TreeView+ depends on / blocked
 
Reported: 2024-01-12 13:40 UTC by Petr Menšík
Modified: 2024-01-30 04:21 UTC (History)
12 users (show)

Fixed In Version: dnsmasq-2.89-7.fc40 dnsmasq-2.89-7.fc39
Doc Type: No Doc Update
Doc Text:
Clone Of: 1852373
Environment:
Last Closed: 2024-01-30 04:21:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Fedora Package Sources dnsmasq pull-request 15 0 None None None 2024-01-13 00:56:07 UTC
Red Hat Issue Tracker RHEL-9516 0 None None None 2024-01-12 16:11:48 UTC

Description Petr Menšík 2024-01-12 13:40:12 UTC
+++ This bug was initially created as a clone of Bug #1852373 +++

Change the original solution with explicit specification of bind-interfaces and interface=lo options.

Backport of newly added option would allow again to just specify a new snippet in /etc/dnsmasq.d/interface.conf for example, without first commenting or replacing options in /etc/dnsmasq.conf.

Of course if someone relied for bind-interfaces and interface=lo present already, it might break such deployments after update.

Comment 1 Petr Menšík 2024-01-12 16:11:49 UTC
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

Comment 2 Petr Menšík 2024-01-12 16:36:35 UTC
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

Comment 3 Petr Menšík 2024-01-13 00:56:07 UTC
Built this change into Rawhide. Would like to push it also into Fedora 39, unless some issues arise.

Comment 4 Petr Menšík 2024-01-17 12:57:42 UTC
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/

Comment 5 Fedora Update System 2024-01-24 00:07:26 UTC
FEDORA-2024-b359bbdf87 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b359bbdf87

Comment 6 Fedora Update System 2024-01-24 01:39:10 UTC
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.

Comment 7 Fedora Update System 2024-01-30 04:21:54 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.