Hi All,
Fedora 39
I am running a caching named server (named-chroot). It is listening on 127.0.0.1. The WAN IP address comes from the DHCP on my DSL modem.
Problem: the accursed systemd-resolved changes /etc/resolv.conf
from nameserver 127.0.0.1 search .
to nameserver 127.0.0.53 options edns0 trust-ad search .
Meaning no DNS resolution until I vi resolv.conf every time I boot up, which is what my web searches tell me to do.
<editorial comment> AAAAAAAHHHHHH!!!!!! </editorial comment>
How do I tell systemd-resolved to stop this annoying behavior.
-T
"options edns0 trust-ad" seems like a good thing
.
On 10/27/24 15:23, ToddAndMargo via users wrote:
Hi All,
Fedora 39
I am running a caching named server (named-chroot). It is listening on 127.0.0.1. The WAN IP address comes from the DHCP on my DSL modem.
Problem: the accursed systemd-resolved changes /etc/resolv.conf
from nameserver 127.0.0.1 search .
to nameserver 127.0.0.53 options edns0 trust-ad search .
Meaning no DNS resolution until I vi resolv.conf every time I boot up, which is what my web searches tell me to do.
<editorial comment> AAAAAAAHHHHHH!!!!!! </editorial comment>
How do I tell systemd-resolved to stop this annoying behavior.
-T
"options edns0 trust-ad" seems like a good thing
.
Figured it out.
My web search show this being a complete pain-in-the-neck (not my actual words) for a lot of folks.
And to add insult to injury, systemd-resolved is required for various other packages to upgrade.
Thank you all for all the help and tips so far cleaning up my install.
-T
This is my work around which survives a reboot:
<resolv.conf.127.0.0.53.problem.txt>
resolv.conf: 127.0.0.53 issue
reference: https://www.youtube.com/watch?v=zzFbFEOgtY0
1) stop systemd-resolved # systemctl stop systemd-resolved.service
2) make sure it is stopped with # systemctl stop systemd-resolved.service
3) create your own seed resolv.conf file. Note that the _xx is arbitrary. You just have to remember what you called it.
# vi /etc/resolv.conf_rn namespace 127.0.0.1
4) erase or rename resolv.conf # rm /etc/resolv.conf
5) create a symbolic link to your seed # ln -s /etc/resolv.conf_rn /etc/resolv.conf
6) start systemd-resolved # systemctl start systemd-resolved.service
7) check resolv.conf # cat /etc/resolv.conf
</resolv.conf.127.0.0.53.problem.txt>
ToddAndMargo composed on 2024-10-27 19:35 (UTC-0700):
Figured it out.
My web search show this being a complete pain-in-the-neck (not my actual words) for a lot of folks.
And to add insult to injury, systemd-resolved is required for various other packages to upgrade.
Just because other packages require its installation doesn't mean you must allow to be used. All my installations have systemd-resolvd.service disabled and masked, and I have an old-fashioned genuine plain text file /etc/resolv.conf. :)
On 10/27/24 19:59, Felix Miata wrote:
ToddAndMargo composed on 2024-10-27 19:35 (UTC-0700):
Figured it out.
My web search show this being a complete pain-in-the-neck (not my actual words) for a lot of folks.
And to add insult to injury, systemd-resolved is required for various other packages to upgrade.
Just because other packages require its installation doesn't mean you must allow to be used. All my installations have systemd-resolvd.service disabled and masked, and I have an old-fashioned genuine plain text file /etc/resolv.conf. :)
I had done something similar to that. Unfortunately, upgrade releases turn the buzzard back on.
ToddAndMargo composed on 2024-10-27 21:51 (UTC-0700):
On 10/27/24 19:59, Felix Miata wrote:
Just because other packages require its installation doesn't mean you must allow to be used. All my installations have systemd-resolvd.service disabled and masked, and I have an old-fashioned genuine plain text file /etc/resolv.conf. :)
I had done something similar to that. Unfortunately, upgrade releases turn the buzzard back on.
WRT masked, there is no "something similar". Simply disabling isn't enough to prevent an upgrade from reverting to package default. Disabling the service must be followed by masking the service.
There's always the option of creating a real /etc/resolv.conf and making it immutable.
Hi.
On Mon, 28 Oct 2024 01:04:39 -0400 Felix Miata wrote:
ToddAndMargo composed on 2024-10-27 21:51 (UTC-0700):
On 10/27/24 19:59, Felix Miata wrote:
Just because other packages require its installation doesn't mean you must allow to be used. All my installations have systemd-resolvd.service disabled and masked, and I have an old-fashioned genuine plain text file /etc/resolv.conf. :)
I had done something similar to that. Unfortunately, upgrade releases turn the buzzard back on.
WRT masked, there is no "something similar". Simply disabling isn't enough to prevent an upgrade from reverting to package default. Disabling the service must be followed by masking the service.
Yes, but it is safer to also declare the preset disabled, as follow (for example):
--------- /usr/lib/systemd/system-preset/50-disable.preset --------- disable systemd-resolved.service --------------------------------------------------------------------
The various scriptlets of the systemd-resolved RPM will then not enable it, even if something unmask the service.
Note also that the posttrans scriptlet of the systemd-resolved RPM may recreate the resolv.conf link if the systemd-resolved preset is enabled (and not masked).
-
Felix Miata -
Francis.Montagnac＠inria.fr -
ToddAndMargo