DNS-over-TLS taking too long RT-AC86U

[rickyd]

Many times during the day DNS will take too long, and I get a Server Not Found error in the browser, even for sites I'm accessing frequently. It's not just the browser, I'll get it in other apps like git-bash occasionally. I never had this problem before switching to DNS-over-TLS.
Attached is a screenshot of the DNS settings. Is there anything incorrect?

 

[dave14305]

Both Cloudflare and Quad9 will terminate idle TCP connections after about 10 seconds. Stubby will pre-emptively close idle connections after 9 seconds, but then have to recreate the TLS connection from scratch when the next DNS query comes in, and will rotate in a round-robin manner among your multiple DoT entries. Do you have IPv6 enabled on the router? If not, remove the IPv6 addresses.

Try picking Cloudflare or Quad9 and testing with only one provider, instead of 2, to narrow down if either one of them is causing your issues.

 

[rickyd]

> rotate in a round-robin manner among your multiple DoT entries
I thought it started with the first entry and failed over to the next if there was an error or the lookup didn't have the requested resource. I don't think that makes a difference, but it's good to know. Thanks.

 

[bbunge]

> rotate in a round-robin manner among your multiple DoT entries
I thought it started with the first entry and failed over to the next if there was an error or the lookup didn't have the requested resource. I don't think that makes a difference, but it's good to know. Thanks.

Not the way Stubby is configured by default. It can be configured without round-robin, however. If using Cloudflare the timeout in Stubby should be incresed but I never had issues with the default settings.
Quad9 can be problematic when doing DoT .
Use just one DNS upsream. Using Cloudflare and Quad9 can cause issues, as you have discovered.
If you do have IPV6 alternate the IPV4 and IPV6 addresses in the DoT setup.
If you want a fairly good filtering resolver use Cloudflare Security (1.1.1.2 and 1.0.0.2 security.cloudflare-dns.com)

 

[Tech9]

One filtered and one unfiltered upstream DNS service doesn't make sense indeed.

 

[PaddraighOS]

Yeah the others have nailed it, mixing Cloudflare and Quad9 over DoT is almost certainly your problem. Stubby on the AC86U rotates between all your entries and the TLS handshake overhead on each new connection adds up fast, especially if one provider is slower to respond than the other. I would stick with just Cloudflare for DoT honestly, their 1.1.1.1 infrastructure is hard to beat for raw speed. If you want to compare actual response times from different providers before committing, have a look at publicdns.info, it has a decent server comparison tool that shows latency from various locations. Should help you pick whichever one works best from where you are. Also worth checking if your ISP is doing any kind of traffic inspection on port 853 which is what DoT uses, some ISPs throttle or interfere with encrypted DNS and that can cause exactly the kind of intermittent timeouts you are seeing. Best of luck with it.

 

[PaddraighOS]

Just adding to what the lads above said - the idle timeout issue with Stubby is the likely culprit here. By default Stubby closes connections after 9 seconds idle, and then has to do a full TLS handshake from scratch on the next query. That handshake can take 200-500ms depending on latency to the resolver, and if the resolver is slow to respond you'll see those Server Not Found errors. Two things I'd try: first, stick with one provider only (Cloudflare 1.1.1.1 is generally the most responsive for DoT in my experience). Second, you can bump the idle_timeout in the Stubby config to something like 30000 (30 seconds) - that'll keep connections alive longer and avoid the constant reconnection. On Merlin you can edit /opt/etc/stubby/stubby.yml and change idle_timeout to 30000. Worth checking your actual latency to each resolver too - a quick dig @1.1.1.1 and dig @9.9.9.9 from the router's SSH will tell you which one responds faster from your location.

 

[PaddraighOS]

Testing reply

 

[dave14305]

you can bump the idle_timeout in the Stubby config to something like 30000 (30 seconds) - that'll keep connections alive longer and avoid the constant reconnection.

No, that's a bad idea. If Stubby doesn't close the connection at 9 seconds, Cloudflare will disconnect it after 10 seconds, and Stubby will see that as a conn_shut, and avoid using that server for the tls_backoff_time defined in stubby.yml. Better that stubby closes the connection and reopens it than to think it was forcibly disconnected and avoid using that upstream. Eventually you could run out of "valid" upstream servers and have no DNS.

 

[Tech9]

I would stick with just Cloudflare

I wouldn't.

Cloudflare outage on November 18, 2025

Cloudflare suffered a service outage on November 18, 2025. The outage was triggered by a bug in generation logic for a Bot Management feature file causing many Cloudflare services to be affected.

blog.cloudflare.com

Cloudflare outage on February 20, 2026

Cloudflare suffered a service outage on February 20, 2026. A subset of customers who use Cloudflare’s Bring Your Own IP (BYOIP) service saw their routes to the Internet withdrawn via Border Gateway Protocol (BGP).

blog.cloudflare.com

 

[ColinTaylor]

On Merlin you can edit /opt/etc/stubby/stubby.yml and ...

That is incorrect. /opt points to an external USB drive which contains Entware files. Merlin's Stubby is built into the firmware and the config file resides in /jffs.

 

[bbunge]

Modifications to Stubby in Merlin firmware are via stubby.postconf file.