Bug 1910969 - Failure to connect to Internet after upgrading to version 2.0.44 on Fedora 32 !!
Summary: Failure to connect to Internet after upgrading to version 2.0.44 on Fedora 32 !!
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnscrypt-proxy
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Robert-André Mauchin 🐧
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-26 14:49 UTC by yousifjkadom@yahoo.com
Modified: 2021-05-25 17:03 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-25 17:03:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
listen-addresses (54.68 KB, image/png)
2020-12-28 19:36 UTC, yousifjkadom@yahoo.com
no flags Details
dns=none (52.71 KB, image/png)
2020-12-28 19:37 UTC, yousifjkadom@yahoo.com
no flags Details

Description yousifjkadom@yahoo.com 2020-12-26 14:49:05 UTC
Hi.

Kindly, look the following issue that I'm already created on upstream developer repository about this issue yesterday:

https://github.com/DNSCrypt/dnscrypt-proxy/issues/1556

Any further information I'm ready to supply you if you want.

Best.

Comment 1 yousifjkadom@yahoo.com 2020-12-27 12:42:29 UTC
Hi again. Do you follow the discussion on GitHub on link that I gave you ?
They instruct me to run:
sudo dnscrypt-proxy -service install

I run it & it installed the service. Then I run:
sudo dnscrypt-proxy -service start
then changed the "Method" in my network manager GUI into "Automatic (DHCP) addresses only" & thence power OFF my system, waiting 3 minutes, & finally power it ON. But Internet did not connect at all, as if I did not do any change !! 

I was re-enforced to change "Method" again into "Automatic (DHCP)" & reboot my system again to be able to connect to Internet !

I run: "systemctl status dnscrypt-proxy" & it gave me the following:

nscrypt-proxy.service - Encrypted/authenticated DNS proxy
     Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled)
     Active: activating (auto-restart) (Result: exit-code) since Sat 2020-12-26 19:25:22 GMT; 14s ago
    Process: 3368 ExecStart=/usr/bin/dnscrypt-proxy -config dnscrypt-proxy.toml (code=exited, status=255/EXCEPTION)
   Main PID: 3368 **(code=exited, status=255/EXCEPTION)**
        CPU: 9ms

then I tried "sudo dnscrypt-proxy -service restart" but still not working !

Note: the listen address is already set at = ['127.0.0.1:53'] & I have no IPv6 at all in my country.

I'm asked by @remyabel to make the following changes in my /etc/resolv.conf
nameserver ::1
nameserver 127.0.0.1
options edns0 single-request-reopen

But in my /etc/resolv.conf the following currently existing:
# Generated by NetworkManager
nameserver xxx.xxx.xxx.x
nameserver 127.0.0.1

I used xxx because I do not know if the 1st address of private data that should not demonstrated to public or not.

Does really I need to change 1st name server into ::1 or not ? I have no IPv6. Also, I'm not expert with such changes in such system files .....

Is this a bug or just need a new configuration ?

Comment 2 Bryce Torcello 2020-12-28 02:45:46 UTC
The upgrade from dnscrypt-proxy-2.0.44-1.fc32 to dnscrypt-proxy-2.0.44-5.fc32 didn't work for me too. I was initially getting the same error as yousifjkadom, but I was unable to get the same error again after a period of troubleshooting. 

However I did observe that the upgrade from 2.0.44-1 to 2.0.44-5 still fails when starting from scratch with 2.0.44-1.

I am able to fix this by simply uninstalling dnscrypt-proxy and installing 2.0.44-5.

For your reference yousifjkadom, to stop NetworkManager editing /etc/resolv.conf you need to edit /etc/NetworkManager/NetworkManager.conf and add the line dns=none under the [main] section. Then you can change your /etc/resolv.conf, which I have mine as:

nameserver 127.0.0.1
options edns0

Comment 3 Robert-André Mauchin 🐧 2020-12-28 08:48:55 UTC
Ok that's my fault I've tried to remove the service file to follow upstrream official method but I didn't know it wouldn't overwrite the existing service file.

Comment 4 Robert-André Mauchin 🐧 2020-12-28 10:56:05 UTC
I've pushed an updated version that should solves the service file problem.

However, you should still check your configuration:

 - Create a new /etc/resolv.conf file with the following content:

nameserver 127.0.0.1
options edns0

and disable editing with sudo chattr +i /etc/resolv.conf. You shouldn't change anything in the NetworkManager GUI.

 - Edit /etc/dnscrypt-proxy/dnscrypt-proxy.toml and make sure listen_addresses is set as the following:

