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]

Thank you.

[MNLierman]

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.

No offense, but except it doesn't. I say this respectfully, as I really appreciate this project, but did you see the discussion item I've made? If I loose internet, DNSCrypt requires it's service to be restarted because it gets stuck.

[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.