Unbound Unbound and dnscheck results

[swejuggalo]

I decided to try out Unbound on two routers. Both starting to climb over 60% hits. Pretty much basic setup.
However, there is a major difference.
https://dnscheck.tools/ shows extreme different results.
They show drastically different ping.
The biggest difference is that AX88U don't use Diversion. But AX88U is the one that generally have the bigger workload.
They are running solo and have their own external IP.

Tried searching and digging but I can't really explain this behavior. It feels like I have no more things I can check to prove what could cause this.
It's in the area of being steady at approx 30 (AX88U) to peaking at 500 with lows on 200 ms (BE88U).

 

[swejuggalo]

Some testing.
OpenVPN seems to be a no go, if I want to use the router as DNS. Perhaps it's possible to fix somehow.
Built-in Wireguard - it's works. But DNS tests are slow. Only on BE88U.
Tailscale - works better, but I can't use the router as exit node. Then I'm one layer infront of any form of DNS options other than the basic DNS option of WAN DNS Setting (DoT options and Unbound are both bypassed).
According to my tests right now, Tailscale as a exit node that is connected to the router is faster than the exit node doing the same test

 

[Tech9]

Unbound will be always slower with test generating unique queries. None of them is cached, >100-200ms is expected. You know what Unbound does and how it works, correct?

 

[SomeWhereOverTheRainBow]

Unbound will be always slower with test generating unique queries. None of them is cached, >100-200ms is expected. You know what Unbound does and how it works, correct?

Even with some of the best dns servers the public has to offer the query time is still inside that range.

So I do not think that behavior is unique or exclusive to unbound. It is more so a behavior of any dns server performing those dnssec checks.

 

[swejuggalo]

Unbound will be always slower with test generating unique queries. None of them is cached, >100-200ms is expected. You know what Unbound does and how it works, correct?

But even when not cached, the big differences is interesting, right?

I know how to ssh into the router and check for example.
dig google.com @127.0.0.1
And see the different responses. But this is from the router perspective.

I'm also interested into testing how the full response time, google.com to the client and compare that. For no other reason than fun.

 

[Tech9]

If you are trying to compete with Google, Cloudflare, OpenDNS, etc. - you have no chance.

 

[swejuggalo]

If you are trying to compete with Google, Cloudflare, OpenDNS, etc. - you have no chance.

Not competing. Just wonder why router 1 has like 33 while router 2 has like 450 when testing. Especially when router 2 is the more powerful one.

 

[Twiglets]

I am confused with understanding what your problem is and what you are expecting as a proof that your problem has been solved.

As mentioned Unbound is a validating, recursive, caching DNS resolver, to quote NLnet Labs, what do you want it to do that it is not doing now ?

Low level numbers in the milliseconds do not translate to any appreciable delay or lag in using Browsers etc

Perhaps if you could define what your problem is better it would help people to answer your questions.

 

[dave14305]

I don't put much weight on the RTT time shown on dnscheck.tools. It's trying to perform HTTPS requests to random URLs that are designed to return 0.0.0.0 responses. Firefox seems to block those requests anyway, so not sure how reliable the results are compared to what was intended. It looks nice on the page, but you're better off checking unbound stats with unbound-control stats_noreset

addr.tools/website/dnscheck.tools/main.js at 94b0bc80273a7d2567199c2e3c2e9784067d3c35 · brianshea2/addr.tools

possibly useful tools for the Internet. Contribute to brianshea2/addr.tools development by creating an account on GitHub.

github.com

 

[Twiglets]

"Just wonder why router 1 has like 33 while router 2 has like 450 when testing. Especially when router 2 is the more powerful one."

To answer the question regarding the 'numbers' quoted, a faster or more powerful router does not directly impact the speed of the DNS queries once they are travelling over the internet.

A more powerful router is usually needed to handle a higher number of users concurrently and/or to provide more services concurrently.

