New release

[akirayamamoto]

I see that there are recent commits, some updating dependencies. On the other hand, the last release was more than one year ago. Is there a reason to hold these recent changes back?

[jedisct1]

The current code is unreliable and there are changes I don't understand nor trust. So, a new release will be tagged once this has been addressed. Meanwhile, the current release works fine.

[akirayamamoto]

I understand your frustration but try and go easy on the dev. This project has some interesting features and I am sure it's not easy to keep everything top notch. In addition, I am sure they are not making much if any money out of this. Also, very likely they need to sacrifice their spare time to work on this after their shift.

Are you accepting PRs to fix issues, dev?

[MNLierman]

I don't mean any disrespect to the dev, which is why I said I appreciate the project, and I respect him for what he does, but this is indeed a long-standing bug which was first reported in 2021, and his comment at the time, was that it's just a log warning message and doesn't have any other effects. Maybe he was saying that based on the information he was making assumptions on at the time, but this statement is incorrect.

I suppose I could fork it and fix the problem myself but I'm not sure I am talented enough to create a TTL expiration for DNS requests when the internet is down. That's what DNSCrypt needs is a TTL for requests, something that says "this request by x client expires in 60 seconds regardless of if the DNS request was able to be fulfilled." Likely the client has moved on much before that 60 seconds has elapsed, but it's a good starting point that would prevent DNSCrypt from getting stuck on too many requests because clients are freaking out and sending hundreds a second. I have a busy network with 40 devices, 2/3 of those are IoT devices.

It's reasonable to think that if the internet goes down, it could get flooded with retires from each client, so in this respect, a variable called RequestTTL should be created, with a default of 60 seconds, and after that time, the request is removed if it was not fulfilled. I'm not sure I could handle such a feature on my own, as I'm not well versed in this particular programming language, but I could probably muster up a wipe out function that clears the requests once the limit is hit, or waits for connectivity to be restored and then clears it. The term used is connections, not requests, but I'm sure it's requests because my pihole forwards the requests to DNSCrypt, so I know for a fact that my clients are not connecting to it directly. The term "Max Connections" used is a bit misleading.

[Dizirgee]

Just wanted to applaud the dev for this answer. After XZ backdoor fiasco people need to be extra vigilant.
After all we dont want dnscrypt to start suddenly sending our data to FSB/GRU or MSS/SSF and the like, do we? :)

Many thanks for your effort and work Frank, I'm using this great sw on my computers for 10+years

[MNLierman]

Just wanted to applaud the dev for this answer. After XZ backdoor fiasco people need to be extra vigilant.
After all we dont want dnscrypt to start suddenly sending our data to FSB/GRU or MSS/SSF and the like, do we? :)

Many thanks for your effort and work Frank, I'm using this great sw on my computers for 10+years

All respect, this is an ongoing discussion about unresolved issues with DNS Crypt. I'm not sure what fiasco you're talking about or what point you're trying to make. You've just notified everyone that has participated in this discussion. What contribution are you making to this discussion? This isn't a Reddit thread. This is a development discussion regarding unresolved issues.

Millions of repos get pull requests everyday, a pull request has nothing to do with a backdoor. Reviewing code and accepting pull requests does not increase your susceptibility to a backdoor. Good f—ing grief. You're referencing an obscure event which is completely unrelated to this core problem.

If the developer wanted to spend the time, and again I say this without any disrespect, it's not very difficult to go through the pull request, review the code, and the comments. There are even free ML algorithms on GH that can be deployed to help flag and score PRs to make the task easier.

The problem I recognize is, these devs and contributors have other things going on in their life that they prioritize higher than this project. Such as what happens with many projects like this. Small project, small team. People get busy, they've got lives, kids, other jobs, and I'm sure that this project doesn't make them any money. It's really unfortunate, because there're a lot of great projects and apps that end up getting dropped or fizzled and die due to lack of support and development. So much good stuff I run into everyday. .

For the moment, I moved onto testing Cloudflared DoH, but it may not be much better. A separate issue was slow overall DNS lookup as calculated by PiHole ranging in 100-200 when the nearest DNS Crypt based DNS server is 40 miles from me and registers at 5ms. It seems like AdGuardHome occasionally has the same issue. Ideally, DNS traffic should be the highest priority on the network. So that specific issue regarding latency might not be related to DNS Crypt at all.

The other remaining issue I had with it was if the Internet went out, DNS Crypt fails to recover without restarting the service. I can reproduce it every time using the steps I provided in another comment. To work around that issue, I'm contemplating putting in a script that pings a server every minute, or maybe 5 minutes. Just one ping packet, if the internet is down, it will start a loop, and as soon as the internet comes back up, it restarts DNS Crypt. It's a work around solution, not a bug patch. It should work though. Debating moving back to DNS Crypt and doing this.

[Dizirgee]

Man, sorry, but are you for real? You hijacked this thread in the first place, and i just wanted to support dev's stance on this.
Because imo it is important.
I mean did you even read his reply? "there are changes I don't understand nor trust" and thats exactly why this is excellent approach on his part! And why you shouldnt hijack thread about unrelated bug you may have found/experience. You countered his response with fabulation that "dnscrpyt doesnt work", i understand you may have been frustrated by that bug but for majority of users its working fine but calling dev on BS is way too much imo.
And you made your post on Oct 20 and 4 days later you felt entitled enough for prompt bugfix so you come to bug here. What contribution you were making by that post?

Especially if you cant even insert "XZ backdoor" into your favorite search engine and read on the problem, instead of writing lengthy reddit post. So with your own words, I dont know what contribution you made with that last post(s) of yours...sorry

just two popular links from search engines on topic:
https://www.wired.com/story/xz-backdoor-everything-you-need-to-know/
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
You could have read up on that, and spare us all of your rambling post (because you would have understood point of my post, i assume).