Steve Gibson has finally released DNS Benchmark v2
https://www.grc.com/dns/benchmark.htm
It was going to be a tiered pricing depending on what features you wanted, but its now going for a one off payment. Original v1 is still available if you just want the free version.
Why would anyone want it? - Most people probably never look into their devices Primary and Secondary DNS server settings, and by default use their ISP DNS servers.
But if you set custom DNS servers this tool is useful to see how your DNS fairs against other available DNS Servers.
Personally I still use Quad9 (9.9.9.9) as Primary, and Cloudflares 1.1.1.1 as Secondary backup should Quad9 ever fail (it never does in my experience), which still compaires very well against a couple of other very slightly faster DNS Servers I could use .. instead of being routed through my ISP DNS servers, and being exploited by them selling on my online activity history for market research etcetera = parasitic ISP. I pay for a pipe to the internet and do not wish to be spied on by the provider, like farming human cattle with default DNS settings. So having my router set to use Custom DNS servers, means all devices in my house also bypass the ISP data hoover.
Your use case may vary ofc, but DNS Benchmark is brilliant, and nothing else does what it does.
Steve Gibson writes all of his code in assembler, so its very efficient, and always bug free (if not, anything missed by all of his testers but caught by the wider public soon after release will very soon be rectified and not need any further updates, he is excellent at coding his utilities).
Anyway I will stop blabbing, have a good read of its web page.
DNS Benchmark v2 - Released
Moderator: Moderators for English X Forum
-
alt3rn1ty
- Posts: 3925
- Joined: Thu, 26. Jan 06, 19:45

DNS Benchmark v2 - Released
Spec's@2025-05-17 - Laptop - Acer Predator Helios Neo 16 AI - Win 11
CPU - Intel Core Ultra 9 275HX 2.7-5.4ghz, RAM - 32gb DDR5 6400(OC),
Discrete GPU - NVidia Geforce RTX 5070 Ti, VRAM 12gb GDDR7,
SSD - M.2 PCIe NVME 1Tb, OLED WQXGA 2560x1600.
Seeker of Sohnen. Long live Queen Polypheides. 
>> Click me for X4 Forum Avatars <<
CPU - Intel Core Ultra 9 275HX 2.7-5.4ghz, RAM - 32gb DDR5 6400(OC),
Discrete GPU - NVidia Geforce RTX 5070 Ti, VRAM 12gb GDDR7,
SSD - M.2 PCIe NVME 1Tb, OLED WQXGA 2560x1600.
>> Click me for X4 Forum Avatars <<
-
alt3rn1ty
- Posts: 3925
- Joined: Thu, 26. Jan 06, 19:45

Re: DNS Benchmark v2 - Released
From Security Now! Podcast #1055 :
Steve Gibson talking about the release ..
Steve Gibson talking about the release ..
Spoiler
Show
I am extremely pleased and proud to announce that after almost exactly one year, GRC’s first new commercial product in several decades has been finished and is now available for purchase and download from GRC’s
website.
Everyone listening knows that this is the hugely improved commercial version of GRC’s most popular ever freeware, our DNS Benchmark. My original plan was to create a pair of commercial improvements to be called
“Plus” and “Pro”. But as the final new base edition kept evolving, there was less and less benefit to be had from a “Pro” edition. So I finally decided to give the base edition many of the features that had been slated for Pro, to have a single new DNS Benchmark called version 2, and to offer it with a lifetime one-time purchase license which entitles its owner to the entire future of the product, no matter what that may be, without ever paying anything more... for $9.95.
Looking back on the past year, that seems like a long time. But as I have mentioned previously, the original code had IPv4 so deeply designed into it back in 2008 that I actually had many false starts and retrenchments as I kept trying to find a way to add support for IPv6 and the two TLS DNS technologies DoH and DoT. I finally figured out how to do that and all four protocols now coexist perfectly.
The single biggest change to the Benchmarking since version 1 was released 16 years ago is that the Internet has changed so that uncached DNS lookups, rather than only cached lookups, have become important. 16 years ago, most of a webpage’s content was being served by the domain being visited. That meant that once the IP for its domain name was known, the page could be displayed with many additional fetches from the same domain and IP.
But these past 16 years have seen that dramatically change. When talking about things like uBlock Origin and other content-control utilities, we’ve noted that the content of today’s websites are being pulled from scores of disparate sources with pages pieced together from far and wide all across the Internet. This has significantly increased the importance of DNS lookups that are not cached... where other resolvers need to be consulted.
Because of the way things were back in 2008, version 1 of the DNS Benchmark used a strictly hierarchical resolver ranking algorithm. The first sort order was cached performance. It completely dominated all resolver ranking. Cached performance was the amount of time a resolver would need to reply to a query for a domain’s IP that it already knew and had cached locally. It turns out that Internet transit times so much dominate this, that cached performance is essentially equal to the time required to “ping” the resolver. While that might not seem like something worth knowing, it turns out that DNS performance is all about connectivity. What you want is a very good resolver that’s also very close. The problem was, that’s all that version 1 of the Benchmark took into consideration. If a resolver close by could beat out other resolvers, version 1 gave it the highest ranking. Only in the case of a tie in cached performance – within 1 millisecond of resolution – would uncached lookup performance be considered as the second sort key. The problem with that was that a resolver might reply to cached queries in 5 milliseconds but take ten times as long – 50 milliseconds – to perform a lookup of something it didn’t already know. Whereas another resolver might take 6 milliseconds to reply to a cached query but only 10 milliseconds to look up something it didn’t already know. I’d much rather be using that second resolver, since that first resolver’s extremely lengthy uncached lookup time is going to have a significant effect on the speed of today’s highly distributed webpage assembly.
And something else happened during the intervening 16 years. Back in 2008, no one had local border NAT routers that were also caching resolvers. We had NAT back then, but those early NAT routers were not doing DNS lookups for their LAN clients. When our PCs used DHCP to obtain their IPs they also received the IP addresses of the ISP’s supplied DNS resolvers. These days, many consumer grade NAT routers are running their own DNS, and our PCs receive the router’s IP for all DNS resolutions.
This matters because the original version of the DNS Benchmark would be seriously overimpressed by the performance of that local caching DNS resolver. How could any possible remote DNS resolver – no matter how fast it might be – possibly complete with the caching resolver sitting right there next to the user on their own LAN? Try pinging your LAN’s gateway and see how quickly it replies. And since the original benchmark’s ranking strategy was to prize caching performance above all else, the LAN’s caching resolver would always be placed at the top of the list, even if its uncached actual domain name lookup performance might be truly atrocious.
So what does the new version 2 of the DNS Benchmark do? It simply takes the average of all three types of DNS queries: cached, uncached, and dotcom resolver. Version 2 has four sorting options. The original cached-first sort is still there for anyone who wants it for some reason, but the new default is just called “Best” performance and that’s the default. What we found during the past year of testing is that, as I noted earlier, what matters most is the connectivity of DNS resolvers. IP packet roundtrip transit times are where the vast majority of time is spent. This means that a popular CDN’s big fast resolver which is nearby on the Internet can generally outperform someone’s own DNS resolver that takes a long time to lookup any IP it doesn’t already know.
As can be seen in the screen shot of the v2 DNS Benchmark on page 13, the performance bar chart still shows the original three bars, one for each query type. But it also shows a new thin black line to mark the average of those three, and resolvers are now ranked according to that line. I suspect that many owners of the version 2 benchmark will be able to significantly improve their network’s DNS lookup performance by studying the results of this modernized ranking. And, of course, for the first time we can gauge the relative performance of IPv6 resolvers versus IPv4 as well as the relative performance of the newer securely authenticated and snoop-proof encrypted DoH and DoT resolvers. DoT can be used natively by Android and DoH can be used natively by all of our web browsers. There’s no longer any reason for us to be vulnerable to ISPs profiling us by our DNS lookups.
The question then becomes, which of the hundreds of alternatives performs best for you? The reason there’s no single right answer for everyone is that, as we have found, it’s all about packet transit time, and that’s all about location. Or as they say about retail: “It’s location, location, location.” The new benchmark contains an updated built-in list of 126 possible IPv4 resolvers, 43 IPv6 resolvers, 81 DoH resolvers and 60 DoT resolvers. And on top of that, the Benchmark’s built-in custom list builder is also able to quickly scan through 4,909 possibly-faster resolvers.
Anyway, everyone gets the idea. I’m very proud of this latest work and I owe a debt of gratitude to the wonderful gang over in GRC’s DNS development newsgroup. Many of them offered great ideas, observations and suggestions that wound up improving the result measurably. We all get the benefit of their contributions. This GRC utility is offered for $9.95, a one-time fee which entitles its owner not only to use it forever, but also to any and all updates or upgrades, no matter what they may be throughout the rest of the product’s life. That’s a model that I think works to everyone’s benefit.
website.
Everyone listening knows that this is the hugely improved commercial version of GRC’s most popular ever freeware, our DNS Benchmark. My original plan was to create a pair of commercial improvements to be called
“Plus” and “Pro”. But as the final new base edition kept evolving, there was less and less benefit to be had from a “Pro” edition. So I finally decided to give the base edition many of the features that had been slated for Pro, to have a single new DNS Benchmark called version 2, and to offer it with a lifetime one-time purchase license which entitles its owner to the entire future of the product, no matter what that may be, without ever paying anything more... for $9.95.
Looking back on the past year, that seems like a long time. But as I have mentioned previously, the original code had IPv4 so deeply designed into it back in 2008 that I actually had many false starts and retrenchments as I kept trying to find a way to add support for IPv6 and the two TLS DNS technologies DoH and DoT. I finally figured out how to do that and all four protocols now coexist perfectly.
The single biggest change to the Benchmarking since version 1 was released 16 years ago is that the Internet has changed so that uncached DNS lookups, rather than only cached lookups, have become important. 16 years ago, most of a webpage’s content was being served by the domain being visited. That meant that once the IP for its domain name was known, the page could be displayed with many additional fetches from the same domain and IP.
But these past 16 years have seen that dramatically change. When talking about things like uBlock Origin and other content-control utilities, we’ve noted that the content of today’s websites are being pulled from scores of disparate sources with pages pieced together from far and wide all across the Internet. This has significantly increased the importance of DNS lookups that are not cached... where other resolvers need to be consulted.
Because of the way things were back in 2008, version 1 of the DNS Benchmark used a strictly hierarchical resolver ranking algorithm. The first sort order was cached performance. It completely dominated all resolver ranking. Cached performance was the amount of time a resolver would need to reply to a query for a domain’s IP that it already knew and had cached locally. It turns out that Internet transit times so much dominate this, that cached performance is essentially equal to the time required to “ping” the resolver. While that might not seem like something worth knowing, it turns out that DNS performance is all about connectivity. What you want is a very good resolver that’s also very close. The problem was, that’s all that version 1 of the Benchmark took into consideration. If a resolver close by could beat out other resolvers, version 1 gave it the highest ranking. Only in the case of a tie in cached performance – within 1 millisecond of resolution – would uncached lookup performance be considered as the second sort key. The problem with that was that a resolver might reply to cached queries in 5 milliseconds but take ten times as long – 50 milliseconds – to perform a lookup of something it didn’t already know. Whereas another resolver might take 6 milliseconds to reply to a cached query but only 10 milliseconds to look up something it didn’t already know. I’d much rather be using that second resolver, since that first resolver’s extremely lengthy uncached lookup time is going to have a significant effect on the speed of today’s highly distributed webpage assembly.
And something else happened during the intervening 16 years. Back in 2008, no one had local border NAT routers that were also caching resolvers. We had NAT back then, but those early NAT routers were not doing DNS lookups for their LAN clients. When our PCs used DHCP to obtain their IPs they also received the IP addresses of the ISP’s supplied DNS resolvers. These days, many consumer grade NAT routers are running their own DNS, and our PCs receive the router’s IP for all DNS resolutions.
This matters because the original version of the DNS Benchmark would be seriously overimpressed by the performance of that local caching DNS resolver. How could any possible remote DNS resolver – no matter how fast it might be – possibly complete with the caching resolver sitting right there next to the user on their own LAN? Try pinging your LAN’s gateway and see how quickly it replies. And since the original benchmark’s ranking strategy was to prize caching performance above all else, the LAN’s caching resolver would always be placed at the top of the list, even if its uncached actual domain name lookup performance might be truly atrocious.
So what does the new version 2 of the DNS Benchmark do? It simply takes the average of all three types of DNS queries: cached, uncached, and dotcom resolver. Version 2 has four sorting options. The original cached-first sort is still there for anyone who wants it for some reason, but the new default is just called “Best” performance and that’s the default. What we found during the past year of testing is that, as I noted earlier, what matters most is the connectivity of DNS resolvers. IP packet roundtrip transit times are where the vast majority of time is spent. This means that a popular CDN’s big fast resolver which is nearby on the Internet can generally outperform someone’s own DNS resolver that takes a long time to lookup any IP it doesn’t already know.
As can be seen in the screen shot of the v2 DNS Benchmark on page 13, the performance bar chart still shows the original three bars, one for each query type. But it also shows a new thin black line to mark the average of those three, and resolvers are now ranked according to that line. I suspect that many owners of the version 2 benchmark will be able to significantly improve their network’s DNS lookup performance by studying the results of this modernized ranking. And, of course, for the first time we can gauge the relative performance of IPv6 resolvers versus IPv4 as well as the relative performance of the newer securely authenticated and snoop-proof encrypted DoH and DoT resolvers. DoT can be used natively by Android and DoH can be used natively by all of our web browsers. There’s no longer any reason for us to be vulnerable to ISPs profiling us by our DNS lookups.
The question then becomes, which of the hundreds of alternatives performs best for you? The reason there’s no single right answer for everyone is that, as we have found, it’s all about packet transit time, and that’s all about location. Or as they say about retail: “It’s location, location, location.” The new benchmark contains an updated built-in list of 126 possible IPv4 resolvers, 43 IPv6 resolvers, 81 DoH resolvers and 60 DoT resolvers. And on top of that, the Benchmark’s built-in custom list builder is also able to quickly scan through 4,909 possibly-faster resolvers.
Anyway, everyone gets the idea. I’m very proud of this latest work and I owe a debt of gratitude to the wonderful gang over in GRC’s DNS development newsgroup. Many of them offered great ideas, observations and suggestions that wound up improving the result measurably. We all get the benefit of their contributions. This GRC utility is offered for $9.95, a one-time fee which entitles its owner not only to use it forever, but also to any and all updates or upgrades, no matter what they may be throughout the rest of the product’s life. That’s a model that I think works to everyone’s benefit.
Spec's@2025-05-17 - Laptop - Acer Predator Helios Neo 16 AI - Win 11
CPU - Intel Core Ultra 9 275HX 2.7-5.4ghz, RAM - 32gb DDR5 6400(OC),
Discrete GPU - NVidia Geforce RTX 5070 Ti, VRAM 12gb GDDR7,
SSD - M.2 PCIe NVME 1Tb, OLED WQXGA 2560x1600.
Seeker of Sohnen. Long live Queen Polypheides. 
>> Click me for X4 Forum Avatars <<
CPU - Intel Core Ultra 9 275HX 2.7-5.4ghz, RAM - 32gb DDR5 6400(OC),
Discrete GPU - NVidia Geforce RTX 5070 Ti, VRAM 12gb GDDR7,
SSD - M.2 PCIe NVME 1Tb, OLED WQXGA 2560x1600.
>> Click me for X4 Forum Avatars <<
