Export thread

  • DNS Benchmark v2 Release 5 with Consultant License
    Guest:
    If you own any earlier release of our DNS Benchmark you may immediately download its release #5 replacement. Running an earlier release will detect the new release and help you upgrade.

    Although this release is cosmetic, appearance matters and affects ease of use. The biggest change, as seen in the image above, is that the DNS Benchmark now has a traditional Windows application menu to more fully expose its many features. This release is also "Consultant License Aware" and GRC will now issue a Consultant version when owners have previously purchased four "Personal Use" licenses. If you have previously purchased four DNSB licenses, or if you wish to upgrade your "Personal Use" license to Consultant, GRC's purchase process will direct you through that process.
    /Steve.
  • 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.)

DNS Benchmark V2 - Lost connectivity

#1

I

Info

Hello everyone, I am very pleased to have acquired my DNSBench license, however I am experiencing the error below.

dnsbench.png



I'm running in standard 5x mode, I don't have IPv6 enabled, only IPv4.
Is there something I should do?

Best Regards,


#2

I

Info

noerror.png


At no point does the internet go down or lose connection.


#3

D

DanR

What is your benchmark speed? See the main drop down menu, roughly 1/3 of the way down.

What is the speed of your internet connection?


#4

I

Info

DanR said:
What is your benchmark speed? See the main drop down menu, roughly 1/3 of the way down.

What is the speed of your internet connection?
Click to expand...

My home internet is fiber 600/300

After clicking the ignore button about 9 times, it hasn't appeared again for now.

Attachments


  • Captura de tela 2025-12-05 232121.png
    Captura de tela 2025-12-05 232121.png
    180.8 KB · Views: 204

#5

D

DanR

You obviously have plenty of bandwidth! :)

I'm thinking that something at your ISP may be sensitive to all the queries coming from DNSB, and temporarily slamming the door on DNSB.. If so, attempting 10x or 20x should exacerbate the problem.

I would suggest running at 1x (1/5 the queries of 5x) and see if that works consistently for you.


#6

I

Info

DanR said:
You obviously have plenty of bandwidth! :)

I'm thinking that something at your ISP may be sensitive to all the queries coming from DNSB, and temporarily slamming the door on DNSB.. If so, attempting 10x or 20x should exacerbate the problem.

I would suggest running at 1x (1/5 the queries of 5x) and see if that works consistently for you.
Click to expand...

The only thing I did was add more DNS servers, but even at 1x it's saying it will take 13 hours, is that correct?


#7

I

Info

@Steve

Is there anything I should do?

I don't mind the time, but it's frustrating when it takes hours and when I check, there's a "connection lost" window, and I have to click "ignore" to continue.

I'm running Windows 11 25H2, wired modem via network cable, there are no internet connection drops, firewall and antivirus disabled, nothing blocking anything.

Is there anything that can be done?

What is the estimated time to complete in x1 x5 x10

Attachments


  • error.png
    error.png
    183.6 KB · Views: 189

#8

D

DanR

Info said:
he only thing I did was add more DNS servers, but even at 1x it's saying it will take 13 hours, is that correct?
Click to expand...
13 hours is definitely very excessive.

Again: What is your benchmark speed? Click the red icon in the UL corner of the DNSB window to pop up the drop down menu. Roughly 1/3 of the way down you should see "Check Benchmark speed xx msec". What is the value of xx? (the default value is 50 msec)

What list of DNS resolvers are you running? The Built In list? A Custom Build list? Or? What is the number of resolvers in that list?

It takes me about 10-12 minutes for an initial benchmark of the BI list. After pruning out the dead and sidelined resolvers, and a few of the slowest, the rest routinely benchmarks in about 9 min for me.

Running a Custom Build routinely takes about 16 minutes. After benchmarking the 50 or so fastest and pruning out the undesirables, the resulting shorter list, including my system resolvers, routinely benchmarks in 3-4 minutes for me.


#9

I

Info

DanR said:
13 hours is definitely very excessive.

Again: What is your benchmark speed? Click the red icon in the UL corner of the DNSB window to pop up the drop down menu. Roughly 1/3 of the way down you should see "Check Benchmark speed xx msec". What is the value of xx? (the default value is 50 msec)

What list of DNS resolvers are you running? The Built In list? A Custom Build list? Or? What is the number of resolvers in that list?

It takes me about 10-12 minutes for an initial benchmark of the BI list. After pruning out the dead and sidelined resolvers, and a few of the slowest, the rest routinely benchmarks in about 9 min for me.

Running a Custom Build routinely takes about 16 minutes. After benchmarking the 50 or so fastest and pruning out the undesirables, the resulting shorter list, including my system resolvers, routinely benchmarks in 3-4 minutes for me.
Click to expand...

What is your benchmark speed? 50msec default, I have now changed it to 20. However, I didn't see any difference.
personalized list, .txt attached

Attachments


  • speed dnsbench.png
    speed dnsbench.png
    147.8 KB · Views: 234
  • DNSBench.txt
    15 KB · Views: 277

#10

I

Info

Changed to 100msec, I think that solved the problem.

Attachments


  • speed100ms.png
    speed100ms.png
    154.3 KB · Views: 160

#11

D

DanR

The default speed is 20, not 50. My bad. 😐

I was thinking your ISP is throttling DNSB's query rate. That appears to be the case. At 100 msec your ISP seems happy. :)

On occasion your ISP would temporarily block all DNS queries. DNSB would incorrectly interpret this as a loss of connectivity.


#12

I

Info

DanR said:
The default speed is 20, not 50. My bad. 😐

I was thinking your ISP is throttling DNSB's query rate. That appears to be the case. At 100 msec your ISP seems happy. :)

On occasion your ISP would temporarily block all DNS queries. DNSB would incorrectly interpret this as a loss of connectivity.
Click to expand...
DanR, It's been 25 minutes since I made the change and the error hasn't reappeared yet (I think it's been resolved), but note the remaining time is 72 hours. Is that normal?

Should I interrupt the test and gradually decrease the time from 80 to 60 to find the shortest time before the "connection loss" error appears? Would setting it to 100ms cause any problems?

Thanks very much for all help.

Best Regards,

Attachments


  • b.png
    b.png
    167 KB · Views: 148
  • a.png
    a.png
    193.6 KB · Views: 168

#13

I

Info

I mean, even though the error isn't showing up, something isn't right because it shouldn't take that long in 100ms.

The speed shouldn't interfere with the results, right?


#14

I

Info

The error still appears, it took a while but it's back.


#15

D

DanR

Info said:
It's been 25 minutes since I made the change and the error hasn't reappeared yet (I think it's been resolved), but note the remaining time is 72 hours. Is that normal?
Click to expand...
Nope. Very abnormal. However, some of it is due to the 100 msec speed. The rest (most of it) is presumably your ISP throttling.
Info said:
Should I interrupt the test and gradually decrease the time from 80 to 60 to find the shortest time before the "connection loss" error appears? Would setting it to 100ms cause any problems?
Click to expand...
Worth a try. By now you should have enough data to eliminate, say, the slowest 2/3 of the resolvers being tested. That should reduce run time by 2/3 as well as reducing the querying (a good thing) your ISP sees. The text file you provided contains 287 resolvers (the Built In list). There is no need to keep testing all 287, especially since your ISP is apparently not happy with that.
Info said:
The speed shouldn't interfere with the results, right?
Click to expand...
Slower speed typically means more accurate results. But given your ISP's throttling, I would not expect it to matter much.

I presume you have not tried to build a Custom List yet.


#16

Steve

Steve

Info said:
DanR, It's been 25 minutes since I made the change and the error hasn't reappeared yet (I think it's been resolved), but note the remaining time is 72 hours. Is that normal?
Click to expand...
@Info: First of all, thank you for your purchase of this past year of my work and a year of a large group's extensive testing! (y)

Here's what's going on: The loss of connectivity you experienced is (normally and should be) very rare. What's happening is that the DNSB release 1 code is not taking into account the time spent with the benchmark doing nothing while it's displaying that dialog box. Since it estimates the amount of time to finish by looking at how long it took to get as far as it did, that estimate will be WAY WAY off, since the benchmark had trouble right from the start. It's a little bit like a lever: So much time was taken to get so very little done that this hugely ballooned the remaining time estimate.

So, now that the benchmark is running along nicely for you, you should be seeing the estimated time remaining dropping by much more than one second every second. It will be "converging" on the correct remaining time.

Thanks to your report I've made a note to STOP the running time meter while that interruption dialog is displayed. It never occurred to me before. So thank you! Once I've accumulated feedback from this "maiden voyage" of DNSB I'll update the code and everyone will be notified to grab the improvement. :)


#17

I

Info

DanR said:
Nope. Very abnormal. However, some of it is due to the 100 msec speed. The rest (most of it) is presumably your ISP throttling.

Worth a try. By now you should have enough data to eliminate, say, the slowest 2/3 of the resolvers being tested. That should reduce run time by 2/3 as well as reducing the querying (a good thing) your ISP sees. The text file you provided contains 287 resolvers (the Built In list). There is no need to keep testing all 287, especially since your ISP is apparently not happy with that.

Slower speed typically means more accurate results. But given your ISP's throttling, I would not expect it to matter much.

I presume you have not tried to build a Custom List yet.
Click to expand...
Hey DanR, Thank you very much.

I reduced the file size to approximately 45 DNS entries, and it actually completed once at 100ms in 5 minutes without any errors.

DNS Benchmark Conclusions & Recommendations

What the results you have just obtained mean to YOU

The results summary, conclusions, and recommendations from your most recent run of this DNS benchmark are provided below. Please carefully consider the implications of making any changes to your system's current configuration before doing so.


þ No packets were lost during the benchmarking.
During the benchmarking, 7,000 DNS queries were sent and 7,000 DNS replies were received. This means that no packets were dropped during any of their transits to and from the resolvers being tested.


þ System has multiple redundant nameservers configured.
This system is currently configured to use 2 separate nameservers for DNS name resolution. This is in keeping with recommended best practice (of having at least two different nameservers) so that the temporary failure of any single nameserver will not prevent all DNS name resolution.


þ All system nameservers are alive & replying to queries.
All of this system's 2 nameservers are working and replying to queries. This is terrific because if the system's primary nameserver were to become overloaded or unavailable, even briefly, one or more backup nameservers are standing by ready to supply DNS lookup services.


ý System nameserver(s) are NOT FULLY FUNCTIONAL!
You may have noticed that the "Name" and "Owner" pages of the “Nameservers” page do not contain the domain name and server ownership information, respectively, of the publicly available alternative DNS resolvers. This information is publicly available, but was not obtained due to the defective operation of this system's nameserver(s).

Recommended Actions:

⦁ This is quite uncommon and very troubling since all properly functioning DNS resolvers are able to lookup and supply this standard and publicly available information. You should, therefore, seriously consider determining and resolving the cause of this standard information outage and use the testing of this benchmark to determine when the problem has been resolved.

⦁ It is possible for this warning notice to be falsely presented if this benchmark's normal alternative public nameservers have been removed and replaced with nameservers that lack any domain name and server ownership information, respectively,. If this is the case, please disregard this incorrect interpretation of the lack of any domain name and server ownership information, respectively,.


ý System nameservers are SLOWER than 17 public alternatives!
This benchmark found 17 publicly available DNS nameservers that are statistically significantly faster than the slowest nameserver currently being used by this system. If you were to adjust your system's configuration to use the faster of these nameservers instead of what it is currently using, your DNS lookup performance, and all use of the Internet, would be improved.

The addresses of the 17 significantly faster publicly available DNS nameservers, listed in order of declining speed (the fastest is first), are:

185.228.168.9
149.112.112.11
9.9.9.11
149.112.112.10
185.228.168.10
149.112.112.112
8.8.8.8
9.9.9.10
162.159.46.1
162.159.36.1
8.8.4.4
1.1.1.2
1.1.1.3
162.159.36.2
1.0.0.1
1.0.0.3
1.0.0.2

Note: A total of 22 publicly available nameservers are on average faster than the slowest nameserver being used by this system, but the speed difference is only statistically significant for 17 of them shown above.

Recommended Actions:

⦁ With at least 95% certainty: Based upon a statistical analysis of the spread in timing value samples received during the benchmark, there is at least a 95% certainty that the performance conclusions stated above are correct. But even so, since changing DNS nameservers requires thought and effort, it's something you want to be sure about. Therefore, since these results represent a single snapshot in time, you may wish to confirm that the faster alternative nameservers are consistently faster than your system's currently configured nameservers, and that those public alternatives don't have any negative characteristics such as being colored orange to signify that they redirect mistaken URLs to an advertising-laden search page rather than returning an error (which will be a concern to some users).

⦁ You may also wish to check the relative performance at different times of day to make sure that the performance improvement over your system's current nameservers is reliable throughout the day.

⦁ And you may wish to make sure that the alternative nameservers are enough faster than what you are currently using for the improvement to be worth changing away from what you're currently using. (This test is only saying that it's 95% sure they are any amount faster.)


þ This system's nameservers are 100% reliable.
DNS reliability is extremely important, since lookup requests that are dropped and ignored by nameservers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup nameservers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

During this benchmark test, all of the system's nameservers tested returned a reply for every request sent. It doesn't get any better than that. Very nice.


þ All of this system nameservers return errors.
This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameservers are returning errors when asked to lookup non-existent domain names.


þ System nameservers are replying to all query types.
During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameservers are replying to these unusual but valid queries.
Click to expand...

Attachments


  • resulta.png
    resulta.png
    148.2 KB · Views: 196
  • resultok.png
    resultok.png
    141.9 KB · Views: 356

#18

Steve

Steve

@Info:
[X] System nameserver(s) are NOT FULLY FUNCTIONAL!
You may have noticed that the "Name" and "Owner" pages of the “Nameservers” page do not contain the domain name and server ownership information, respectively, of the publicly available alternative DNS resolvers. This information is publicly available, but was not obtained due to the defective operation of this system's nameserver(s).
Click to expand...
We can see from your bar chart that all of the server names are set at "Determining Ownership" which tells us that the Benchmark was unable to obtain reverse DNS lookups to determine their names from their IP addresses.

Something was up with your Internet connection which appears to have cleared up. If you reboot your PC and rerun the Benchmark I wonder whether that might resolve that lookup trouble?


#19

I

Info

Steve said:
@Info:

We can see from your bar chart that all of the server names are set at "Determining Ownership" which tells us that the Benchmark was unable to obtain reverse DNS lookups to determine their names from their IP addresses.

Something was up with your Internet connection which appears to have cleared up. If you reboot your PC and rerun the Benchmark I wonder whether that might resolve that lookup trouble?
Click to expand...
Hi Steve, thanks very much for all works DNSBench v2.

I successfully completed another round of testing on 45 servers running 10x - 100ms, which took 20 minutes to complete. I'm going to restart everything and expand the list a bit and see what happens.


DanR You were right, for some reason my ISP wasn't handling the large list of DNS servers well. I did another round of testing with approximately 45 servers, all ok. The results are attached.

DNS Benchmark Conclusions & Recommendations

What the results you have just obtained mean to YOU

The results summary, conclusions, and recommendations from your most recent run of this DNS benchmark are provided below. Please carefully consider the implications of making any changes to your system's current configuration before doing so.


þ Overall packet drop rate was 0.16% (108 packets).
The Internet is designed to drop packets. Dropped packets are not a problem, but they will delay DNS lookups while the system awaits their return. During the benchmarking, 69,791 DNS queries were sent and 69,683 DNS replies were received. This is a replies-to-queries ratio of 99.84%, which is reasonable for the Internet. However, since dropped packets reduce a resolver's effective performance while the system waits to see whether a resolver will reply, the Benchmark penalizes resolvers from which replies are not received by adding one second of total query-response time for every reply not received during the benchmark. This will reduce that resolver's final performance ranking and will be shown as “red” in the lefthand column.


þ System has multiple redundant nameservers configured.
This system is currently configured to use 2 separate nameservers for DNS name resolution. This is in keeping with recommended best practice (of having at least two different nameservers) so that the temporary failure of any single nameserver will not prevent all DNS name resolution.


þ All system nameservers are alive & replying to queries.
All of this system's 2 nameservers are working and replying to queries. This is terrific because if the system's primary nameserver were to become overloaded or unavailable, even briefly, one or more backup nameservers are standing by ready to supply DNS lookup services.


ý System nameservers are SLOWER than 1 public alternative!
This benchmark found 1 publicly available DNS nameserver that is statistically significantly faster than the slowest nameserver currently being used by this system. If you were to adjust your system's configuration to use this nameserver instead of what it is currently using, your DNS lookup performance, and all use of the Internet, would be improved.

The addresses of the 1 significantly faster publicly available DNS nameserver, listed in order of declining speed (the fastest is first), are:

1.0.0.1

Note: A total of 1 publicly available nameservers are on average faster than the slowest nameserver being used by this system, but the speed difference is only statistically significant for 1 of them shown above.

Recommended Actions:

⦁ With at least 95% certainty: Based upon a statistical analysis of the spread in timing value samples received during the benchmark, there is at least a 95% certainty that the performance conclusions stated above are correct. But even so, since changing DNS nameservers requires thought and effort, it's something you want to be sure about. Therefore, since these results represent a single snapshot in time, you may wish to confirm that the faster alternative nameservers are consistently faster than your system's currently configured nameservers, and that those public alternatives don't have any negative characteristics such as being colored orange to signify that they redirect mistaken URLs to an advertising-laden search page rather than returning an error (which will be a concern to some users).

⦁ You may also wish to check the relative performance at different times of day to make sure that the performance improvement over your system's current nameservers is reliable throughout the day.

⦁ And you may wish to make sure that the alternative nameservers are enough faster than what you are currently using for the improvement to be worth changing away from what you're currently using. (This test is only saying that it's 95% sure they are any amount faster.)


ý DNS queries to one or more system nameservers were lost.
DNS reliability is important because requests that are lost, dropped or ignored by resolvers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup resolvers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

During this benchmark test, replies from the DNS resolvers being tested were not received after they were sent.

So the question now is: Did the benchmark discover alternative resolvers having superior performance and reliability to which you could switch in order to obtain more performance and reliability?

Important Note:

⦁ Incorrect warnings of low reliability nameservers can arise if (1) DNS benchmarking is being performed while the local network is busy performing other work such as file downloading, or (2) the benchmark is running over a wireless (WiFi) link with low signal strength or high interference. Please try to minimize any other local network activity while the benchmark is running, and use a wired (not wireless) LAN connection if possible.

Recommended Actions:

⦁ Before you make any changes, please run the benchmark again and perhaps also a few more times at differing times of day to verify that the troubling reliability is an ongoing problem and not just a brief occurrence.

⦁ You may also wish to consult the “Tabular Data” page which summarizes all benchmark results in numeric tables. The numbers make it easier to see exactly how unreliable your system's nameservers are compared with the available alternatives. (And also how the alternatives' performance compares.)


þ All of this system nameservers return errors.
This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameservers are returning errors when asked to lookup non-existent domain names.


þ System nameservers are replying to all query types.
During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameservers are replying to these unusual but valid queries.
Click to expand...

Attachments


  • end10x100ms.png
    end10x100ms.png
    147 KB · Views: 173
  • end10x100msecc.png
    end10x100msecc.png
    145.5 KB · Views: 194

#20

I

Info

I've come to the conclusion that I can't have more than 60 DNS resolvers; more than that causes an error.

10x - 50msec - time 38min - 58 Resolvers DNS

DNS Benchmark Conclusions & Recommendations

What the results you have just obtained mean to YOU

The results summary, conclusions, and recommendations from your most recent run of this DNS benchmark are provided below. Please carefully consider the implications of making any changes to your system's current configuration before doing so.


þ Overall packet drop rate was 0.05% (39 packets).
The Internet is designed to drop packets. Dropped packets are not a problem, but they will delay DNS lookups while the system awaits their return. During the benchmarking, 95,922 DNS queries were sent and 95,883 DNS replies were received. This is a replies-to-queries ratio of 99.95%, which is reasonable for the Internet. However, since dropped packets reduce a resolver's effective performance while the system waits to see whether a resolver will reply, the Benchmark penalizes resolvers from which replies are not received by adding one second of total query-response time for every reply not received during the benchmark. This will reduce that resolver's final performance ranking and will be shown as “red” in the lefthand column.


