Export thread

  • 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.)

Which DNS setting is in control???

#1

J

JorgeA

I have changed the "preferred DNS server" on my PC's Ethernet adapter properties to use Quad9 (9.9.9.9), with the alternate server set to Quad9's second choice of 149.112.112.112. The DNS settings on the router provided by my ISP (Verizon) are unchanged from default.

Out of curiosity, I tried the DNS test offered by Quad9 and, sure enough, it tells me that my PC is using Quad9 servers. However, when next I tried the test by dnsleaktest.com, that one came back saying that I'm on the servers that are listed on the Verizon router.

Now I am little more than a novice on these matters, but my understanding of it was that it's the DNS settings on your particular computer that determine where it will go looking for Web sites -- that the local settings override the router settings. However, the dnsleaktest.com results seem to say otherwise.

So, for those here who know about these things: is my PC really using Quad9, or is it still using Verizon's DNS servers?

(I do know that I can change the DNS settings on the router. What I want to find out is whether my understanding of it has been wrong all along and it makes no difference to change the DNS settings on the PC.)

Thanks very much.


#2

P

PHolder

Which browser were you using? If it's Google Chrome, it's not clear what it uses to get its DNS configuration. In my case when I experimented it was using insecure DNS and they were all Google, even though my router OS and router have other configurations. It wouldn't let me easily switch to DoH because it said my browser was being managed by my organization (unknown why, I am not an organization.) I figured out how to switch it on in the registry, but I still don't get any means to configure which DNS is used, but it did change, and now 3 out of 4 are Quad9 and the remaining one is Google.

The key is HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome for those who are interested. Make a String with DnsOverHttpsMode and set it to automatic (or secure but I used automatic as secure can result in no DNS if a failure happens, whereas automatic will fall back.)

Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"DnsOverHttpsMode"="automatic"


#3

J

JorgeA

I tried each of the two tests on Vivaldi and Waterfox. They gave the same results: Quad9 says I'm using them, while dnsleaktest.com says I'm using Verizon.


#4

P

PHolder

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.

Code:
R:\TEMP>ipconfig/all

Windows IP Configuration

   Host Name . . . . . . . . . . . . :  xxx
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
   Physical Address. . . . . . . . . :  xxx
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : xxx
   IPv4 Address. . . . . . . . . . . : xxx
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : July 10, 2024 11:33:44 PM
   Lease Expires . . . . . . . . . . : August 10, 2024 4:35:25 PM
   Default Gateway . . . . . . . . . : xxx
   DHCP Server . . . . . . . . . . . : xxx
   DHCPv6 IAID . . . . . . . . . . . : xxx
   DHCPv6 Client DUID. . . . . . . . : xxx
   DNS Servers . . . . . . . . . . . : xxx  <<<<<<<<<<<<<<<<<<<<<<<<<
   NetBIOS over Tcpip. . . . . . . . : Enabled

If you don't have DNS security configured, this is the value I would expect your browser to be using.

Also, here's another tool to try: https://www.top10vpn.com/tools/what-is-my-dns-server/


#5

J

JorgeA

Thanks, I tried both of your suggestions. Using IPCONFIG /ALL did show Quad9 to be the DNS server. On the other hand, the top10vpn.com tool reported the Verizon servers to be my DNS server. o_O

Further down that page, they also suggest using NSLOOKUP in a command prompt... and this time I'm back to Quad9. Huh?!?

This is so bizarre. How can we tell which method's output is closer to the truth?


#6

P

PHolder

Well one very scary possibility comes to mind. Perhaps Verizon is intercepting all requests to the Quad9 servers and "silently" redirecting them to their own?

Have you ever used NSLOOKUP? (On Windows?) It's easy enough to use, so it can't hurt, but it's unclear how we'll know anything from it really, because it simply show you which server you're using, and you already should know that from the IPCONFIG/ALL. I didn't show it below, but the command to get out of it is exit .

Code:
R:\TEMP>nslookup
Default Server:  router.asus.com
Address:  xxx  <<<<< This is my router IP address which is what I expect.

> server 9.9.9.9    <<<<<<  tell it a different server
Default Server:  dns9.quad9.net
Address:  9.9.9.9

> set type=A   <<<<< tell it IPv4 lookup
> google.com
Server:  dns9.quad9.net
Address:  9.9.9.9

Non-authoritative answer:
Name:    google.com
Address:  172.217.165.14

> set type=AAAA   <<<<<< tell it IPv6 lookup
> google.com
Server:  dns9.quad9.net
Address:  9.9.9.9

Non-authoritative answer:
Name:    google.com
Address:  2607:f8b0:400b:804::200e


#7

J

JorgeA

Whoa -- it WOULD be scary if that's what was going on. It's the opposite of what I've read is the case, that the local DNS settings are supposed to override the router settings.

Yeah, I did try NSLOOKUP and it came back saying I'm on Quad9.

I have Norton 360 on this PC and they offer a VPN service as part of the package. Maybe I'll switch that on and see if it changes the output from top10vpn.com.


#8

J

JorgeA

UPDATE: Turned on the Norton VPN and, according to top10vpn.com, my DNS server now is from Amazon.com (?!?).

Would still like to hear insights on whether the adapter settings for DNS are or are not overridden by the router settings. I always thought the settings on the PC took precedence over the router's settings.


#9

f1assistance

f1assistance

UPDATE: Turned on the Norton VPN and, according to top10vpn.com, my DNS server now is from Amazon.com (?!?).
How do we not innerstand what a VPN is/does?
What Is SSL Inspection?
Why would we blindly trust any 'security software' (e.g., Norton 360), as it's a MitM with complete administrative privileges?
What "router" do you have on your perimeter?


#10

miquelfire

miquelfire

Does Windows' NSLOOKUP just display the server it's configured to use for DNS, or does it have a method to ensure there's no MITM attack that intercepts DNS packets? I remember in the Edgerouter guide Steve has referenced before having a bit where you can force DNS traffic to go through your DNS server, even if the client was configured for something else (This was before DOH and DOT BTW. Don't know if the guide was updated to deal with those, or if it was removed because you can't intercept that type of traffic). So with that guide, if someone on that network had configured their DNS to OpenDNS, and you use that guide to force people to use QUAD9, their NSLOOKUP would report OpenDNS, but they were actually using QUAD9. They might be doing something like that.


#11

P

PHolder

does it have a method to ensure there's no MITM attack that intercepts DNS packets?
Most of basic DNS without security is over UDP, so it would be easy to interfere with. There are security options for DNS, they are just not the defaults (in general) for most users. I think enabling DNS security would be the solution to the OP's issues.


#12

J

JorgeA

Would still like to hear insights on whether the adapter settings for DNS are or are not overridden by the router settings.


#13

Tazz

Tazz

Not to hijack the thread, but my PC DNS settings kinda override my modem/router.

I say kinda because the GRC Spoofability Test finds two DNS servers. One of the two that are set on my PC and none of the ones set in the router.

The other DNS server (107.161.13.135 - IP-107-161-13-135.static.fibrenoire.ca) it finds is "dead" according to the GRC DNS Benchmark utility but here I am testing its spoofability. It scores "Good" to "Excellent" varying throughout the day; "Lost Entropy" changes a little.


#14

P

PHolder

Turned on the Norton VPN and, according to top10vpn.com, my DNS server now is from Amazon.com
That probably means "Norton" uses AWS servers for their VPN service. Once you're using a VPN, you lose all control over what the exit node does with things like DNS and routing of packets.


#15

D

DanR

Would still like to hear insights on whether the adapter settings for DNS are or are not overridden by the router settings. I always thought the settings on the PC took precedence over the router's settings.
That is my understanding. All that I have read, as well as my personal experience, supports the PC DNS settings overriding what is in the router..


#16

J

JorgeA

OK, I've run through the tests listed on Michael Horowitz's DNS page at routersecurity.org. Here's what they output:

We already know about dnsleaktest.com: it says that I'm using Verizon DNS servers.
Browserleaks.com also has me using Verizon.
Dnscheck.tools similarly has me on Verizon.
Perfect-privacy.com doesn't give any results, it only reports "Checking DNS servers, please wait..." but never gets around to completing the task.
Expressvpn.com shows my PC connecting to Verizon servers.

So it looks like only Quad9 is saying that I'm on their DNS resolvers, the ones that I set under Ethernet Adapter.


#17

EdwinG

EdwinG

So, I just ran the DNS Spoofability Test, and it uncovered something that wasn’t mentioned.

It’s possible that the DNS recursor (resolver) is hosted at your ISP.
When I run those ISP leak tests, my ISP always shows up as one of the servers. I know my equipment doesn’t do any DNS rewriting (I have full control over that). It’s the PTR record for one of the IPv4 addresses that gave it away for me.


#18

J

JorgeA

It’s possible that the DNS recursor (resolver) is hosted at your ISP.
When I run those ISP leak tests, my ISP always shows up as one of the servers.
Interesting. Seeking to understand this: could it mean that it's not necessarily true that the PC's settings for DNS take precedence over the router's settings?


#19

f1assistance

f1assistance

Does Windows' NSLOOKUP just display the server it's configured to use for DNS, or does it have a method to ensure there's no MITM attack that intercepts DNS packets? I remember in the Edgerouter guide Steve has referenced before having a bit where you can force DNS traffic to go through your DNS server, even if the client was configured for something else (This was before DOH and DOT BTW. Don't know if the guide was updated to deal with those, or if it was removed because you can't intercept that type of traffic). So with that guide, if someone on that network had configured their DNS to OpenDNS, and you use that guide to force people to use QUAD9, their NSLOOKUP would report OpenDNS, but they were actually using QUAD9. They might be doing something like that.
No, Norton 360 as with any such 'security' software suite is literally a MitM...


#20

EdwinG

EdwinG

Interesting. Seeking to understand this: could it mean that it's not necessarily true that the PC's settings for DNS take precedence over the router's settings?
That was not exactly where I was going with my post, but the answer to your statement is… maybe.

It is indeed possible for a router to be configured to redirect traffic to a given device, especially when it is unauthenticated and in a local network. That would allow a home router to intercept that traffic and handle it according to its defined configuration.

That's a little bit how captive portals work on WiFi. They intercept DNS and HTTP traffic to redirect you to the captive portal instead of going out to the Internet (implementations do differ, but the logic stays the same).

What I had in mind is regular day-in day-out Internet routing, where a single IP address could be distributed across multiple servers (aka anycast).

It is possible for a given service (your DNS recursor/resolver for the purposes of this discussion) to have a server hosted on your ISP's network and have it announce that 9.9.9.9 is at your ISP. When DNS tests will run, they will see another at-ISP address querying them because the answer needs to go back to the server servicing and not somewhere random. This will show up as your ISP in the report even if your computer did successfully query 9.9.9.9 and the expected host replied.
So, when I tested my home network which uses CIRA's Canadian Shield (with DNS-over-TLS) as one of the upstream services, it showed up with my ISP's name as a reverse DNS record (Edit: as I was writing this post, I discovered that my ISP seems to host that server for public use).

To illustrate and test this, a simple trace route (using tracert) can be done. In my demonstration, I will use the Quad9 server at 9.9.9.9 and the open-source MTR tool with -zw command line arguments which gives me a report with AS numbers (network operators; I won't use them). I will hide the first 3 "public" hops to protect my IP addresses :).

When I run it from my home, it goes through this path:
Code:
~ % mtr 9.9.9.9 -zw
Start: 2024-08-10T23:02:26-0400
HOST: MyLaptop.local                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    gw (172.16.10.1)                                    0.0%    10    2.9   2.9   2.2   5.0   0.8
  2. AS5645   ISPRouter1.teksavvy.com (0.0.0.0)                   0.0%    10   15.6  16.0  15.0  17.0   0.7
  3. AS5645   ISPRouter2.teksavvy.com (0.0.0.0)                   0.0%    10   16.9  17.5  14.9  23.3   2.9
  4. AS5645   ISPRouter3.teksavvy.com (0.0.0.0)                   0.0%    10   16.5  17.0  15.3  26.5   3.4
  5. AS5645   ae1-0-bdr02-tor1.teksavvy.com (206.248.153.7)       0.0%    10   15.8  15.7  15.1  16.5   0.4
  6. AS???    equinix01-ch1.pch.net (208.115.136.31)              0.0%    10   28.1  26.2  25.0  28.9   1.3
  7. AS19281  dns9.quad9.net (9.9.9.9)                            0.0%    10   29.4  26.3  24.2  34.7   3.3

Through a VPN on a server I operate from Montréal, it goes through:
Code:
~ % mtr 9.9.9.9 -zw
Start: 2024-08-10T23:05:10-0400
HOST: MyLaptop.local                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    10.0.200.1                                0.0%    10   22.6  23.3  22.1  27.9   1.7
  2. AS???    0.0.0.0                                   0.0%    10   22.4  23.3  22.4  26.0   1.0
  3. AS16276  0.0.0.0                                   0.0%    10   23.2  23.1  22.3  24.3   0.6
  4. AS???    0.0.0.0                                   0.0%    10   23.6  22.9  21.9  23.6   0.6
  5. AS???    10.196.135.125                            0.0%    10   22.6  24.2  22.5  30.9   2.6
  6. AS???    10.196.134.162                            0.0%    10   23.3  24.2  23.0  27.5   1.5
  7. AS???    10.196.134.140                            0.0%    10   22.7  23.3  22.5  25.8   0.9
  8. AS???    10.74.9.238                               0.0%    10   23.9  24.0  22.5  30.5   2.4
  9. AS???    10.95.81.10                               0.0%    10   23.9  24.0  23.0  26.3   0.9
 10. AS16276  ymq-mtl3-sbb2-8k.qc.ca (142.44.208.174)  50.0%    10   27.4  27.8  25.6  30.9   1.9
 11. AS???    10.200.3.5                               20.0%    10   25.6  28.8  25.6  37.3   5.0
 12. AS???    pch1.peer.qix.ca (198.179.18.20)          0.0%    10   23.7  24.1  23.5  24.8   0.4
 13. AS19281  dns9.quad9.net (9.9.9.9)                  0.0%    10   23.5  24.0  23.5  24.5   0.4

What we can observe from these 2 routes is that they don't end up at the same physical locations.
The penultimate hop is in different locations:
  • Home ISP: Somewhere in Chicago (equinix01-ch1 seems to be Equinix's CH1 datacentre)
  • VPN: Somewhere in Montréal (QIX on hop 12)
Note: An IP operator can put any valid name in a reverse DNS record; they can't lower the calculated round-trip latency (they can increase it in theory, although I cannot think of a benefit in doing so).
We can observe that the average latency is about the same between the penultimate and the last hop. It means that they are not geographically distant, probably in the same or nearby building (let's say within 1km). It is safe to assume that those two 9.9.9.9 servers are not the same device.
Additionally, in the second route, all the hops have a reasonably close latency meaning they're all really close between them (within 100km). Communicating with Chicago from Montréal would roughly add 20ms worth of round-trip latency to those numbers.

Considering that it is meant to be a global service, it would make sense that that address when requested from Auckland shouldn't go to the same location as Montréal or Toronto; it would add unnecessary latency for every DNS query (over 210ms or 0.21s for a round-trip). That becomes perceptible for an end-user.

In conclusion, what I'm trying to say is that it might be normal and expected :) That's how a lot of CDN services work, they simply have caching servers close to the end-users.

Network routing is definitely a fun rabbit hole someone can drop into ;)


#21

R

RayG

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.


#22

J

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."


#23

J

JorgeA

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.


#24

EdwinG

EdwinG

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 :)


#25

J

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?


#26

EdwinG

EdwinG

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 :)


#27

J

JorgeA

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?


#28

P

PHolder

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.)


#29

J

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."


#30

P

PHolder



#31

EdwinG

EdwinG

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.


#32

J

JorgeA

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?


#33

EdwinG

EdwinG

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.


#34

J

JorgeA

Show up as a server at Verizon (showing Verizon as the ISP), correct.
Huh, interesting -- thank you. Maybe everything's good after all, then.


#35

A

a viewer

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).


#36

B

bdub76

Here's some more information about how DNS is setup in your browser:



#37

barnski

barnski

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.


#38

MichaelRSorg

MichaelRSorg

DNS is complicated, much more so than many people are aware. For example, I know of 13 places where your DNS configuration settings might come from. Part of the complication is old insecure DNS vs. new secure DNS (in two flavors no less). Also, there are OS level DNS settings and web browser DNS settings. It's a lot.

I suggest starting here
https://routersecurity.org/testdns.php

and, if you can, read the long DNS explanation too.