-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ams-dnscrypt-nl: Returning bad results for github.com #853
Comments
/cc @kokial |
Having the same issue. The returned IPv6 appears to be a NAT64 address. |
I use this with the default log level to see where the query is forwarded to: [query_log]
file = '/dev/stdout' |
jedisct1
added a commit
that referenced
this issue
Nov 10, 2023
agross
added a commit
to agross/ansible-home-network
that referenced
this issue
Nov 11, 2023
The test script is based on https://github.com/kkkgo/PaoPao-Pref/blob/bef1cb285c8f2b8ec61977d2a7309f59ad4b06ce/dnscrypt_resolver/check.sh It verifies that: * Known IPv4 and IPv6 addresses resolve * An AAAA query for github.com does not return a NAT64 IPv6 address DNSCrypt/dnscrypt-resolvers#853 * The short TTL of a known address is unchanged It's best to run the script on a docker host that has IPv6 enabled such that IPv6 servers can be reached from within the test container.
Fixed in #857 |
Thank you! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I noticed this due to SSH access to Github became unexcusably slow:
ssh -vT github.com
showed that it tried to connect first to IPv6 to github, timed out and then connected via IPv4. Infamously, Github doesn't have IPv6.Turns out this DNSCrypt resolver is returning garbage in this case, "ams-dnscrypt-nl"
Now 64::/16 for IPv6 is just non-sense and
20.205.243.166
is apparently Microsoft's hosting in Singapore (I am from Europe).Even though my config has
require_nofilter = true
, kkkgo determined here this server to be filtering.Log file:
Is there no option to log each DNS query to console? --loglevel doesn't cut it. So you will have to take my word for it. Other servers when selected work correctly. I have managed at least once to hit a correct result between restarting dnscrypt-proxy and writing this down, but other than that this is a consistent error with this server.
I have no idea if this is a way to contact the server admin or whatever be done.
The text was updated successfully, but these errors were encountered: