Which DNS setting is in control???

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

Well I guess the first thing to verify is that your system is working as you think it is. In a CMD window do a IPCONFIG/ALL and check to make sure the DNS values are what you think they're supposed to be configured as.


Also, here's another tool to try: https://www.top10vpn.com/tools/what-is-my-dns-server/
Interesting that web site gives me this list:
Code:
Country    ISP    DNS Server
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.84.158
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.84.161
US    WOODYNET-1 - WoodyNet    74.63.26.236
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.161.153
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.161.152
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.161.151
US    CLOUDFLARENET - Cloudflare, Inc.    172.70.88.209
US    WOODYNET-1 - WoodyNet    74.63.26.239
US    WOODYNET-1 - WoodyNet    2620:171:fa:f0::11
2400:cb00:793:1024::ac46:a198
2400:cb00:736:1024::ac45:2b2c
US    WOODYNET-1 - WoodyNet    2620:171:fa:f0::239
US    WOODYNET-1 - WoodyNet    2620:171:fa:f0::235

WOODYNET looks to be an interesting one? I'll need to look further at some point.
 
  • Like
Reactions: JorgeA
WOODYNET looks to be an interesting one? I'll need to look further at some point.
WoodyNet addresses similar to the ones that you list, are what I'm getting when running the DNS tests linked on Michael Horowitz's page. (That is, I'm getting those instead of the 9.9.9.9 that I've set on my PC's Ethernet Adapter Properties.)

Just this morning, I noticed the following paragraph on that page:

It is commonly thought that if the Operating System specifies DNS servers (either for Ethernet or for a specific SSID) they will get used. This is not always the case. Some routers (such as the Pepwave Surf SOHO) can force clients to use the DNS servers specified in the router. Worse, if the router is doing this (at least with Peplink routers) the computer can not tell. The DNS server the computer sees is not the one really being used.

Looks like my Verizon router (a Fios-G1100) may be among the routers that "force clients to use the DNS servers specified in the router."
 
Now here's another perspective to leave the whole situation clear as mud:

If you're saying that the router gives itself to clients as a DNS server, that's typically how it works. DNS requests will go from your client to the router to Cloudflare. Some routers will hand off themselves + whatever DNS servers are configured in the router[...]

Edit: Technically the router's acting as a forwarder/proxy in this scenario, not a server.

If true, then would this suggest that a PC that had DNS on its Ethernet Adapter set to Quad9, would indeed be using Quad9, and that the information being reported (that it's still relying on the ISP's DNS servers) is incorrect?

Maybe @Steve can do a deep dive on this topic for SN.
 
If true, then would this suggest that a PC that had DNS on its Ethernet Adapter set to Quad9, would indeed be using Quad9, and that the information being reported (that it's still relying on the ISP's DNS servers) is incorrect?
It’s not necessarily incorrect, because Quad9’s server could be hosted at your ISP. In which case, you’re still using Quad9, and that the ISP for their server is your ISP.

Those two situations are not mutually exclusive :)
So you could be using Quad9, and they’re using your ISP to better service you :)
 
  • Like
Reactions: JorgeA
It’s not necessarily incorrect, because Quad9’s server could be hosted at your ISP. In which case, you’re still using Quad9, and that the ISP for their server is your ISP.

I'd be extremely surprised to learn that Verizon is itself using Quad9 DNS servers!

If possible, I'd like to get to the bottom line here. As I see it, there are (at least) two possibilities:
  1. The Verizon router is ignoring (or overriding) my PC's DNS setting to use Quad9, and using Verizon DNS servers instead; or
  2. The Verizon router is actually honoring my PC's DNS settings, but the various "DNS leak test" results are misinterpreting the router's forwarding of requests as the router substituting its own DNS settings for mine.
Is there a way to tell what's truly going on?
 
I'd be extremely surprised to learn that Verizon is itself using Quad9 DNS servers!
Although possible, unlikely.

I meant that there is a computer from Quad9 at Verizon that is handling traffic for 9.9.9.9.

That’s scenario number 3.
If possible, I'd like to get to the bottom line here. As I see it, there are (at least) two possibilities:
  1. The Verizon router is ignoring (or overriding) my PC's DNS setting to use Quad9, and using Verizon DNS servers instead; or
  2. The Verizon router is actually honoring my PC's DNS settings, but the various "DNS leak test" results are misinterpreting the router's forwarding of requests as the router substituting its own DNS settings for mine.
Is there a way to tell what's truly going on?
Why not do a traceroute to 9.9.9.9, and see the path it takes :)
 
I meant that there is a computer from Quad9 at Verizon that is handling traffic for 9.9.9.9.

That’s scenario number 3.
Hmm... how likely is such a scenario?

Regarding traceroute (tracert in my case), this is actionable information. The output seems to show that the data goes through at least two locations with Verizon in their name, before eventually landing at 9.9.9.9.

Therefore, in my case at least, setting the PC's DNS in Ethernet Adapter Properties to Quad9 apparently did not actually make Quad9 the DNS resolver for that PC. Would that be an accurate interpretation -- or is this another case of the Verizon router working as a "forwarder," as suggested in the Reddit thread?
 
Traceroute shows how an "average" packet would be handled by your network, and while it is useful information, it doesn't give anything specific about specific protocols that may be [effectively] rerouted by a "device in the middle". Traceroute packets are ICMP packets and are handled differently than UDP and TCP packets in general, so you can't really rely on it showing if your UDP packet is being rewritten somewhere along that path unbeknownst to you. (This is what would be happening if your router (or even your ISP in its network) were to attempt to hijack your [insecure] DNS queries.)
 
  • Like
Reactions: JorgeA
Traceroute packets are ICMP packets and are handled differently than UDP and TCP packets in general, so you can't really rely on it showing if your UDP packet is being rewritten somewhere along that path unbeknownst to you.
I'm starting to think that I should forget about the Ethernet adapter properties setting, and instead just point my browsers to a secure DNS server. In Waterfox, for example, I can choose from among Cloudflare, NextDNS, or a custom provider (although I wouldn't know what information to put in for the custom provider, there are no instructions given for that in the browser settings). Unlike DNS Server in the (Windows) network adapter properties, these settings do seem to "take" when I run the various "DNS leak tests."
 
Hmm... how likely is such a scenario?
The answer is: Highly likely.

That's how Cloudflare, Akamai and other content delivery networks work with HTTP(S). They put their servers close to the users to distribute load and improve user experience.

Traceroute packets are ICMP packets and are handled differently than UDP and TCP packets in general, so you can't really rely on it showing if your UDP packet is being rewritten somewhere along that path unbeknownst to you.
By the way, Traceroute exists in both TCP and UDP mode when given proper flags; Microsoft did not implement those. You can even specify the port you're targeting ;)

On macOS, it would be traceroute -P tcp -p 53 9.9.9.9 or traceroute -P udp -p 53 9.9.9.9. Linux has a similar capability.

Code:
% traceroute -P tcp -p 53 9.9.9.9
traceroute to 9.9.9.9 (9.9.9.9), 64 hops max, 40 byte packets
 1  [AS0] gw (172.16.10.1)  1.096 ms  0.250 ms  0.221 ms
 2  [AS5645] ISPRouter1.teksavvy.com (0.0.0.0)  15.650 ms  13.384 ms  13.192 ms
 3  [AS5645] ISPRouter2a.teksavvy.com (0.0.0.0)  13.985 ms
    [AS5645] ISPRouter2b.teksavvy.com (0.0.0.0)  13.739 ms
    [AS5645] ISPRouter2c.teksavvy.com (0.0.0.0)  13.182 ms
 4  [AS5645] ISPRouter3a.teksavvy.com (0.0.0.0)  13.861 ms
    [AS5645] ISPRouter3b.teksavvy.com (0.0.0.0)  13.807 ms
    [AS5645] ISPRouter3c.teksavvy.com (0.0.0.0)  13.807 ms
 5  [AS5645] ae2-0-bdr02-tor1.teksavvy.com (206.248.153.5)  13.622 ms
    [AS5645] ae1-0-bdr02-tor1.teksavvy.com (206.248.153.7)  13.655 ms
    [AS5645] ae2-0-bdr02-tor1.teksavvy.com (206.248.153.5)  13.391 ms
 6  * [AS30159] equinix01-ch1.pch.net (208.115.136.31)  26.758 ms !X *
 7  * * *
 8  * * *
 9  * [AS0] equinix01-ch1.pch.net (208.115.136.31)  23.507 ms !X *
10  * *^C

While ICMP is imperfect, it still provides a pretty good idea on what's going on.
I'm starting to think that I should forget about the Ethernet adapter properties setting, and instead just point my browsers to a secure DNS server. In Waterfox, for example, I can choose from among Cloudflare, NextDNS, or a custom provider (although I wouldn't know what information to put in for the custom provider, there are no instructions given for that in the browser settings). Unlike DNS Server in the (Windows) network adapter properties, these settings do seem to "take" when I run the various "DNS leak tests."
You could enable DNS-over-TLS in Windows… However, it is a command line configuration. It only works over TCP and requires certificate validation. There's also DoH that's available.
 
I meant that there is a computer from Quad9 at Verizon that is handling traffic for 9.9.9.9.
So let me see if I understand this. You're saying that (for example) Quad9 would have its own server at Verizon handling traffic for 9.9.9.9, but that this Quad9 server at Verizon would show up in these various tests as a Verizon server, is that correct?
 
So let me see if I understand this. You're saying that (for example) Quad9 would have its own server at Verizon handling traffic for 9.9.9.9, but that this Quad9 server at Verizon would show up in these various tests as a Verizon server, is that correct?
Show up as a server at Verizon (showing Verizon as the ISP), correct.
 
  • Like
Reactions: JorgeA
if you are using dns over regular mechanics (port 53 and open), the router can substitute the dns server for one they like. It can be used in some simple wifi hotspot to prevent you from using an external dns to access the internet. However, many routers offer this as an option when you set them.

there are also some utilities in your computer that might try to overwrite the dns selection (e.g. nextdns).
 
If you review the Quad9 FAQ at https://docs.quad9.net/FAQs/#__tabbed_4_2 under "Network Providers / DNS Leak Tests" it states:
Quad9 utilizes multiple network providers in our global network. When running a DNS leak test, it's expected to see IP addresses owned by the following providers:
  • WoodyNet (AKA PCH.net)
  • PCH.net
  • i3D
  • EdgeUno
  • Equinix Metal (FKA: Packet, Packet.net, or Packethost)
  • Path.net (Path Network)
  • E-MAX (Bratislava, SK)
On that basis, I think it's probably OK that I (and other Quad9 users in this thread) see a WoodyNet IP when doing a DNS leak test.

However, Verizon is not on that list, so I'm not sure this helps the OP.
 
Last edited: