DNS Benchmark V2 - Lost connectivity

[Info]

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

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

Best Regards,

 

[Info]

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

 

[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?

 

[Info]

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?

My home internet is fiber 600/300

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

 

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

 

[Info]

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.

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?

 

[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

 

[DanR]

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?

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.

 

[Info]

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.

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

 

[Info]

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

 

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

 

[Info]

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.

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,

 

[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?

 

[Info]

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

 

[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?

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

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?

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.

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

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.

 

[Steve]

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?

@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!

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.

 

[Info]

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.

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.

 

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

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?

 

[Info]

@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?

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.

 

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