[SOLVED] Some webpages/terminal connectivity works but not others.

archuser38013 · 2024-07-28 10:27:45

seth wrote:

ping duckduckgo.com
What's the output for that? You might be using https://en.wikipedia.org/wiki/IPv6_tran … nism#DNS64

The output is just like any other when you use ping.

How do you mean I might be using it? I haven't setup anything and installed arch fresh on this system not long ago so it would have to be via the ISP, and, as mentioned, it only works when using those specifics nameservers I put in previous reply. So somehow must be happening elsewhere than locally?

Last edited by archuser38013 (2024-07-28 10:28:17)

seth · 2024-07-28 16:09:22

The output is just like any other when you use ping.

Don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Seriously.

I don't care whether you use a hello-kitty colorscheme, an ugly font or whether the columns were properly aligned or any "looks" but whether it's maybe resulting in pinging a (synthetic) IPv6 because that would be DNS64 and also explain why you can't use a different DNS.
In that case everytime you ask for an domain w/o an IPv6, the DNS generates one and your ISP maps that to the IPv4 internally.

archuser38013 · 2024-07-29 14:22:46

seth wrote:

The output is just like any other when you use ping.
Don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
Seriously.
I don't care whether you use a hello-kitty colorscheme, an ugly font or whether the columns were properly aligned or any "looks" but whether it's maybe resulting in pinging a (synthetic) IPv6 because that would be DNS64 and also explain why you can't use a different DNS.
In that case everytime you ask for an domain w/o an IPv6, the DNS generates one and your ISP maps that to the IPv4 internally.

How are you able to tell that from the ping output? Here it is:

$ ping duckduckgo.com
PING duckduckgo.com (64:ff9b::348e:7cd7) 56 data bytes
64 bytes from 64:ff9b::348e:7cd7: icmp_seq=1 ttl=112 time=64.8 ms
64 bytes from 64:ff9b::348e:7cd7: icmp_seq=2 ttl=112 time=62.8 ms
64 bytes from 64:ff9b::348e:7cd7: icmp_seq=3 ttl=112 time=61.3 ms
64 bytes from 64:ff9b::348e:7cd7: icmp_seq=4 ttl=112 time=59.4 ms
64 bytes from 64:ff9b::348e:7cd7: icmp_seq=5 ttl=112 time=57.4 ms
!!:s^C
--- duckduckgo.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 57.395/61.140/64.782/2.568 ms

I would really like to get to the bottom of it as it is just a mystery to me. traceroute and traecepath won't work for v4 IPs or domains. Yet ping and firefox will work for the domains.

Last edited by archuser38013 (2024-07-29 14:27:29)

seth · 2024-07-29 14:28:12

PING duckduckgo.com (64:ff9b::348e:7cd7) 56 data bytes

Does that look like an IPv4?
You're using DNS64 and you'll *have* to use that DNS for "IPv4" connections unless you find a different service w/ similar provision.

Despite multiple requests you've never actually provided a dig/drill result from your ISP DNS, but see for yourself

 dig @8.8.8.8 -t A duckduckgo.com # 40.114.177.156
 dig @8.8.8.8 -t AAAA duckduckgo.com # nope
 dig -t A duckduckgo.com # no idea, probably 40.114.177.156 ?
 dig -t AAAA duckduckgo.com # 64:ff9b::348e:7cd7

archuser38013 · 2024-07-29 14:32:13

seth wrote:

PING duckduckgo.com (64:ff9b::348e:7cd7) 56 data bytes
Does that look like an IPv4?
You're using DNS64 and you'll *have* to use that DNS for "IPv4" connections unless you find a different service w/ similar provision.
Despite multiple requests you've never actually provided a dig/drill result from your ISP DNS, but see for yourself
 dig @8.8.8.8 -t A duckduckgo.com # 40.114.177.156
 dig @8.8.8.8 -t AAAA duckduckgo.com # nope
 dig -t A duckduckgo.com # no idea, probably 40.114.177.156 ?
 dig -t AAAA duckduckgo.com # 64:ff9b::348e:7cd7

What is my ISP dns? Don't recall receiving that request and don't know what my ISP DNS is.

Last edited by archuser38013 (2024-07-29 14:32:54)

seth · 2024-07-29 14:35:27

The default that's working, in https://bbs.archlinux.org/viewtopic.php … 1#p2185051 I asked the first time for a couple of outputs, the 2 & 3 one contrast the default ISP against 9.9.9.9

archuser38013 · 2024-07-29 14:39:19

seth wrote:

The default that's working, in https://bbs.archlinux.org/viewtopic.php … 1#p2185051 I asked the first time for a couple of outputs, the 2 & 3 one contrast the default ISP against 9.9.9.9

I guess that is what those 4 commands above are?