The power of the router impacts any processing that may be needed for all the services that the router provides BUT during the DNS query you are mostly waiting for external servers unless your query can be answered from the cache.

I expect you could measure the difference between routers if the volume of requests was very high and they were running identical 'lots of other things' at the same time.

The volume of other traffic while you are making the DNS requests has an impact IF the traffic is maxing out the WAN but that would be obvious to you at the time you are running the tests.

 

[SomeWhereOverTheRainBow]

I don't put much weight on the RTT time shown on dnscheck.tools. It's trying to perform HTTPS requests to random URLs that are designed to return 0.0.0.0 responses. Firefox seems to block those requests anyway, so not sure how reliable the results are compared to what was intended. It looks nice on the page, but you're better off checking unbound stats with unbound-control stats_noreset

addr.tools/website/dnscheck.tools/main.js at 94b0bc80273a7d2567199c2e3c2e9784067d3c35 · brianshea2/addr.tools

possibly useful tools for the Internet. Contribute to brianshea2/addr.tools development by creating an account on GitHub.

github.com

I am confused with understanding what your problem is and what you are expecting as a proof that your problem has been solved.

As mentioned Unbound is a validating, recursive, caching DNS resolver, to quote NLnet Labs, what do you want it to do that it is not doing now ?

Low level numbers in the milliseconds do not translate to any appreciable delay or lag in using Browsers etc

Perhaps if you could define what your problem is better it would help people to answer your questions.

I was able to get my local recursive unbound instance to perform the test in 169ms which came out to be roughly 16 ms more than using encrypted upstream resolvers. I can't say that there is any particular issue at all here. The only thing I could possibly entertain is maybe the OP lives in a very isolated region with very few if any nearby servers. IMO the fact that unbound is able to resolve anything in those conditions is a testament of its versatility.

 

[Tech9]

The tool in Post #1 to OpenDNS:

The actual latency is under 4ms. OpenDNS have a server in my city.

Not sure why you guys run Unbound, but major providers are killing it in performance.

Privacy... I know.

 

[swejuggalo]

I am confused with understanding what your problem is and what you are expecting as a proof that your problem has been solved.

As mentioned Unbound is a validating, recursive, caching DNS resolver, to quote NLnet Labs, what do you want it to do that it is not doing now ?

Low level numbers in the milliseconds do not translate to any appreciable delay or lag in using Browsers etc

Perhaps if you could define what your problem is better it would help people to answer your questions.

The "slow" router is the one that does the very least things, traffic wise, with mainly the addition of Diversion as the main difference.
"Outside" of Unbound with normal 1.1.1.1 DNS both are identical down to the micro differences. But with Unbound the random tests were consistently huge in difference, up until now where both seems fairly even.
I can accept that both a fairly slow in this test, but if the difference is 10x+ bigger on one, that makes me wonder.

The tool in Post #1 to OpenDNS:

View attachment 67644

The actual latency is under 4ms. OpenDNS have a server in my city.

Not sure why you guys run Unbound, but major providers are killing it in performance.

View attachment 67645

Privacy... I know.

For me, it's mainly for fun, and see what it can do for me. For me, Cloudflare is usually the clear winner for pure speed. Live in Sweden and their closest servers are in Denmark.

I don't put much weight on the RTT time shown on dnscheck.tools. It's trying to perform HTTPS requests to random URLs that are designed to return 0.0.0.0 responses. Firefox seems to block those requests anyway, so not sure how reliable the results are compared to what was intended. It looks nice on the page, but you're better off checking unbound stats with unbound-control stats_noreset

addr.tools/website/dnscheck.tools/main.js at 94b0bc80273a7d2567199c2e3c2e9784067d3c35 · brianshea2/addr.tools

possibly useful tools for the Internet. Contribute to brianshea2/addr.tools development by creating an account on GitHub.

github.com

Great will do. The huge differences just made me wonder what happened, since I could not find a logical reason. I was after all 10x+ worse values.