DNS seems to stop all of a sudden (Stubby w/NextDNS)

I have the Convexa-S running v3.104. I have NextDNS DoT using Stubby. It works fine until it doesn’t. All of a sudden the router stops resolving DNS queries sent by connected devices. When I check the NextDNS log I can see the router set the query but the devices on the network never actually receive the response.

It seems like the way to fix this is to go to > disable DNS over TLS from Cloudflare then re-enable it.

Anyone else facing similar issues?

#NOTE: See ‘/etc/stubby/stubby.yml.default’ for original config file and descriptions





tls_query_padding_blocksize: 128

edns_client_subnet_private : 0

round_robin_upstreams: 1

idle_timeout: 10000

timeout: 5000

tls_connection_retries: 5

tls_backoff_time: 300

dnssec_return_status: GETDNS_EXTENSION_TRUE


  • 0::1@53535


IPv6 addresses

# Cloudflare IPv6

# Cloudflare IPv6 secondary

# Quad 9 IPv6

- address_data: 2620:fe::10

tls_auth_name: “dns.quad9.net

IPv4 addresses

# Cloudflare servers

# Cloudflare servers secondary

Quad 9 service

- address_data:

tls_auth_name: “dns.quad9.net

Yes, my MV-1000W(firmware 3.105) with Stubby+NextDNS has the same issue as yours, my solution is SSH in with a “stubby restart” command to get it working again.

I still don’t know what happened to it.

Just turn “DNS rebind protection” off and NextDNS should be OK.

I have tried turning off “DNS rebind protection” on my MV-1000W and it still stop resolving from time to time. I still have no idea what happened.

Does it mean stopped and you have to enable it manually?

I am running nextdns for 2 weeks now and everything is fine.

I decided to try again to disable “DNS Rebind Protection” and also manually restarted Stubby and it works this time for at least 1 week now for my MV-1000W.

I also have a MT-1300(Beryl) running and have Stubby+NextDNS+“DNS Rebind Protection” turned on from the 1st day serving, it never goes wrong. That’s interesting for the same configuration combination but different result in different model. Maybe it’s because Beryl have newer firmware version ? (v3.200 vs v3.105) …hmmm

Someone said it is a stubby problem. But still don’t know why.

My MT-1300 Stubby stops working with “DNS Rebind Protection” turned on today, so this is confirmed a general issue around GL-iNET routers. :upside_down_face:

I’m a little late to the conversation here, but I think I’ve just run into this issue with my MT-1300 Beryl.

Are you guys saying turn off “DNS Rebinding Attack Protection” in the local router settings under “Custom DNS Server”? Or, turn off “DNS Rebinding Protection” in the NextDNS cloud configuration under the “Security” tab?

The one on the router.

Thanks for clarifying!

I just bought the Flint router and the same issue is happening for me as well :confused:

I seem to have this issue aswell, rebind protection is off both on the router and on the nextdns site, however wireguard is still on, and forcing the dns on clients aswell, adguard is off.

But it also doesn’t happen all the time for me sometimes I can run it a few days fine, other times the dns doesn’t lease it to the clients, for me a reboot of the router works fine, but I guess a stubby restart would be fine to as others have suggested.

Sometimes also my wifi goes down and this only happens when udhcpd is renewing the lease, it will no longer associate clients but I wonder if this issue could be also a part of this, like there is some kind delay so stubby or even the interface fails to get up, note that im also observing udhcpd lease failing errors but I guess that might be caused by myself since I made a routed AP via luci, and maybe stubby can act unstable when the wan connection got connection lost?

If I see anything happen again I could add my logs from kernel and system status, to me its very random.


I forgot to mentoin the firmware im using, the firmware is release 3.207 (1800ax flint).

Edit again:

I added the logs here with stripped mac addresses maybe its usefull and maybe not.

dns.zip (28.9 KB)