þ System has multiple redundant nameservers configured.
This system is currently configured to use 2 separate nameservers for DNS name resolution. This is in keeping with recommended best practice (of having at least two different nameservers) so that the temporary failure of any single nameserver will not prevent all DNS name resolution.


þ All system nameservers are alive & replying to queries.
All of this system's 2 nameservers are working and replying to queries. This is terrific because if the system's primary nameserver were to become overloaded or unavailable, even briefly, one or more backup nameservers are standing by ready to supply DNS lookup services.


ý System nameservers are SLOWER than 12 public alternatives!
This benchmark found 12 publicly available DNS nameservers that are statistically significantly faster than the slowest nameserver currently being used by this system. If you were to adjust your system's configuration to use the faster of these nameservers instead of what it is currently using, your DNS lookup performance, and all use of the Internet, would be improved.

The addresses of the 12 significantly faster publicly available DNS nameservers, listed in order of declining speed (the fastest is first), are:

tls://security-filter-dns.cleanbrowsing.org
https://doh.cleanbrowsing.org/doh/security-filter/
9.9.9.11
https://dns9.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
tls://dns.google
https://dns10.quad9.net/dns-query
https://dns.quad9.net/dns-query
tls://anycast.dns.nextdns.io
https://dns.google/dns-query
https://dns.nextdns.io
tls://dns.nextdns.io

Note: A total of 13 publicly available nameservers are on average faster than the slowest nameserver being used by this system, but the speed difference is only statistically significant for 12 of them shown above.

Recommended Actions:

⦁ With at least 95% certainty: Based upon a statistical analysis of the spread in timing value samples received during the benchmark, there is at least a 95% certainty that the performance conclusions stated above are correct. But even so, since changing DNS nameservers requires thought and effort, it's something you want to be sure about. Therefore, since these results represent a single snapshot in time, you may wish to confirm that the faster alternative nameservers are consistently faster than your system's currently configured nameservers, and that those public alternatives don't have any negative characteristics such as being colored orange to signify that they redirect mistaken URLs to an advertising-laden search page rather than returning an error (which will be a concern to some users).

⦁ You may also wish to check the relative performance at different times of day to make sure that the performance improvement over your system's current nameservers is reliable throughout the day.

⦁ And you may wish to make sure that the alternative nameservers are enough faster than what you are currently using for the improvement to be worth changing away from what you're currently using. (This test is only saying that it's 95% sure they are any amount faster.)


ý DNS queries to one or more system nameservers were lost.
DNS reliability is important because requests that are lost, dropped or ignored by resolvers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup resolvers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

During this benchmark test, replies from the DNS resolvers being tested were not received after they were sent.

So the question now is: Did the benchmark discover alternative resolvers having superior performance and reliability to which you could switch in order to obtain more performance and reliability?

Important Note:

⦁ Incorrect warnings of low reliability nameservers can arise if (1) DNS benchmarking is being performed while the local network is busy performing other work such as file downloading, or (2) the benchmark is running over a wireless (WiFi) link with low signal strength or high interference. Please try to minimize any other local network activity while the benchmark is running, and use a wired (not wireless) LAN connection if possible.

Recommended Actions:

⦁ Before you make any changes, please run the benchmark again and perhaps also a few more times at differing times of day to verify that the troubling reliability is an ongoing problem and not just a brief occurrence.

⦁ You may also wish to consult the “Tabular Data” page which summarizes all benchmark results in numeric tables. The numbers make it easier to see exactly how unreliable your system's nameservers are compared with the available alternatives. (And also how the alternatives' performance compares.)


þ All of this system nameservers return errors.
This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameservers are returning errors when asked to lookup non-existent domain names.


þ System nameservers are replying to all query types.
During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameservers are replying to these unusual but valid queries.
Click to expand...

Attachments


  • 10x50msectubular.png
    10x50msectubular.png
    154.4 KB · Views: 149
  • 10x50msec.png
    10x50msec.png
    167.9 KB · Views: 207

#21

I

Info

Sorry, just a few questions:

First, I'd like to thank DeanR for the discovery. My ISP must have some limitation when many queries are made. Thanks to him, and with a maximum list of 60 resolvers, no more errors appear. Above 60 resolvers, I get a connection error.

Based on the results, the DNS server cleanbrowsing 185.228.168.9 is superior to the Quad9 9.9.9.9 that I currently use, correct?

A silly question: when I ping cleanbrowsing I get 7ms compared to 6ms for Quad.

When I do a tracert to cleanbrowsing I get 13 hops, compared to 11 for Quad.

Isn't this relevant? Or should I consider Short by cached Performance?

Best Regards,

Attachments


  • results.png
    results.png
    160.7 KB · Views: 174

#22

Steve

Steve

@Info: The black link shown in the bar chart is the average of the three DNS query types — Cached, Uncached and DotCom. That's probably what matters most. We see that you have some extremely fast (red) cached response times. That must be due to the extremely high quality of your Internet connection and good hardware that's getting the packets to and from your machine.

The (green) uncached response times are significantly longer, which is to be expected, since that represents the resolver you're querying needing to, in turn, query that other domain's resolver for its IP.

The original v1 DNS Benchmark would ONLY take the cached responses into consideration. That might have been the right thing to do 16 years ago. But the Internet is a far different place today with web pages being assembled from scores of different domains as ads and code libraries and (annoyingly) trackers are being referenced. So today's v2 Benchmark averages all three query types since they have become equally important.


#23

Steve

Steve

@Info: The “ping time” is probably very equivalent to the resolver's cached performance since most of the time will be spent with packets in transit. And we see exactly that in your DNSB chart. Quad9's ping response (the red bar) at 6ms is just a tiny bit shorter than the red bar for the CleanBrowsing at 7ms. (Pro Tip: If you LEFT-CLICK and hold on a resolver, you can directly read the timings for each of those bars and for the "black line" which is their average.)

But the reason the CleanBrowsing resolver might make more sense, is that Quad9 is slower (and a LOT slower for the dotcom queries) which means that anytime you ask for a domain name that Quad9 doesn't already have in its cache it needs to, in turn, ask other resolvers for the domain's IP address and we see that takes more time for Quad9 than for the CleanBrowsing resolver.

Now, in fairness, Quad9 might have a larger cache, or its popularity might mean that there's a greater likelihood that the domain you want to lookup is in its cache. At the moment there's no way to tell. Someday, I might tackle arranging to emit simultaneous queries to multiple resolvers so that real-world statistics could be obtained. But I have a few other goodies to create first!

Thanks again for your interest and support... And feel free to spread the word! (y)


#24

Steve

Steve

@Info:

One other thing I noted was that you had your Sideline Threshold set to 100msec. That would normally not be any problem. But in an instance where your ISP appears to be sensitive to the amount of DNS you're doing, setting a lower threshold — perhaps even 25msec — will allow DNSB to quickly and automatically disqualify slower resolvers to prevent their subsequent benchmarking. So you'll automatically wind up testing fewer resolvers and the ones you do test will be among the fastest.


#25

I

Info

Steve said:
@Info:

One other thing I noted was that you had your Sideline Threshold set to 100msec. That would normally not be any problem. But in an instance where your ISP appears to be sensitive to the amount of DNS you're doing, setting a lower threshold — perhaps even 25msec — will allow DNSB to quickly and automatically disqualify slower resolvers to prevent their subsequent benchmarking. So you'll automatically wind up testing fewer resolvers and the ones you do test will be among the fastest.
Click to expand...

@Steve
Everything is working now with my list, my limit is 60 DNS servers, I don't have any more problems.

Another round of testing, now with 50x - 50msec, took 2:30 hours.

Thank you, very happy with the result and all the work.

@DanR
Thank you for all your help and patience in helping me figure out my problem. There really was no need for a list of 287 resolvers; that was my problem. My ISP limit is 60.

Best Regards

Attachments


  • dns-20251207-115506.pdf
    96.6 KB · Views: 417
  • 50x50msec.png
    50x50msec.png
    129.5 KB · Views: 151

#26

D

DanR

Info said:
Thank you for all your help and patience in helping me figure out my problem. There really was no need for a list of 287 resolvers; that was my problem. My ISP limit is 60.
Click to expand...
You are very welcome! I'm glad that things are working well for you now.

I would suggest you consider building a Custom List. This process is very much more benign than a normal benchmark process. I would not expect your ISP to have any issue with it. When it is done, you will have a list of the 50 or so fastest resolvers available to you at your location, plus your system resolvers.

This will typically be a better list than the pruned down Built In list, which is not optimized for your location.

After a benchmark run or two, you may prune off the bottom 1/3 or so as too slow, or problematic, etc. The resulting list will benchmark very fast! :)


#27

I

Info

DanR said:
You are very welcome! I'm glad that things are working well for you now.

I would suggest you consider building a Custom List. This process is very much more benign than a normal benchmark process. I would not expect your ISP to have any issue with it. When it is done, you will have a list of the 50 or so fastest resolvers available to you at your location, plus your system resolvers.

This will typically be a better list than the pruned down Built In list, which is not optimized for your location.

After a benchmark run or two, you may prune off the bottom 1/3 or so as too slow, or problematic, etc. The resulting list will benchmark very fast! :)
Click to expand...

Could you tell me what the process of creating it would be like building a Custom List.?

I imagined it was just a matter of adding the desired DNS servers to DNSBench.ini.


#28

D

DanR

Info said:
Could you tell me what the process of creating it would be like building a Custom List.?

I imagined it was just a matter of adding the desired DNS servers to DNSBench.ini.
Click to expand...
Nope! It's much simpler than that. :)

Click the red icon in the UL corner of the DNSB main window to access the drop down main menu.

Almost halfway down there will be the item [Build Custom Nameserver List] - click it.

In the popup window you have one choice to make: Check [DNSSEC only]. Or not.

Then click [Build Custom List] - that's it! :)

DNSB downloads a data base of 4,909 resolvers from GRC and proceeds to do a quick speed test on each one from your location. It consistently takes 16 minutes for me at my location.

When it is done it will present you with the 50 or so fastest resolvers for your location. After benchmarking this list a time or two, too slow resolvers, unresponsive resolvers, etc. may be pruned from the list. The resulting shortened list will benchmark quite fast. :)

You may repeat this exercise as often as you wish.

Note: I have IPv6 disabled (no connectivity). This reduces the Custom Build list to 4,807 resolvers for me.


#29

I

Info

DanR said:
Nope! It's much simpler than that. :)

