The cause of death of a large number of DOH is unknown. #2380
57382
started this conversation in
Potential issues
Replies: 1 comment 1 reply
-
|
Yes. |
Beta Was this translation helpful? Give feedback.
1 reply
-
It must be stated that I have no malicious intentions. Even when I speak harshly and look unfriendly. |
Beta Was this translation helpful? Give feedback.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
-
OpenWrt 21.02.6 Stable Release arm cpu
dnscrypt-proxy 2.1.2
server_names = []
timeout = 10000
bootstrap_resolvers = ['127.0.0.1:53']
Dnsmasq forwards DNS requests to local port 53.
This will force DNSCRYPT to act as its own bootstrap_resolvers.
ignore_system_dns = false
Because the ISP DNS of the system has been killed by me,
there is no other DNS, only DNSCRYPT.
This will force DNSCRYPT to use local port 53.
This causes the request to end up returning DNSCRYPT itself.
My dnscrypt-proxy parameters are set as follows:
Only the DOH parser is enabled.
Disable DNSCRYPT and other resolvers.
require_dnssec = false
require_nolog = false
require_nofilter = false
This enables all 120+ DOH resolvers.
Special settings:
Disable IPV6 completely.
Disable DNS cache completely. DNSCRYPT and Dnsmasq.
Disable ISP DNS completely. IPV4 and IPV6.
Lock Windows DNS to 192.168.1.1.
Completely disable Browser Secure DNS.
Force use of router DNS.
Rigorous multiple times, verify all the above settings.
Test against doh.ffmuc.net 5.1.66.255 using SmartDNS. Very rigorous testing. Verified that ffmuc works 100%. Verified that ffmuc dnssec works 100%. The ping is about 200ms.
The current number of DOH resolver servers is 127.
127-38, we get 89 DOH dead body.
Do the same multiple tests with your DNSCRYPT. I get: ffmuc is dead. ffmuc is dead. ffmuc is dead.
For testing purposes, I only traced ffmuc. If I tracked down more, I would undoubtedly find more DOH dying of your DNSCRYPT.
I have enabled DNSCRYPT log 0. But got nothing. Didn't get the doh.ffmuc.net error.
I correctly filled in the IP of doh.ffmuc.net in captive-portals.txt. Thus prompting doh.ffmuc.net to avoid stepping on your bootstrap_resolvers.
I know that DNSCRYPT hardcodes 9.9.9.9 as built-in DNS.
Your 9.9.9.9 is a virus. I had to completely ban the 9.9.9.9 IP using the firewall.
In my network environment, ISPs go crazy attacking insecure legacy DNS.
This will cause a large number of domain name resolution failures. These are DOH server domain names. These are the domain names that DNSCRYPT uses to update SDNS.
That's why I spit out 9.9.9.9. It is poisonous food.
A similar resolver, SmartDNS, does not have hardcoded DNS.
I just disable ISP DNS, delete all DNS of SmartDNS,
Using SmartDNS I was able to destroy my DNS resolution and not be able to open any web pages.
It's sensible, and it allows me to do what I want. Your hardcoded 9.9.9.9 is just plain stupid.
SmartDNS does not use bootstrap_resolvers. This is a Heartbleed method.
It can directly use the DOH which has the IP address. As long as one DOH's IP is running normally, it will automatically use this IP to resolve the IP addresses of all other DOHs. We have more than 120 DOH servers. Most of them have fixed IP addresses. So SmartDNS never fails.
And your 9.9.9.9 will be killed by the ISP at the starting line. LOL. What's more, your 9.9.9.9 will lead 120+ DOH to die together.
Your require_dnssec is also a joke. This is even more useless than require_nolog. Some DOH resolvers claim to be dnssec. Is this really the case? Absolutely not! require_dnssec=true. Then go to https://en.internet.nl/connection. Test several times. You will fall over dnssec many times. require_dnssec is only symbolic in nature. As long as the resolver says that it is dnssec, it will enter the dnssec list of DNSCRYPT. This is a serious mistake! You cannot verify the authenticity of require_nolog. But for dnssec you can use internet.nl and many other similar sites for authenticity verification. Only by passing the actual test can it be marked as dnssec.
If the DOH resolver is not dnssec it can still be killed by the ISP!
Use SmartDNS. I can just specify DOHdnssec as a resolver for other DOHs.
DOH dnssec ensures food is safe.
It's also silly to force an update of the resolvers list. refresh_delay Max 168 hours limit. Greater folly is yet to come. Suppose the copy of DNSCRYPT-PROXY was published a month ago. public-resolvers.md has not been updated for a month at this time. DNSCRYPT will intelligently treat it as a completely invalid resolver. At this point, you are the same as if there is no public-resolvers.md file! DNSCRYPT will resolve and download new public-resolvers.md with hardcoded 9.9.9.9. Looks like it's right up your alley again. LOL.
dnscrypt-proxy is the worst program design I have ever seen.
Beta Was this translation helpful? Give feedback.
All reactions