$ drill @9.9.9.9 -t A duckduckgo.com
Error: error sending query: General LDNS error
$ drill @9.9.9.9 -t AAAA duckduckgo.com
Error: error sending query: General LDNS error
$ drill -t A duckduckgo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 10155
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; duckduckgo.com.      IN      A

;; ANSWER SECTION:
duckduckgo.com. 51      IN      A       52.142.124.215

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 243 msec
;; SERVER: 127.0.0.53
;; WHEN: Mon Jul 29 14:34:11 2024
;; MSG SIZE  rcvd: 48
$ drill -t AAAA duckduckgo.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 544
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; duckduckgo.com.      IN      AAAA

;; ANSWER SECTION:
duckduckgo.com. 188     IN      AAAA    64:ff9b::348e:7cd7

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 155 msec
;; SERVER: 127.0.0.53
;; WHEN: Mon Jul 29 14:35:14 2024
;; MSG SIZE  rcvd: 60

Last edited by archuser38013 (2024-07-29 14:39:50)

seth · 2024-07-29 14:44:08

drilling 9.9.9.9 doesn't work b/c you can't reach IPv4, you could try

drill @2001:4860:4860::8888 -t A duckduckgo.com
drill @2001:4860:4860::8888 -t AAAA duckduckgo.com

But as you can see, you're getting the synthetic IPv6 resolution (AAAA) from your DNS and that's then also how you can access ddg, despite it not having an actual IPv4

archuser38013 · 2024-07-29 14:45:48

seth wrote:

drilling 9.9.9.9 doesn't work b/c you can't reach IPv4, you could try
drill @2001:4860:4860::8888 -t A duckduckgo.com
drill @2001:4860:4860::8888 -t AAAA duckduckgo.com
But as you can see, you're getting the synthetic IPv6 resolution (AAAA) from your DNS and that's then also how you can access ddg, despite it not having an actual IPv4

How does AAAA mean it is synthetic? So is the conclusion it is nat64/ or cgnat which is what they told me, via the ISP?

archuser38013 · 2024-07-29 14:49:40

Is there no way to have different nameservers then with this current hardware? No workaround? Not a big deal but nice to know if there is a way around it.

-thc · 2024-07-29 15:34:25

To clear things up a little:

CGNAT is a technique used by providers to stop providing a public IPv4 address for every customer. You still get an external IPv4 address and can use it for outgoing IPv4 traffic - the only limitation is that your external IP is normally not reachable from the internet (incoming IPv4 traffic).

NAT64 is a technique used by providers to stop providing IPv4 completely. You only get an IPv6 address for your client and the providers DNS server generates NAT64-IPv6 addresses (64:ff9b::/96) for IPv4-only hosts on the internet. The provider "translates" the NAT64-IPv6 traffic to IPv4 traffic.

You can not use any other DNS server because it would disrupt your providers NAT64 mechanism. If you are unable to reach certain IPv4 servers it's your providers responsibility. Maybe some applications struggle with NAT64 but I lack the experience.

Last edited by -thc (2024-07-29 15:58:18)

archuser38013 · 2024-07-29 16:15:36

-thc wrote:

To clear things up a little:
CGNAT is a technique used by providers to stop providing a public IPv4 address for every customer. You still get an external IPv4 address and can use it for outgoing IPv4 traffic - the only limitation is that your external IP is normally not reachable from the internet (incoming IPv4 traffic).
NAT64 is a technique used by providers to stop providing IPv4 completely. You only get an IPv6 address for your client and the providers DNS server generates NAT64-IPv6 addresses (64:ff9b::/96) for IPv4-only hosts on the internet. The provider "translates" the NAT64-IPv6 traffic to IPv4 traffic.
You can not use any other DNS server because it would disrupt your providers NAT64 mechanism. If you are unable to reach certain IPv4 servers it's your providers responsibility. Maybe some applications struggle with NAT64 but I lack the experience.

Thanks that does help further explain things a little.

If it is a lost cause then I will just settle with it then. At least as more time passes it should become less relevant as ipv6 adoption grows.

seth · 2024-07-29 20:38:43

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

Arch Linux

#26 2024-07-28 10:27:45

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#27 2024-07-28 16:09:22

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#28 2024-07-29 14:22:46

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#29 2024-07-29 14:28:12

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#30 2024-07-29 14:32:13

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#31 2024-07-29 14:35:27

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#32 2024-07-29 14:39:19

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#33 2024-07-29 14:44:08

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#34 2024-07-29 14:45:48

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#35 2024-07-29 14:49:40

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#36 2024-07-29 15:34:25

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#37 2024-07-29 16:15:36

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

#38 2024-07-29 20:38:43

Re: [SOLVED] Some webpages/terminal connectivity works but not others.

Board footer