Click the red icon in the UL corner of the DNSB main window to access the drop down main menu.

Almost halfway down there will be the item [Build Custom Nameserver List] - click it.

In the popup window you have one choice to make: Check [DNSSEC only]. Or not.

Then click [Build Custom List] - that's it! :)

DNSB downloads a data base of 4,909 resolvers from GRC and proceeds to do a quick speed test on each one from your location. It consistently takes 16 minutes for me at my location.

When it is done it will present you with the 50 or so fastest resolvers for your location. After benchmarking this list a time or two, too slow resolvers, unresponsive resolvers, etc. may be pruned from the list. The resulting shortened list will benchmark quite fast. :)

You may repeat this exercise as often as you wish.

Note: I have IPv6 disabled (no connectivity). This reduces the Custom Build list to 4,807 resolvers for me.
Click to expand...
Thank you so much, I didn't realize that option existed, it worked too.


#30

johnawolf

johnawolf

Info said:
Hello everyone, I am very pleased to have acquired my DNSBench license, however I am experiencing the error below.

View attachment 1840


I'm running in standard 5x mode, I don't have IPv6 enabled, only IPv4.
Is there something I should do?

Best Regards,
Click to expand...
I am having the same issue and changing the various options does not seem to fix the issue. I changed the benchmark speed to 100ms and still no luck. I would note that v1 still works.


#31

D

DanR

johnawolf said:
I changed the benchmark speed to 100ms and still no luck.
Click to expand...
100 msec is too fast for your ISP. Does the default of 20 msec work?


#32

johnawolf

johnawolf

No, it does not I still get the "internet connectivity was lost while benchmarking" error. My Internet connection was not lost so I am not sure what the issue is. v1 of the benchmark still works.


#33

I

Info

johnawolf said:
No, it does not I still get the "internet connectivity was lost while benchmarking" error. My Internet connection was not lost so I am not sure what the issue is. v1 of the benchmark still works.
Click to expand...
Remove the resolvers to a maximum of 40 DNS servers; your provider shouldn't handle too many resolvers.


#34

D

DanR

@johnawolf What Info said! :)

And you might try Custom Build for resolvers optimized for your location. See my post above for instructions. :)


#35

I

Info

DanR said:
@johnawolf What Info said! :)

And you might try Custom Build for resolvers optimized for your location. See my post above for instructions. :)
Click to expand...

I created a custom build, it took 16 minutes, and even then I analyzed the list and chose to remove about 10. After having the customized list, I went ahead and tested it at 100x speed, and the result was what you see in the attachment.

Now I can remove the worst ones.

Attachments


  • Captura de tela 2025-12-09 070046.png
    Captura de tela 2025-12-09 070046.png
    132.8 KB · Views: 131
  • dns-20251209-095907.png
    dns-20251209-095907.png
    117.9 KB · Views: 160

#36

D

DanR

