Re: dnsmasq default configuration changed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please, Stephen, would you please read what I wrote, not what Kevin wrongly deducted?

The change I made in dnsmasq does not conflict with systemd-resolved in default configuration or if configured correctly. I have wrote scenario, when it can conflict and how to fix it. So no, there is no need to revert my change. If it is, *PLEASE* report it with exact step to reproduce. I have tested those changes do not cause regressions. If you (or anyone else) know something I have missed, I need much more precise steps than those below to fix it.

I would suggest everyone to try that change in rawhide actually, verify what is listening on and whether it does conflict with anything. I use "lsof -np $(pidof dnsmasq)" command for quick checks.

On 15. 01. 24 20:04, Stephen Gallagher wrote:
On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Petr Menšík wrote:
systemd-resolved is unfortunately known to broken.
[snip]
Dnsmasq does not break DNSSEC, systemd-resolved does.
[snip]
Unfortunately broken are clients having systemd-resolved enabled.
How exactly is it broken? If you refer to:
https://github.com/systemd/systemd/issues/25676
fixes for that are finally coming in now (as of 3 weeks ago).

I have reported issues known to me:

https://github.com/systemd/systemd/issues?q=is%3Aopen+is%3Aissue+author%3Apemensik+label%3Aresolve+

https://bugzilla.redhat.com/buglist.cgi?quicksearch=reporter%3Apemensik%40redhat.com%20component%3Asystemd&list_id=13235040

There are some others, which I consider important enough. If it works for you, good for you. It does not work well for others, I do not want to discuss it here. This thread is about dnsmasq only and I would like to focus to that only.


I would recommend having systemd-resolved forwarded to dnsmasq, which can
then be forwarded further.
If you think dnsmasq should replace systemd-resolved by default, then please
propose that through the Changes process, which will also ensure the glibc
resolver, NetworkManager, and the like get configured properly for it.
Simply shipping dnsmasq with a default configuration that conflicts with
systemd-resolved is not a productive approach.

If systemd-resolved is really broken, then it either needs to be fixed or
replaced. The former needs to be handled through systemd upstream, the
latter through the Fedora Changes process.
Yes, I plan to propose changes to default system wide resolver, because long reported bugs to systemd-resolved were mostly ignored. For years. But the solution I want to propose is not replacing it with dnsmasq. I am dnsmasq maintainer, I know it has own issues. In my opinion it is less broken, but not perfect. We are preparing different solution, which should be better. But it is not yet ready and therefore there is no Fedora Change filled. We fill create that once we are sure it brings features without causing regressions.

But this change should create conflict with systemd-resolved only in case
it was improperly configured.
But the default configuration you ship will conflict.

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.
You just wrote that you make it listen by default on all interfaces, and
then filter. This means it will conflict over the port 53. That said,
listening on the lo interface only will also conflict with systemd-resolved
or any other local resolver, so you are probably right that your change does
not change much for the default configuration, it just makes it harder (more
settings to change) to set up coexistence. 127.0.0.53 is unfortunately not
an independent interface, it is still the lo interface.

Based on my reading of this thread, this change is going to break the
default configuration and needs to be reverted immediately. Petr,
please file a Change Proposal for Fedora *41*. You have missed the
deadline for F40 System-Wide Changes (Dec. 26th) and this is
absolutely NOT a self-contained Change.

I am sorry my intention were not understood correctly. Miroslav already mentioned that. We will fill System-Wide Change, but this change does not need it. If it breaks something, please use bug #2258062 to report details or create a new one for rawhide. But reproducible details are needed, not just assumptions.

Cheers,

Petr

PS: I consider it rude to be commented on issue closed for discussion, especially if the comment is misleading and false.

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux