DNS Benchmark V2 - Lost connectivity

[Steve]

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.

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?

 

[Info]

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?

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

 

[johnawolf]

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?

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.

 

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

 

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

 

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

 

[Steve]

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.

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?

 

[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

 

[Steve]

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

It will be interesting to see what John learns of how his system was obtaining a bogus unresponsive resolver.

 

[johnawolf]

It will be interesting to see what John learns of how his system was obtaining a bogus unresponsive resolver.

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.

 

[Steve]

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

 

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

 

[peterblaise]

Exploring some background:

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

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.

 

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

 

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

---------------------------​

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.