@johnawolf You might also try reducing the speed further to 150 or 200 msec. This means longer benchmark times, but if it keeps your ISP happy . . .
Note: Less msec is faster. In my first post to you my thinking was backwards. :(


#37

Steve

Steve

johnawolf said:
I am having the same issue and changing the various options does not seem to fix the issue. I changed the benchmark speed to 100ms and still no luck. I would note that v1 still works.
Click to expand...
Hi John.

During testing we discovered that some ISPs (and many VPNs) were throttling UDP or, in some cases, blocking it outright if they saw too much UDP DNS activity. However, it's suspicious that v1 is working without trouble for you.

Does the interruption notice appear immediately? Or after some time into the run of the benchmark? That screen shot you quoted as being the same as yours ( from @Info ) showed that only 2 resolver queries had been sent, thus an immediate loss notice. Are you really seeing the same?

Thanks!!


#38

johnawolf

johnawolf

Steve said:
Hi John.

During testing we discovered that some ISPs (and many VPNs) were throttling UDP or, in some cases, blocking it outright if they saw too much UDP DNS activity. However, it's suspicious that v1 is working without trouble for you.

Does the interruption notice appear immediately? Or after some time into the run of the benchmark? That screen shot you quoted as being the same as yours ( from @Info ) showed that only 2 resolver queries had been sent, thus an immediate loss notice. Are you really seeing the same?

Thanks!!
Click to expand...
Steve, with the default set up and most of the adjustments suggested it is popping up immediately. It will run (sort of) with the list pared down to 49 resolvers and the benchmark speed set to 200 ms. I say sort of because the pop up does not come up immediately and if you click ignore it will run for a bit before it comes up again, typically 10s of queries. Not very practical to babysit it through a full run.

v1 loads the names of the DNS servers (which v2 does not) and runs to conclusion with no errors. At the conclusion, it did report a high number of unreliable resolvers which I don't recall seeing before. FYI my ISP is Spectrum and my router is an Eero 6+ via wire without the Eero+ stuff active.

Any thoughts would be appreciated.


#39

I

Info

johnawolf said:
Steve, with the default set up and most of the adjustments suggested it is popping up immediately. It will run (sort of) with the list pared down to 49 resolvers and the benchmark speed set to 200 ms. I say sort of because the pop up does not come up immediately and if you click ignore it will run for a bit before it comes up again, typically 10s of queries. Not very practical to babysit it through a full run.

v1 loads the names of the DNS servers (which v2 does not) and runs to conclusion with no errors. At the conclusion, it did report a high number of unreliable resolvers which I don't recall seeing before. FYI my ISP is Spectrum and my router is an Eero 6+ via wire without the Eero+ stuff active.

Any thoughts would be appreciated.
Click to expand...
Please reduce the number of DNS resolvers to only 40 or 30 and test again, regardless of the time frame. Time is never a problem for me; the issue is the number of DNS servers.


#40

johnawolf

johnawolf

At 39 resolvers and 20 ms benchmark speed it appears to be working. However, it still lists the resolvers as ... determining ownership ... but at least it is running.


#41

Steve

Steve

johnawolf said:
At 39 resolvers and 20 ms benchmark speed it appears to be working. However, it still lists the resolvers as ... determining ownership ... but at least it is running.
Click to expand...
One of the biggest differences between v1 (which you've noted appears to not be having the problem) is that v1 is UDP-only whereas v2, of course, does UDP as well as two flavors of TLS queries.

So a worthwhile experiment (since you may not need DoH and DoT benchmarking side-by-side) would be to accept the offer to only benchmark UDP resolvers rather than all five flavors. (I don't know why this would be happening but it's the big difference between v1 and v2.)

The "...determining ownership..." is definitely odd. Your own local machine is handling those queries and it should be succeeding. Does the Name tab show the "reverse DNS" for your UDP (IP addressed) resolvers?


#42

I

Info

Steve said:
One of the biggest differences between v1 (which you've noted appears to not be having the problem) is that v1 is UDP-only whereas v2, of course, does UDP as well as two flavors of TLS queries.

So a worthwhile experiment (since you may not need DoH and DoT benchmarking side-by-side) would be to accept the offer to only benchmark UDP resolvers rather than all five flavors. (I don't know why this would be happening but it's the big difference between v1 and v2.)

The "...determining ownership..." is definitely odd. Your own local machine is handling those queries and it should be succeeding. Does the Name tab show the "reverse DNS" for your UDP (IP addressed) resolvers?
Click to expand...
But in my case, if I only allow UDP above 60 resolvers, I have the same problem. For me, the only solution was limiting it to 50 independent UDP DOH DNS servers; actually, I set my list to 48 DNS servers.

I also have the "...determining ownership..." problem, but honestly, it's not a big deal to me.

Below is a quick test: 5x 20 sec

Please note in the attached document that not all DNS entries show "...determining ownership..."; some are identified normally.

Steve, I think that with a large list of DNS servers, each DNS server would be a UDP connection on port 53, right? The more DNS servers, the greater the number of connections?

Just thinking about it, should the ISP limit the number of open connections? Sorry if I'm talking nonsense, I'm not an expert.

In any case, it wasn't a problem for me; I found my magic number of 48 servers and I don't see the need to have such a large list..

Attachments


  • Captura de tela 2025-12-09 180517.png
    Captura de tela 2025-12-09 180517.png
    200 KB · Views: 148
  • test.png
    test.png
    117.9 KB · Views: 138

#43

johnawolf

johnawolf

Steve said:
One of the biggest differences between v1 (which you've noted appears to not be having the problem) is that v1 is UDP-only whereas v2, of course, does UDP as well as two flavors of TLS queries.

So a worthwhile experiment (since you may not need DoH and DoT benchmarking side-by-side) would be to accept the offer to only benchmark UDP resolvers rather than all five flavors. (I don't know why this would be happening but it's the big difference between v1 and v2.)

The "...determining ownership..." is definitely odd. Your own local machine is handling those queries and it should be succeeding. Does the Name tab show the "reverse DNS" for your UDP (IP addressed) resolvers?
Click to expand...
FIXED: Ok, first thanks to Steve and gang for the suggestions to get v2 to run by lower the number of resolvers to under 40. That worked with all the other default settings, including getting the ...determining ownership... message to go away.

The final report indicated one of my five DNS resolvers was dead. Wait, 5!?! I only have 4 two IPv4s and two IPv6s for my two Pi-Holes. Five is not right. So, I opened terminal and ran ipconfig /all. Sure, enough there are four that should be there and a fifth one on the top of the list. It is an IPv6 address starting with 2600:. No idea where it came from or is coming from for that matter. It shows up on both Windows machines I checked. I don’t see it on my iOS devices or my Raspberry Pis.

The fifth “DNS Server” goes nowhere that I can see. It won’t respond to a ping and I have so far been unable to find it on my network. It obviously is not responding to DNS queries. I went and added the correct DNS resolvers manually to my Windows machine rather than depending on DHCP and that fixed v 2. It is running fine with all the default settings.

Off to find where this random DNS server is coming from.

Thanks again.


#44

D

DanR

@johnawolf

You really should do a Custom Build. See https://forums.grc.com/threads/dns-benchmark-v2-lost-connectivity.2272/page-2#post-16468

This will give you a short list of resolvers optimized for your location. These resolvers ought to perform much better for you than the trimmed Built In list you are currently using.


#45

johnawolf

johnawolf

Thanks Dan. The "trimmed" list was a custom build then trimmed to get it under 40. Now that I removed the random DNS entry I mentioned above, everything is working find and I created a new custom list. It completed fine as expected and I got good results. Thanks again for your help.


#46

peterblaise

peterblaise

"... should the ISP limit the number of open connections? ..."


Hahahaha - look at how many sub-references are called by almost any
web page, especially the big players like, Oh, I dunno, Amazon,
Facebook, and so on - all their page elements come from different
resources all over the web.

Just opening one web page, and hoping all page elements load and
present themselves, may take an incredible number of DNS calls.

Think: $

- - - - -

Q: Google, How many DNS queries are made by loading just one complex web page?

A: Loading a single complex web page can trigger numerous DNS queries, potentially ranging from a few dozen to hundreds.

The exact number is not fixed and depends on several factors:
  • Number of unique domains: Each unique domain from which resources (images, scripts, CSS files, fonts, third-party widgets, etc.) are loaded requires at least one DNS lookup to resolve its IP address. Complex pages often pull content from many different domains.
  • Caching: DNS queries are cached at various levels (browser, operating system, local DNS resolver). If a domain's IP address is already in a cache and its Time-To-Live (TTL) has not expired, a new DNS query for that domain will not be necessary.
  • IPv6 considerations: If a domain advertises both IPv4 and IPv6 records, loading a webpage might trigger additional DNS queries to resolve both record types, potentially doubling the number of queries compared to an IPv4-only scenario.
  • Third-party content: Social media buttons, analytics scripts, advertising networks, and other embedded third-party content can significantly increase the number of unique domains and, consequently, the number of DNS queries.
  • Page complexity and features: Pages with many images, videos, interactive elements, and modern web features (like Google Fonts) often rely on resources hosted on various domains, leading to more DNS lookups.
While a single DNS lookup involves a sequence of queries (recursive resolver, root server, TLD server, authoritative nameserver), the number of distinct DNS queries initiated by the client for a webpage corresponds to the number of unique domains whose IP addresses need to be resolved.


#47

Steve

Steve

johnawolf said:
Thanks Dan. The "trimmed" list was a custom build then trimmed to get it under 40. Now that I removed the random DNS entry I mentioned above, everything is working find and I created a new custom list. It completed fine as expected and I got good results. Thanks again for your help.
Click to expand...
We've all learned a very interesting lesson from your experience, John: DNSB discovered a non-functional resolver that your system really did have configured among its resolvers to use ... and that tripped up DNSB. I'm unsure what I might do about that ... but perhaps I ought to have the Benchmark notice that immediately, advice its user, and make an issue of it before proceeding?


#48

peterblaise

peterblaise

"... report indicated one of my five DNS resolvers was dead. Wait, 5!?! I only have 4 two IPv4s and two IPv6s for my two Pi-Holes. Five is not right. So, I opened terminal and ran ipconfig /all. Sure, enough there are four that should be there and a fifth one on the top of the list. It is an IPv6 address starting with 2600:. No idea where it came from ..."


Yes, yes, yes - I have been using DNSBench to troubleshoot my
"in here" networking, getting TLS versions up to snuff, getting IPv6
reliably connected, isolating wonky NICs and drivers, finding
under-performing switches, and so on, on my way to testing DNS
Nameserver resolvers "out there".

By DNSBench helping me troubleshoot my networking "in here",
and helped me troubleshoot my Internetting "out there", I see that ...

... DNSBench is two, two, two tools in one!

Thanks immeasurably, @Steve Gibson.

- - - - -

Q: Google, what IPv6 DNS Nameserver resolvers start with the primary prefix of 2600:?

A: The primary public IPv6 DNS nameserver resolvers that start with the prefix are operated by Cloudflare and Control D. [1, 2, 3]

The specific addresses are:
  • Cloudflare DNS:
    • 2606:4700:4700::1111
    • 2606:4700:4700::1001
  • Control D Free Uncensored:
    • 2606:1a40::
    • 2606:1a40:1:: [1, 2]
The address range is a global unicast address space assigned to the ARIN (American Registry for Internet Numbers) region. Various Internet Service Providers (ISPs) and organizations within this region use parts of this prefix for their services, including DNS resolution. [4]

[1] https://publicdns.neocities.org/ipv6-domain-name-servers
[2] https://www.lifewire.com/free-and-public-dns-servers-2626062
[3] https://hostman.com/tutorials/dns-configuration-for-ipv6/
[4] https://www.iana.org/assignments/ipv6-unicast-address-assignments


#49

Steve

Steve

peterblaise said:
Q: Google, what IPv6 DNS Nameserver resolvers start with the primary prefix of 2600:?
Click to expand...
It will be interesting to see what John learns of how his system was obtaining a bogus unresponsive resolver.


#50

johnawolf

johnawolf

Steve said:
It will be interesting to see what John learns of how his system was obtaining a bogus unresponsive resolver.
Click to expand...
The 2600 ipv6 address comes back to Charter Communications (my ISP) and the look ups put it in my town. I am not a DNS or DHCP expert by any means, but I assume Charter is pushing the address via DHCP for DNS and my router is passing it along to my Windows machines despite the custom DNS setting. If that is the case it is some crazy misconfiguration by Charter.


#51

Steve

Steve

Huh! THAT is interesting, indeed. I've assumed that switching to manual DNS configuration would prevent a machine from obtaining anything through DHCP!


#52

peterblaise

peterblaise

@Steve: "... I've assumed that switching to manual DNS configuration would prevent a machine from obtaining anything through DHCP ..."

I think the Comcast Business Router 2 also hijacks any DNS queries
anywhere anytime to it's own filtering and redirecting regardless of
manually entered Preferred and Alternate DNS Nameservers in our
NIC control panels.

( I'll confirm, but my suspicion is high. )


#53

peterblaise

peterblaise

Exploring some background:

@Info, your image shows IPv6 toggled off - was that intentional?

1765495444175.png


How did IPv6 get toggled off?

If you only have IPv4 through your ISP / router, can you compare the
results via DNSBench 1 using the same INI file?

https://www.grc.com/files/dnsb-free.exe <-- DNSBench 1

If you toggle IPv6 on, does Add/Remove, Add Defaults then show any
IPv6 resolvers coming in and looking live?

- - - - -

Note also, I use Scaling 100 msec to show my real working resolvers,
and Sideline 10 msec to really, really reduce wasting time on
resolvers I'm never going to select anyway - we each evolve our own
preferences.

Thanks.


#54

GreenWine

GreenWine

Just a small addition to this topic. When I am connected to ProtonVPN, I cannot complete even a quick benchmark without getting the error message the OP mentioned. Just a small 20ish list of nameservers and 1x round. I only accidentally tried this as I forgot to turn off the vpn.

I can see a usecase for benchmarking dns whilst using a vpn but personally, if I'm using a vpn I am expecting extra latency anyway. If you're one of those that uses a vpn full time, it certainly could be useful to find a closer ns to your vpn exit node, same for tor I guess.


#55

peterblaise

peterblaise

@GreenWine : "... When I am connected to ProtonVPN, I cannot complete even a quick benchmark without getting the error message the OP mentioned ..."

That error message during Benchmark is:

1765578571649.png


---------------------------​
Internet connectivity was lost while benchmarking:​
---------------------------​
It appears that this system's connection to the Internet​
has been lost, so the benchmark you were running has been​
suspended at the point of interruption.​
​
Since the connectivity outage may have been gradual rather​
than abrupt, the benchmark results obtained up to this point​
may have been distorted as the connection was failing.​
​
You may proceed in any of three ways:​
​
You may select "Abort" to cancel any further benchmarking,​
but retain the results accumulated up to the point of​
interruption (knowing that they may be distorted).​
​
You may select "Retry" to discard the interrupted benchmark​
and restart this DNS Benchmark program from the initial​
point of "Verifying Internet Access." (This is recommended.)​
​
You may select "Ignore" if connectivity has been restored​
and you wish to ignore the interruption and continue with​
the same interrupted benchmark.​
---------------------------​
Abort Retry Ignore​
---------------------------​

- - - - -

Note, for me, [ Ignore ] is the only functional response, and then, the
program carries on.

[ Abort ] and [ Retry ] seem to return to the program from the popup,
but the program does nothing.

Let's ALWAYS let us know what responses we proffer to the program
popups, and the resulting program behavior.

So, what do other people do and see when they do what they do?

Thanks.


Top Bottom
Back