listen_addresses = ['127.0.0.1:53']

Comment 5 Robert-André Mauchin 🐧 2020-12-28 19:09:39 UTC
> $ systemctl status dnscrypt-proxy
> I'm getting the following output:
> 
> ```
> ● dnscrypt-proxy.service - Encrypted/authenticated DNS proxy
>      Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled)
>      Active: active (running) since Mon 2020-12-28 18:29:20 GMT; 8min ago
>    Main PID: 774 (dnscrypt-proxy)
>       Tasks: 10 (limit: 9163)
>      Memory: 30.9M
>         CPU: 1.635s
>      CGroup: /system.slice/dnscrypt-proxy.service
>              └─774 /usr/bin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
> ```

There's nothing below that output?

There's no error displayed so it should work.


> However, it seem that dns=none NOT WORKING because /etc/resolv.conf is still editable & I'm unable to use dnscrypt-proxy **UNLESS** by set NetworkManager GUI at "Automatic (DHCP) addresses only" as a method with set "DNS servers" within it at 127.0.0.1 While using default setting with method set at "Automatic (DHCP)" with no any DNS set within it, it will lead to overwrite /etc/resolv.conf with deleting "127.0.0.1" & "options edns0" & replace them by just "nameserver xxx.xxx.xxx.x" which is my ISP DNS !!


You shouldn't touch anything with the gui.In that order:
 - Revert to defaultin the NetworkManager
 - recheck that dns=none is set in the conf file 
 - rewrite resolv.conf:

nameserver 127.0.0.1
options edns0

 - set it as read-only with: sudo chattr +i /etc/resolv.conf
 - check that listen_addresses = ['127.0.0.1:53'] in /etc/dnscrypt-proxy/dnscrypt-proxy.toml
 - Finally restart the service: sudo systemctl restart dnscrypt-proxy

It should work then. If not, paste the full output of systemctl status dnscrypt-proxy

Comment 6 Robert-André Mauchin 🐧 2020-12-28 19:11:51 UTC
Also what does

    dnscrypt-proxy -resolve example.com

return?

Comment 7 yousifjkadom@yahoo.com 2020-12-28 19:18:11 UTC
@Robert-André Mauchin

Dear, I run the following commands:
sudo dnscrypt-proxy -service uninstall
sudo dnscrypt-proxy -service install --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
sudo systemctl restart dnscrypt-proxy.service
They worked 100% & now every time I reboot or power OFF/ON my PC then run:
$ systemctl status dnscrypt-proxy
I'm getting the following output:

● dnscrypt-proxy.service - Encrypted/authenticated DNS proxy
     Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-12-28 18:29:20 GMT; 8min ago
   Main PID: 774 (dnscrypt-proxy)
      Tasks: 10 (limit: 9163)
     Memory: 30.9M
        CPU: 1.635s
     CGroup: /system.slice/dnscrypt-proxy.service
             └─774 /usr/bin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

However, it seem that dns=none NOT WORKING because /etc/resolv.conf is still editable & I'm unable to use dnscrypt-proxy UNLESS by set NetworkManager GUI at "Automatic (DHCP) addresses only" as a method with set "DNS servers" within it at 127.0.0.1 While using default setting with method set at "Automatic (DHCP)" with no any DNS set within it, it will lead to overwrite /etc/resolv.conf with deleting "127.0.0.1" & "options edns0" & replace them by just "nameserver xxx.xxx.xxx.x" which is my ISP DNS !!
It seem that this issue is Fedora specific !

In summary, now I have 2 options from my NetworkManager GUI:
1) using the default Internet connection (using my ISP DNS). I can achieve this by set "Methods" at default "Automatic (DHCP) without specifying any DNS address(s),
2) utilizing the dnscrypt-proxy protection. To achieve that I have to set "Methods" at "Automatic (DHCP) addresses only" with specifying 127.0.0.1 as a DNS.

Is the above situation normal or malfunctioning ?

Please note the following: EVEN WHEN I USE "Automatic (DHCP) addresses only" as a "Methods", the file etc/resolv.conf is still editable at every reboot & power OFF/ON because what ever I enter & save the line:
options edns0
this line will deleted after each reboot or power OFF/ON !!! Why this happened ?!!

What is the ideal behaviour after set dns=none ? Should it be that GUI can not change any thing in /etc/resolv.conf ?? Is this new bug ? Do I have to open new issue here on RadHat BugZilla about it ? Does the command "sudo chattr +i /etc/resolv.conf" help ?

Comment 8 yousifjkadom@yahoo.com 2020-12-28 19:25:02 UTC
The full output of "systemctl status dnscrypt-proxy" is:

● dnscrypt-proxy.service - Encrypted/authenticated DNS proxy
     Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-12-28 18:29:20 GMT; 49min ago
   Main PID: 774 (dnscrypt-proxy)
      Tasks: 10 (limit: 9163)
     Memory: 31.0M
        CPU: 2.228s
     CGroup: /system.slice/dnscrypt-proxy.service
             └─774 /usr/bin/dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   406ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   415ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   420ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   458ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   467ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   499ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   526ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   679ms xxxxxxxxxxxxxx
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: Server with the lowest initial latency: rumpelsepp.org (rtt: 85ms)
Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: dnscrypt-proxy is ready - live servers: 80


I replaced the real value by xxxxxxxxxxxxxxxx because I'm not sure if these confidental or not. They are the DNS servers addresses that used by dnscrypt-proxy. They are not a numbers, but letters like url not started by www.

Comment 9 Robert-André Mauchin 🐧 2020-12-28 19:31:37 UTC
(In reply to yousifjkadom from comment #8)
> The full output of "systemctl status dnscrypt-proxy" is:
> 
> ● dnscrypt-proxy.service - Encrypted/authenticated DNS proxy
>      Loaded: loaded (/etc/systemd/system/dnscrypt-proxy.service; enabled;
> vendor preset: disabled)
>      Active: active (running) since Mon 2020-12-28 18:29:20 GMT; 49min ago
>    Main PID: 774 (dnscrypt-proxy)
>       Tasks: 10 (limit: 9163)
>      Memory: 31.0M
>         CPU: 2.228s
>      CGroup: /system.slice/dnscrypt-proxy.service
>              └─774 /usr/bin/dnscrypt-proxy -config
> /etc/dnscrypt-proxy/dnscrypt-proxy.toml
> 
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   406ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   415ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   420ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   458ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   467ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   499ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   526ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: -   679ms
> xxxxxxxxxxxxxx
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: Server with the
> lowest initial latency: rumpelsepp.org (rtt: 85ms)
> Dec 28 18:31:33 localhost.localdomain dnscrypt-proxy[774]: dnscrypt-proxy is
> ready - live servers: 80
> 
> 
> I replaced the real value by xxxxxxxxxxxxxxxx because I'm not sure if these
> confidental or not. They are the DNS servers addresses that used by
> dnscrypt-proxy. They are not a numbers, but letters like url not started by
> www.

From that output it seems dnscrypt-proxy is working as intended. Your issue seems to be related to NetworkManager.
Retry the dns=none in the config file.
Restart it: sudo systemctl restart NetworkManager.service
Rewrite resolv.conf

Comment 10 yousifjkadom@yahoo.com 2020-12-28 19:35:35 UTC
I tried so many time to edit /etc/resolv.conf file with:
nameserver 127.0.0.1
options edns0

but is it overwritten ! Even when I used "Automatic (DHCP) addresses only" it will delete "options edns0" after rebooting or power OFF/ON PC !

dns=none & listen addresses both are already set correctly - see screenshots.

Comment 11 yousifjkadom@yahoo.com 2020-12-28 19:36:51 UTC
Created attachment 1742777 [details]
listen-addresses

Comment 12 yousifjkadom@yahoo.com 2020-12-28 19:37:36 UTC
Created attachment 1742778 [details]
dns=none

Comment 13 yousifjkadom@yahoo.com 2020-12-28 19:40:14 UTC
Please notice that I'm on Cinnamon version of Fedora not on GNOME version. However, Cinnamon DE it is a fork of GNOME & using many of GNOME utilities .....

Comment 14 Robert-André Mauchin 🐧 2020-12-28 19:58:37 UTC
(In reply to yousifjkadom from comment #10)
> I tried so many time to edit /etc/resolv.conf file with:
> nameserver 127.0.0.1
> options edns0
> 
> but is it overwritten ! Even when I used "Automatic (DHCP) addresses only"
> it will delete "options edns0" after rebooting or power OFF/ON PC !
> 
> dns=none & listen addresses both are already set correctly - see screenshots.

I don't know how to help you more. Have you tried restarting NetworkManager with sudo systemctl restart NetworkManager.service ?
It shouldn't overwrite resolv.conf.

Is resolv.conf a regular file? What does "ll /etc/resolv.conf" return?

Try deleting the file and recreating it.

Comment 15 yousifjkadom@yahoo.com 2020-12-28 20:02:06 UTC
I remember something now: I installed Fedora 24, then upgraded to 26, then 28, then 30, & now on 32.
When I was on Fedora 28 the "dns=none" was working because at that time when I used it, it led to block ALL Internet connection apart from Tor browser which was the only way to use Internet (via it's SOCKS5 proxy default setting & ports). But when I upgraded to Fedora 30, "dns=none" never led to such block in Internet !

I do not remember now when some one inform me online that this a new setting from Fedora .....

Regarding use of "Automatic (DHCP) addresses only" with 127.0.0.1 as a DNS, I got it from many forums in Internet insisting on this approach ! I'm not sure if this indicating a global problem or not, but I want you to know about it ....

Comment 16 yousifjkadom@yahoo.com 2020-12-28 20:04:40 UTC
The output of "$ ll /etc/resolv.conf" is the following:

lrwxrwxrwx. 1 root root 35 Jun 16  2019 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf

Comment 17 Robert-André Mauchin 🐧 2020-12-29 07:25:32 UTC
(In reply to yousifjkadom from comment #16)
> The output of "$ ll /etc/resolv.conf" is the following:
> 
> lrwxrwxrwx. 1 root root 35 Jun 16  2019 /etc/resolv.conf ->
> /var/run/NetworkManager/resolv.conf

That's what's wrong, remove that symbolic link and recreate resolv.conf

Comment 18 yousifjkadom@yahoo.com 2020-12-29 09:36:35 UTC
@Robert-André Mauchin
I noticed that system upgrade can led to mistakes like this without warning or error message ...

Okay, I will do, but please review the following steps if are correct or not before I perform them because I'm not so expert in editing system files. For example, I do not know what you mean by "symbolic link" ....

sudo rm /etc/resolv.conf

sudo vi /etc/resolv.conf
& set within it,
nameserver 127.0.0.1
options edns0

reboot PC

Comment 19 yousifjkadom@yahoo.com 2020-12-29 09:38:54 UTC
@Robert-André Mauchin
I forgot to ask: do I have to power OFF/ON Internet connection (WiFi) during deletion of /etc/resolv.conf & creation of new one, or no need for that ?

Comment 20 Robert-André Mauchin 🐧 2020-12-29 14:52:41 UTC
(In reply to yousifjkadom from comment #18)
> @Robert-André Mauchin
> I noticed that system upgrade can led to mistakes like this without warning
> or error message ...
> 
> Okay, I will do, but please review the following steps if are correct or not
> before I perform them because I'm not so expert in editing system files. For
> example, I do not know what you mean by "symbolic link" ....
> 
the current /etc/resolv.conf is not a file but a link to /var/run/NetworkManager/resolv.conf

That's why NetworkManager keeps managing the file

> sudo rm /etc/resolv.conf
> 
> sudo vi /etc/resolv.conf
> & set within it,
> nameserver 127.0.0.1
> options edns0
> 
> reboot PC


yes do this, this should work

Comment 21 Robert-André Mauchin 🐧 2020-12-29 14:53:03 UTC
(In reply to yousifjkadom from comment #19)
> @Robert-André Mauchin
> I forgot to ask: do I have to power OFF/ON Internet connection (WiFi) during
> deletion of /etc/resolv.conf & creation of new one, or no need for that ?

No it doesn't matter

Comment 22 yousifjkadom@yahoo.com 2021-01-01 09:14:19 UTC
@Robert-André Mauchin
Hi.
1st I would like to say, happy new year & Merry Christmas !

I opened the following question on "Ask Fedora":
https://ask.fedoraproject.org/t/is-this-a-bug-or-intentional-change-in-fedora-etc-resolv-conf-state/11314

As you see, it seem from replay on my question on "Ask Fedora" that this is a default configuration intended by Fedora developers, may be to enable users to use GUI in more convenient way !

So, the only remaining to me before closing this tick on BugZilla are the following:

1) is my conclusion that the current state of my /etc/resolv.conf is an intended one by Fedora developer is correct ? If not please inform me so that after closing this ticket I will open new one about that issue.

2) if the current state of my /etc/resolv.conf is default intended state by Fedora developer, then can I use command "sudo chattr +i /etc/resolv.conf" instead of deletion of /etc/resolv.conf & recreating it ? If yes, then this will be better because I can simply revert changes to the default Fedora setting by run "sudo chattr -i /etc/resolv.conf"

3) the only concern from current state of my /etc/resolv.conf (being editable at each boot automatically by NetworkManager GUI) is the undo process for "edns0". Is there other way to make edns0 sticky other than deletion/recreation of /etc/resolv.conf file or using of "sudo chttr +1 /etc/resolv.conf" ?

Feel free to close this issue from your side after covering these points.

Thank you for your kind support & help. You learned me too much !

Comment 23 yousifjkadom@yahoo.com 2021-01-07 07:29:16 UTC
Hi. I received the new update for dnscrypt-proxy. But it show me strange behaviour !

During the updating process, terminal showed me a message said what mean "the "service" not installed use '-service' to install it" !! But I'm already installed service according to your instruction by using the following command:
sudo dnscrypt-proxy -service install --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
sudo dnscrypt-proxy -service start

And as I expected, after reboot my PC dnscrypt-proxy was not run & I was unable to access Internet via it.

I tried to re-run the command:
sudo dnscrypt-proxy -service install --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml

But I received in terminal what said what mean "[FATAL] .... the init is already existing ....."
So, how & why new version did not recognized that "dnscrypt-proxy.service" is already installed ?? This is the 1st error.

I run "systemctl status dnscrypt-proxy" & showed me same previous error that "it is set manually to be enabled but it exit with code ......", an error that was fixed by "-config /etc/dnscrypt-proxy/dnscrypt-proxy.toml" previous (before new version update) use.

I, then decided to run "sudo dnscrypt-proxy -service start". But it remain not completed after about 3 minutes without any thing shown in terminal. So, I decided to close terminal but I received a message said "a process already going, do you like to abort" so I abort.

Then I did the following which fix the problem:
sudo dnscrypt-proxy -service uninstall
sudo dnscrypt-proxy -service install --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
sudo dnscrypt-proxy -service start (it delayed for about 1 & 1/4 minutes before completed)
& finally run "systemctl status dnscrypt-proxy" & output was very okay.

Finally, I rebooted my PC, then rechecked & every thing was okay & can accessed Internet via dnscrypt-proxy without leak again.

Kindly, issuer me that my system not breaked by the [FATAL .....] that I received after run
sudo dnscrypt-proxy -service install --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
just after updating to new version, before "uninstall/then install" service.

Kindly, issuer me that closing terminal while "sudo dnscrypt-proxy -service start" before completed not break my system.

Comment 24 Robert-André Mauchin 🐧 2021-01-07 09:43:12 UTC
> During the updating process, terminal showed me a message said what mean "the "service" not installed use '-service' to install it" !! But I'm already installed service according to your instruction by using the following command:

During the update/install I force remove the existing service file to avoid conflict with previous system service file in /lib

> And as I expected, after reboot my PC dnscrypt-proxy was not run & I was unable to access Internet via it.

This is not normal, I need to investigate the issue.

> Kindly, issuer me that my system not breaked by the [FATAL .....] that I received after run

Absolutely not, the error is expected.

Comment 25 Bryce Torcello 2021-01-09 00:41:22 UTC
I thought I would mention this since I think it's likely this will be an issue others will encounter, which is that the upgrade from 2.0.44-5 to 2.0.44-8 breaks dnscrypt-proxy and similar to my earlier comment, I had to remove and install 2.0.44-8 in order to get it in a working state again.

It seems as if the reason for breakage this time is that 3 versions were seemingly pushed on one day (2.0.44-6, 2.0.44-7, 2.0.44-8) without testing whether the upgrade directly from 2.0.44-5 to 2.0.44-8 succeeds.

Upgrading from 2.0.44-5 to 2.0.44-6, 2.0.44-6 to 2.0.44-7 and 2.0.44-7 to 2.0.44-8 does result in a working installation of dnscrypt-proxy but unless users are checking for updates every 5 minutes, their only upgrade path is going to be directly from 2.0.44-5 to 2.0.44-8.

Comment 26 yousifjkadom@yahoo.com 2021-03-06 18:11:21 UTC
I'm already - since weeks ago - delete /etc/resolv.conf & recreating it as you instructed.

Yes, you are right & I was wrong. Without delete /etc/resolv.conf & recreating it with:

nameserver 127.0.0.1
options edns0

the dnscrypt-proxy will never provide the user with maximum benefit that it can give. I'm very wandering why Fedora made default so that /etc/resolv.conf is not a file but a link to /var/run/NetworkManager/resolv.conf !

Comment 27 Fedora Program Management 2021-04-29 16:45:09 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 28 Ben Cotton 2021-05-25 17:03:13 UTC
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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