Intermittent loss of DNS resolution using DoH

Hello, I am using DoH with the luci app with dnsmasq. Since setting up DoH, I have noticed nearly daily loss of DNS resolution on all clients. It happens sometimes once every 2 days or sometimes several times a day, often for hours at a time. Most of the time a reboot fixes it. Restarting https_dns_proxy or dnsmasq doesn't solve the problem.

My router:
Model: TP-Link Archer A7 v5
FIrmware: OpenWrt SNAPSHOT r11582-b3779e920e / LuCI Master git-19.327.83508-5e1253f (recently updated to see if it fixed problem but it didn't)
Config: DHCP for all LAN clients, IPv6 disabled everywhere possible, adblock enabled, UPnP disabled

https_dns_proxy config (set via luci app, using cloudflare and



config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option nonwildcard '1'
        option localservice '1'
        option noresolv '1'
        list doh_backup_server ''
        list addnhosts '/tmp/adb_list.overall'
        option logqueries '1'
        option logdhcp '1'
        option logfacility '/tmp/dnsmasq.log'
        list server ''
        list server ''

When the DNS resolution fails, I can still use nslookup on the router via ssh since I don't have local DoH configured. But nslookup on clients times out: "nslookup
;; connection timed out; no servers could be reached"

However, since I can resolve on the router, I nslookup on the router to find the IP of a site, then I can ping that direct IP from the clients. So the issue is DNS related in my view. Direct IP address in the browser of clients can see pages.

Example output of /tmp/dnsmasq.log when DNS resolution is WORKING:

Nov 30 19:39:14 dnsmasq[2125]: 1505 query[A] from
Nov 30 19:39:14 dnsmasq[2125]: 1505 forwarded to
Nov 30 19:39:14 dnsmasq[2125]: 1505 forwarded to
Nov 30 19:39:14 dnsmasq[2125]: 1506 query[AAAA] from
Nov 30 19:39:14 dnsmasq[2125]: 1506 forwarded to
Nov 30 19:39:14 dnsmasq[2125]: 1505 reply is
Nov 30 19:39:14 dnsmasq[2125]: 1506 reply is 2a03:b0c0:3:d0::1af1:1

When it fails, I do not get the "reply" lines. Just the first 3 lines I think, the first query and the two forwards (I'd give example but not having the problem ATM).

Anyone have any ideas?

I think you have hit same problem I had just a while ago.

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        **option local '/lan/'**

Change line marked ** above to

        list local '/lan/'

Background: I have dnscrypt-proxy setup for my outbound DNS. A while ago I was moving internal name resolution to the same system. I did the changes to config on CLI with uci set command by copying lines to change from what uci show command listed. I found out that uci show does show list-items as option lines and uci set command set a list item to option item without any hick. Just later I found recommendation from UCI documentation to manually edit config and leave uci for scripted operations. Before I had the impression uci and manual configuration file edits are mostly equal and a belief that by using uci it may protect me better from config mistakes.

Thank you I will try that and see if the problem returns.

Also, change that to the non-DoH server to be used when DoH proxy is stopped.

Yes I will, I had thought that line looked out of place, seeing that the backup server was a redundant address already listed elsewhere. I can just put '' there, for example?

1 Like

To update: With the above changes made, I am having fewer issues. But I still have problems with https_dns_proxy. Whenever I tax the router and download near my ISP max speeds, the https_dns_proxy service either crashes or uses 100% memory. However, now I can recover without a reboot by restarting the service. If I know I am going to keep throughput on the router high, I keep it disabled until I'm done and just use normal DNS for the time being otherwise it just crashes/hangs the DoH service again.

Perhaps I can do some profiling or something on the service to see what it's hung up on?

Smells like a bug in https_dns_proxy. Still the question is, what is in your environment for https_dns_proxy, what makes it bug for you?

Do you have SQM setup for your uplink? If not, it may provide relief for https_dns_proxy.

Logs? Also, the https_dns_proxy has been retired for the newer https-dns-proxy which uses RFC8484 instead of JSON API, so it's pretty much all new code, I would try that.