These servers never supported the DNSCrypt v2 protocol, and have
been a pain to maintain compatibility with. But the main issue
is that in some countries, they are now lying resolvers, *except*
for the certificate.
That makes it difficult to reliably detect that they are lying
resolvers. From a user perspective in these countries, it appears
that DNS queries randomly fail, when they are hitting these servers.
I tried to think of different ways to detect this, but couldn't
find anything satisfactory.
Maybe if they properly implement the DNSCrypt protocol some day,
they will take it as an opportunity to also fix that bug, and
return consistent error codes, even for the certificates.
This commit updates the forwarding plugin to support matching subdomains
of the root domain ("."). It looks like the forwarding plugin already
performs subdomain matches against the domains specified in the
forwarding rules files, but matches against the root domain weren't
working because of the way matches are performed by comparing the
normalized presentation format QNAME (which omits the trailing dot for
all QNAMEs except the root domain name).
Without this commit, only queries where the QNAME is exactly "."
would match a forwarding rule for the "." domain, like this (with
`offline_mode = true` and a single forwarding rule for the "." domain):
```
[2024-03-25 21:13:31] 100.100.100.100 . NS FORWARD 0ms 127.0.0.1:53
[2024-03-25 21:13:36] 100.100.100.100 com NS NOT_READY 0ms -
```
With this commit I get the expected result:
```
[2024-03-25 21:40:07] 100.100.100.100 . NS FORWARD 0ms 127.0.0.1:53
[2024-03-25 21:40:09] 100.100.100.100 com NS FORWARD 0ms 127.0.0.1:53
```
There's nothing special about "-service install".
On any system, executables shouldn't be modifiable by other system
users, no matter what the executable is and how it's run.
