coolreader18 wrote: ⤴Thu Nov 08, 2018 8:56 pm
I've been having this issue for about a week, and it came completely out of the blue. I can't connect to IPv4 addresses at all, and I'm 99% sure that's the definite issue. With the settings I had prior to this problem, I could ping/browse google.com and a few other sites, but nothing else. After a bit and browsing some stackexchange posts I realized that they all had IPv6 addresses, and the sites I couldn't connect to were all IPv4. So after some searching I set up DNS64 and NAT64, but the issue with those is that they are
slow. Google's speed test, which uses its own IPv6, gives me ~50 Mb/s download, while speedtest.net, which only has IPv4 and has to route through DNS64, gets around 2 Mb/s. I don't have this issue when connected via ethernet. In NetworkManager, I have IPv4 disabled for my network, and using
TREX's DNS64 server for the IPv6 tab's DNS (google's DNS64 doesn't work).
something 6 to 4 appears to be working for you... I'd look at fully undoing any local NAT64/DNS64 then try other remote options (besides TREX) since their policy, as read from your link above, states:
TREX policy: Acceptable Usage wrote:The servers are made available as is. Their main intended userbase is Finland. We reserve the right to deny this service if we uncover abuse or malicious activities. We may also limit the NAT64 traffic to less than 100Mbps for the same reason. The maximum acceptable rate of queries to the recursive name servers from a single network is one thousand queries per second or 1000q/s.
unlikely you would have been flagged abusive (although...single network?), however, they may have implemented geo-blocks/restrictions recently that drop your requests if you are not:
TREX policy: About wrote:...Finnish end users as part of a research project in association with the Finnish Future Internet programme and Internet Testbed Finland.
Like trytip's inital response (and having read your replies) I still believe this is a DNS (or more specifically a NAT64 DNS) issue. Please bear with me, Ima Linux noob so offer food for thought, not advice. I also agree with trytip's most recent reply on attempting to do what you do using LM live session to help rule out ISP and remote DNS issues.
Wrapping my head around all this I found this helpful from cloudflare blog:
Translation requires technologies such as NAT64 and DNS64. NAT64 allow IPv6 hosts to communicate with IPv4 servers by creating a NAT-mapping between the IPv6 and the IPv4 address. DNS64 will synthesize AAAA records from A records. DNS64 has some known issues like DNSSEC validation failure (because the DNS server doing the translation is not the owner’s domain server). For service providers, supporting IPv4/IPv6 translation means providing separate IPv4 and IPv6 connectivity thus incurring additional complexity as well as additional operational and administrative costs.
my first step would be to make sure DNSSEC is disabled if you find you require DNS64 (which you "shouldn't" if the DNS server is IPv6, leaving NAT64 still a potential problem), those validation failures may be causing issue.
then I'd remove TREX from the equation, at least to test things are working at your PC. try
Cloudflare IPv6 DNS for that.
(their DNS address info from that page since IPv4 resolving is not working
Code: Select all
The addresses of 1.1.1.1 are:
1.1.1.1
1.0.0.1
2606:4700:4700::1111
2606:4700:4700::1001
if that doesn't change anything then I'd consider blocking IPv4 "system wide", to rule out resolve timeouts due to something weird going on between IPv4&6 on your PC. A good discussion on that can be found here:
Security flaw found in systemd (translate disabling IPv6 methods into IPv4 info you want)
other thoughts:
what is
docker0 first device listed in the ifconfig output? is this a docker.com app created virtual adapter that you run DNS64 or something else from?
Also curious about where you mentioned putting the cloudflare and google IPv4 DNS entries on a disabled IPv4 system?
(as well I do not think your assessment of
host command in terminal returning appropriate IPv4 address demonstrates DNS works for your system by showing you an IPv4 result. Although I could be wrong, as I block IPv6 everywhere I can, system wide, and always get error from host lookup, as seen here:
Code: Select all
~$ host google.com
google.com has address 172.217.1.206
google.com host information "AAAA queries have been locally blocked by dnscrypt-proxy" "Set block_ipv6 to false to disable this feature"
however, I can open google.com via IP address direct
172.217.1.206 in browser address bar. I cannot ping in terminal nor directly open IPv6 addresses in browser as entire system is IPv6 disabled.
When I run test at
test-ipv6 anything regarding IPv6 results show Fail and I would expect yours to return all as good and especially IPv6 info (NAT64 I believe will respond to test with IPv4 info?). It may be worth your while to reenable IPv4 to run this test fully, they provide a lot of details and information on the tests, even formatting the FAQs to include your info.
(edit 1 for typos and clarification
(edit 2 to add
APNIC NAT64 check HTH!
