WireShark is a good tool to see network activity, you can use it to see which IP is exactly being connected to by any program.

At the SuperUser forum, I explained what I am trying to do and asked how to confirm in Windows, what IP address browsers like Edge, Chrome and/or Firefox are using, to check whether or not they obey what one has entered into the hosts file.

The first suggestion I got was not to use the hosts file, but set up my own DNS server and enter any of the exceptions to it. Yeah, I guess that would be one solution... but I don't think it is feasible to suggest here anyone, who wants to try some alternative GOG download server (from what GOG/Fastly gives them by default) "Yeah, just set up your own DNS server and put the additional A record there, eezy peezy lemon sqeezy". :D

And, if I've understood correctly, that wouldn't work either if DNS-over-HTTPS (or DNS-over-TLS) kicks in? The IP-address would still be received from some DoH-capable DNS that the browser forces you to use, not your own DNS server (nor the hosts file)?


Thanks, I forgot about that. That may be the best solution in this case, to troubleshoot this. I haven't used Wireshark in ages, now it is good time to do so.

What's the deal with DNS-over-HTTPS (or DNS-over-TLS) anyway? I get confused when I try to find more information about it, especially as most of the active discussion seems to be from like 5 years ago for some reason, apparently back when Mozilla rolled out the feature on their browsers. Things that I've read:

1. Mozilla and other browser makers were, years ago, very keen on introducing the feature to their browsers. My assumption now is that all major browsers have this feature, but I have no idea if it is enabled by default, or not. I think I checked my Firefox and possibly Edge browsers and the feature seemed to be there, but disabled in my case. Need to google the instructions for each browser as different browsers call the feature with their own names, "Secure DNS" or whatever they like.

2. Years ago, there was news that Firefox/Mozilla will enable this feature by default for US users of their browser. So... has Mozilla really done that, and why specifically US folks? Why not the rest of the world, Europe etc.? So is it now enabled by default (only) for US users, but it can still be disabled too, right?

3. Some discussion on the subject proclaimed that the whole campaign of browser makers introducing it directly to their browsers is stupid and redundant, as all OSes (Windows, Linux, Mac etc.) are going to introduce the same feature right into the OS anyway. So... has that happened already? Do e.g. Windows and newer Linux distro releases offer DoH and/or DoT on the operating system level, and is it disabled by default?

It is nice to learn about technical subjects, but sometimes the more you read, the more confused you become, sheesh...

DNS-over-HTTPS was "allegedly" made to secure both privacy and security concerns, f.ex. a MITM attack as UDP sends in plain text (as mentioned above where an ISP can snoop up DNS request and then sends their own DNS response, regardless).

However, as usual, it can provide more problems than it solves:

You can read more about it here:
https://www.sans.org/white-papers/39160/

Main points are: https://blog.mozilla.org/en/products/firefox/firefox-continues-push-to-bring-dns-over-https-by-default-for-us-users/

Right. Firefox family tends to use CloudFlares DoH resolvers, but LibreWolf (the one I use) has it off (if I remember correctly). Not sure about Chrome since I don't use it. But yeah, it's easy to forget you've made changes to either that or the hosts file which may screw the results later on (as Timppu found out).

CDN's relies heavily on back-ends and load-balancing, but as I mentioned before, what route it takes through the different networks depends heavily on available routes and configurations.

Traffic to/from DNS servers and traffic to/from servers with the other protocols (i.e. file transfers) isn't the same, but yes, depending on what you get from the DNS it can be pretty bad, especially if the network or the server you finally get is configured badly, has high traffic, or limits its bandwidth.

With Wireshark and Nmap you'll be able to find a lot of information about the path through the different networked tiers, however, load-balancing and backends are generally something that happens "behind the scenes" while only exposing one or a handful of IP addresses.

If Wireshark or Nmap is too daunting, then I can recommend at least tracert (Traceroute), a good tool to in every network troubleshooting:

Here's what I get when I try tracert 151.101.85.55

4 19 ms 19 ms 20 ms irb-2925.agg2.xxx.us.m247.ro [37.120.220.38]
5 25 ms 25 ms 26 ms te-0-0-0-5.bb1n.xxx.se.m247.ro [37.120.220.158]
6 * * * Request timed out.
7 26 ms 25 ms 26 ms 151.101.85.55

And with gog-cdn.us-eu.map.fastly.net I get:

4 19 ms 21 ms 19 ms irb-.-.us.m247.ro [37.120.220.38]
5 18 ms 18 ms 20 ms ae6-.-.ip4.gtt.net [212.222.111.25]
6 26 ms 26 ms 26 ms ae3.-.ip4.gtt.net [89.149.129.98]
7 * * * Request timed out.
8 27 ms 27 ms 27 ms be4649.-.-.atlas.cogentco.com [130.117.3.130]
9 35 ms 33 ms 33 ms be4094.-.-.atlas.cogentco.com [154.54.37.58]
10 35 ms 34 ms 35 ms be4090.-.-.atlas.cogentco.com [154.25.16.154]
11 32 ms 32 ms 32 ms 149.6.117.26
12 32 ms 32 ms 34 ms 151.101.237.55

You see how the traffic is diverted depending on if you use the host name or the IP directly? The same goes for different protocols and apps and the order of things as well (nslookup f.ex. completely bypasses the hosts file while ping -a doesn't).

So, subdomains and IP addresses of those sub-domains can change any time depending on where you are, what DNS you use and get from it/them, and the configuration of that network. And using VPN won't necessarily be better.

This really is down the rabbit- (PI-)hole. I need coffee...

EDIT: I know where .ro is supposed to be, but all I see is
.ro
.ro
.row your boat... XD

GOG didn't like this post initially but adding a small amount at a time just left one small section that didn't post :/.

I mostly only know about the status in Firefox and on Linux but quick searching suggests they are in other recent operating systems as well (but maybe not Windows 10). In general, I think it is a good step for privacy even though it has limitations on its own (Encrypted Client Hello also helps but requires tls1.3). I'm not sure there would be any progress on the availability of encrypted DNS without Mozilla pushing DNS over HTTPS so I think it was a good thing for them to push even if it is confusing. An older encrypted DNS protocol, DNScrypt, was less well supported (I think that one required configuring a server public key rather than using TLS certificates). DNS is core network infrastructure so any changes are almost guaranteed to be contentious and confusing.

I would say that it is better to use one of them for the system resolver than just in the browser. I think the possibility of causing issues with CDNs may be part of why Mozilla limits where it is enabled by default, maybe also the presence of nearby servers that pass their privacy guidelines (however I am just guessing, they have a FAQ but it doesn't say why they choose particular locations; they say it is currently enabled by default in the US, Canada, Russia, and Ukraine). There is a way to signal that DNS over HTTPS shouldn't be used by default and I wouldn't be surprised if many bad ISPs signal that but it will still be used if explicitly configured. I don't know if any operating systems enable either by default yet (systemd-resolved does not and only supports DNS over TLS for now). The main difference is that over TLS uses a dedicated port while over HTTPS uses the standard HTTPS port so in theory over HTTPS could be harder to block, although at this point resolvers I know about aren't running on the same server as other websites (other than websites about the DNS server) so they could easily be blocked by IP (however some networks will just block anything but HTTPS so it can still help in that case; just using DNS over TLS on the HTTPS port would work in that case too but DNS over HTTPS allows a webserver to also run on the same port).

Personally I use systemd-resolved and DNS over TLS. I route all of my traffic through a SOCKS proxy and configure the ssh connection to also connect a local port to 8.8.8.8 port 853 (via the openssh -L option) so the DNS server tries to find IP addresses close to the remote side (at least I think this works, I recall it seemed to help when I set it up). It unfortunately seemed like Google was the best option near me (I don't trust Cloudflare at all) although there seemed to be a number of privacy focused options in Europe.

In your case the host seemed to resolve to a different IP address but there is also anycast which causes one IP address to go different places depending on where you are connecting from. I don't think using wireshark or nmap for this is helpful but traceroute is and is widely available (often called traceroute and some routers have a traceroute function in the admin interface).

In Firefox, about:networking#dns will show you what IP addresses Firefox is getting.

I don't agree with the complaints about DNS over HTTPS you mentioned.