Can't Access or Address Some Sites (Twitch / Steam / Discord Clients) w/ Unbound Installed

etherb0x · November 9, 2020, 4:51am

Hi all, apologies if this is either too niche or broad for this forum.

I've installed and configured Unbound in combination with odhcdp to enable DNS over TLS, in addition to adblock, mostly following OpenWRT installation guides with a few extra troubleshooting steps here and there. I've got DNS over TLS checked (tls-upstream) and am using cloudflare-dns.com as a certificate verifier, with 10.8.8.1, 1.1.1.1, 1.0.0.1 setup in the zone file.

Most of my online experience is working totally fine, but a few services like local (Windows) clients for Twitch, Discord and Steam all refuse to connect to the internet unless I additionally connect my VPN client. Running a successul OpenVPN connection to this same service on the router doesn't fix it, it needs to be via ProtonVPN's Windows client.

So I'm suspecting it's a DNS issue, and would need to be resolved at the level of Unbound.

Here's some dig output which might make the problem clearer:

root@OpenWrt:~# dig cloudflare.com

; <<>> DiG 9.16.8 <<>> cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17461
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;cloudflare.com.                        IN      A

;; ANSWER SECTION:
cloudflare.com.         294     IN      A       104.16.133.229
cloudflare.com.         294     IN      A       104.16.132.229

;; Query time: 219 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 09 03:59:38 UTC 2020
;; MSG SIZE  rcvd: 75

root@OpenWrt:~# dig discord.com

; <<>> DiG 9.16.8 <<>> discord.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18728
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;discord.com.                   IN      A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 09 03:59:40 UTC 2020
;; MSG SIZE  rcvd: 40

I'm at a loss as to how to fix this.

I've tried disabling DNS over TLS, disabling DNSSEC, replacing the servers in the zone file with Google's, and a host of other things.

It's worth mentioning that 10.8.8.1 / 1.1.1.1 is what ProtonVPN (my VPN provider) instructs users to use as their DNS field in OpenVPN configurations; i.e. it would seem they use Cloudflare as part of their DNS resolution as well. So I'm extra confused as to why these services aren't addressable when I've got an OpenVPN connection established.

Hope you can point me in the right direction!

Edit: Just on a whim, noticing that I have an IPV6 lease assigned to my router (though I have never been able to get Unbound to work with Cloudflare's IPV6 servers without errors on port 843), I turned up this thread on Discord: https://support.discord.com/hc/en-us/community/posts/360047840052-Add-IPv6-support. Is it possible that using only IPV4 servers with Unbound could cause these sorts of connection issues?

vgaetera · November 9, 2020, 6:01am

Post the output:

netstat -l -n -p | grep -e dnsmasq -e unbound; \
head -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*; \
uci show dhcp; uci show unbound

etherb0x · November 9, 2020, 5:53pm

Thanks so much for the fast response! Here's the output:

root@OpenWrt:~# netstat -l -n -p | grep -e dnsmasq -e unbound; \
> head -n -0 /etc/resolv.* /tmp/resolv.* /tmp/resolv.*/*; \
> uci show dhcp; uci show unbound
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      9817/unbound
tcp        0      0 127.0.0.1:8953          0.0.0.0:*               LISTEN      9817/unbound
tcp        0      0 ::1:8953                :::*                    LISTEN      9817/unbound
udp        0      0 0.0.0.0:53              0.0.0.0:*                           9817/unbound
==> /etc/resolv.conf <==
# /tmp/resolv.conf generated by Unbound UCI 2020-11-09T04:58:58+0000
nameserver 127.0.0.1
nameserver ::1
search lan.

==> /tmp/resolv.conf <==
# /tmp/resolv.conf generated by Unbound UCI 2020-11-09T04:58:58+0000
nameserver 127.0.0.1
nameserver ::1
search lan.

==> /tmp/resolv.conf.auto <==
# Interface wan
nameserver 64.59.144.100
nameserver 64.59.150.143
search vc.shawcable.net
# Interface wan6
nameserver 2001:4e8:0:4009::15
nameserver 2001:4e8:0:4007::1a
head: /tmp/resolv.*/*: No such file or directory
dhcp.lan=dhcp
dhcp.lan.interface='lan'
dhcp.lan.start='100'
dhcp.lan.limit='150'
dhcp.lan.leasetime='12h'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.dhcpv4='server'
dhcp.lan.ra_management='1'
dhcp.wan=dhcp
dhcp.wan.interface='wan'
dhcp.wan.ignore='1'
dhcp.odhcpd=odhcpd
dhcp.odhcpd.leasefile='/tmp/hosts/odhcpd'
dhcp.odhcpd.leasetrigger='/usr/lib/unbound/odhcpd.sh'
dhcp.odhcpd.loglevel='4'
dhcp.odhcpd.maindhcp='1'
unbound.@unbound[0]=unbound
unbound.@unbound[0].add_extra_dns='0'
unbound.@unbound[0].add_local_fqdn='1'
unbound.@unbound[0].add_wan_fqdn='0'
unbound.@unbound[0].dns64='0'
unbound.@unbound[0].domain='lan'
unbound.@unbound[0].domain_type='static'
unbound.@unbound[0].edns_size='1280'
unbound.@unbound[0].hide_binddata='1'
unbound.@unbound[0].interface_auto='1'
unbound.@unbound[0].listen_port='53'
unbound.@unbound[0].manual_conf='0'
unbound.@unbound[0].num_threads='1'
unbound.@unbound[0].rate_limit='0'
unbound.@unbound[0].rebind_localhost='0'
unbound.@unbound[0].rebind_protection='1'
unbound.@unbound[0].recursion='default'
unbound.@unbound[0].resource='default'
unbound.@unbound[0].root_age='9'
unbound.@unbound[0].ttl_min='120'
unbound.@unbound[0].verbosity='1'
unbound.@unbound[0].enabled='1'
unbound.@unbound[0].dhcp_link='odhcpd'
unbound.@unbound[0].unbound_control='2'
unbound.@unbound[0].extended_stats='1'
unbound.@unbound[0].localservice='1'
unbound.@unbound[0].validator='1'
unbound.@unbound[0].validator_ntp='1'
unbound.@unbound[0].protocol='ip4_only'
unbound.@unbound[0].trigger_interface='lan' 'wan'
unbound.forward=zone
unbound.forward.enabled='1'
unbound.forward.fallback='0'
unbound.forward.zone_type='forward_zone'
unbound.forward.zone_name='.'
unbound.forward.dns_assist='none'
unbound.forward.tls_upstream='1'
unbound.forward.tls_index='cloudflare-dns.com'
unbound.forward.server='2606:4700:4700::1111' '2606:4700:4700::1000' '10.8.8.1' '1.1.1.1' '1.0.0.1'

vgaetera · November 10, 2020, 3:47am

Establish the VPN connection and check the output:

ubus call system board; \
for DNS in 127.0.0.1 ::1 10.8.1.1 1.1.1.1 2606:4700:4700::1111 8.8.8.8 2001:4860:4860::8888; \
do for OPT in "" +tcp +notcp; \
do echo ${DNS}:${OPT}:$(dig @${DNS} -q discord.com +short ${OPT}); \
done; done

Check if the issue persists when you try the following:

Remove 10.8.1.1 from the list of servers.
Use only Cloudflare DNS + DoT.
Use only Google DNS + DoT.

etherb0x · November 10, 2020, 5:44am

I had a DNS entry mistyped as 10.8.1.1 when it should have been 10.8.8.1. Yikes.

Anyways, I almost declared victory but it seems like it's working very intermittently, so I don't think it's actually due to one of the DNS providers but perhaps something to do with Unbound. I have been able to connect to both Discord.com and Twitch.tv successfully using all combinations of Cloudflare + DoT, Google + DoT, and either of those + the ProtonVPN DNS server (10.8.8.1).

Sometimes, Discord works, but Twitch doesn't.
Sometimes, they both don't work.
There's never been a time where Twitch works and Discord doesn't.

I restarted the router between each DNS table change. Could there be an unbound DNS cache that's getting cleared and is built locally and is therefore throwing up errors after restarts? I know I'm talking crazy, just throwing it out there.

While it was working

Here's it while working with full Cloudflare plus the ProtonVPN DNS (10.8.8.1)

root@OpenWrt:~# ubus call system board; \
> for DNS in 127.0.0.1 ::1 10.8.8.1 1.1.1.1 2606:4700:4700::1111 8.8.8.
8 2001:4860:4860::8888; \
> do for OPT in "" +tcp +notcp; \
> do echo ${DNS}:${OPT}:$(dig @${DNS} -q discord.com +short ${OPT}); \
> done; done
{
        "kernel": "4.14.195",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 1 (v7l)",
        "model": "Linksys WRT3200ACM",
        "board_name": "linksys,rango",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.4",
                "revision": "r11208-ce6496d796",
                "target": "mvebu/cortexa9",
                "description": "OpenWrt 19.07.4 r11208-ce6496d796"
        }
}
127.0.0.1::162.159.128.233 162.159.138.232 162.159.136.232 162.159.135.232 162.159.137.232
127.0.0.1:+tcp:162.159.136.232 162.159.135.232 162.159.137.232 162.159.128.233 162.159.138.232
127.0.0.1:+notcp:162.159.138.232 162.159.136.232 162.159.135.232 162.159.137.232 162.159.128.233
::1:: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
::1:+tcp:;; Connection to ::1#53(::1) for discord.com failed: connection refused.
::1:+notcp: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short +notcp ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
10.8.8.1::162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+tcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+notcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
1.1.1.1::162.159.136.232 162.159.137.232 162.159.128.233 162.159.135.232 162.159.138.232
1.1.1.1:+tcp:162.159.136.232 162.159.137.232 162.159.138.232 162.159.128.233 162.159.135.232
1.1.1.1:+notcp:162.159.138.232 162.159.137.232 162.159.136.232 162.159.135.232 162.159.128.233
2606:4700:4700::1111::162.159.138.232 162.159.137.232 162.159.128.233 162.159.136.232 162.159.135.232
2606:4700:4700::1111:+tcp:162.159.128.233 162.159.138.232 162.159.136.232 162.159.135.232 162.159.137.232
2606:4700:4700::1111:+notcp:162.159.136.232 162.159.128.233 162.159.135.232 162.159.138.232 162.159.137.232
8.8.8.8::162.159.136.232 162.159.137.232 162.159.138.232 162.159.135.232 162.159.128.233
8.8.8.8:+tcp:162.159.136.232 162.159.137.232 162.159.138.232 162.159.135.232 162.159.128.233
8.8.8.8:+notcp:162.159.135.232 162.159.128.233 162.159.138.232 162.159.136.232 162.159.137.232
2001:4860:4860::8888::162.159.135.232 162.159.136.232 162.159.137.232 162.159.128.233 162.159.138.232
2001:4860:4860::8888:+tcp:162.159.136.232 162.159.138.232 162.159.128.233 162.159.135.232 162.159.137.232
2001:4860:4860::8888:+notcp:162.159.128.233 162.159.137.232 162.159.135.232 162.159.136.232 162.159.138.232

While it was NOT working

Here's a call to Twitch.tv during one of the times it was failing (using Cloudflare):

root@OpenWrt:~# ubus call system board; \
> for DNS in 127.0.0.1 ::1 10.8.8.1 1.1.1.1 2606:4700:4700::1111 8.8.8.
8 2001:4860:4860::8888; \
> do for OPT in "" +tcp +notcp; \
> do echo ${DNS}:${OPT}:$(dig @${DNS} -q twitch.tv +short ${OPT}); \
> done; done
{
        "kernel": "4.14.195",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 1 (v7l)",
        "model": "Linksys WRT3200ACM",
        "board_name": "linksys,rango",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.4",
                "revision": "r11208-ce6496d796",
                "target": "mvebu/cortexa9",
                "description": "OpenWrt 19.07.4 r11208-ce6496d796"
        }
}
127.0.0.1::
127.0.0.1:+tcp:
127.0.0.1:+notcp:
::1:: ; <<>> DiG 9.16.8 <<>> @::1 -q twitch.tv +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
::1:+tcp:;; Connection to ::1#53(::1) for twitch.tv failed: connection refused.
::1:+notcp: ; <<>> DiG 9.16.8 <<>> @::1 -q twitch.tv +short +notcp ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
10.8.8.1::151.101.2.167 151.101.66.167 151.101.130.167 151.101.194.167
10.8.8.1:+tcp:151.101.2.167 151.101.66.167 151.101.130.167 151.101.194.167
10.8.8.1:+notcp:151.101.2.167 151.101.66.167 151.101.130.167 151.101.194.167
1.1.1.1::151.101.194.167 151.101.2.167 151.101.66.167 151.101.130.167
1.1.1.1:+tcp:151.101.194.167 151.101.66.167 151.101.130.167 151.101.2.167
1.1.1.1:+notcp:151.101.2.167 151.101.66.167 151.101.194.167 151.101.130.167
2606:4700:4700::1111::151.101.130.167 151.101.194.167 151.101.66.167 151.101.2.167
2606:4700:4700::1111:+tcp:151.101.66.167 151.101.194.167 151.101.2.167 151.101.130.167
2606:4700:4700::1111:+notcp:151.101.2.167 151.101.66.167 151.101.194.167 151.101.130.167
8.8.8.8::151.101.194.167 151.101.66.167 151.101.2.167 151.101.130.167
8.8.8.8:+tcp:151.101.66.167 151.101.130.167 151.101.194.167 151.101.2.167
8.8.8.8:+notcp:151.101.194.167 151.101.130.167 151.101.2.167 151.101.66.167
2001:4860:4860::8888::151.101.194.167 151.101.130.167 151.101.2.167 151.101.66.167
2001:4860:4860::8888:+tcp:151.101.66.167 151.101.2.167 151.101.194.167 151.101.130.167
2001:4860:4860::8888:+notcp:151.101.130.167 151.101.2.167 151.101.194.167 151.101.66.167

Here's a call to Discord while it was failing (Cloudflare + 10.8.8.1):

root@OpenWrt:~# ubus call system board; \
> for DNS in 127.0.0.1 ::1 10.8.8.1 1.1.1.1 2606:4700:4700::1111 8.8.8.
8 2001:4860:4860::8888; \
> do for OPT in "" +tcp +notcp; \
> do echo ${DNS}:${OPT}:$(dig @${DNS} -q discord.com +short ${OPT}); \
> done; done
{
        "kernel": "4.14.195",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 1 (v7l)",
        "model": "Linksys WRT3200ACM",
        "board_name": "linksys,rango",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.4",
                "revision": "r11208-ce6496d796",
                "target": "mvebu/cortexa9",
                "description": "OpenWrt 19.07.4 r11208-ce6496d796"
        }
}
127.0.0.1::
127.0.0.1:+tcp:
127.0.0.1:+notcp:
::1:: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
::1:+tcp:;; Connection to ::1#53(::1) for discord.com failed: connection refused.
::1:+notcp: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short +notcp ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
10.8.8.1::162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+tcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+notcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
1.1.1.1::162.159.135.232 162.159.138.232 162.159.137.232 162.159.128.233 162.159.136.232
1.1.1.1:+tcp:162.159.136.232 162.159.135.232 162.159.128.233 162.159.138.232 162.159.137.232
1.1.1.1:+notcp:162.159.137.232 162.159.136.232 162.159.128.233 162.159.135.232 162.159.138.232
2606:4700:4700::1111::162.159.136.232 162.159.135.232 162.159.138.232 162.159.137.232 162.159.128.233
2606:4700:4700::1111:+tcp:162.159.128.233 162.159.138.232 162.159.135.232 162.159.137.232 162.159.136.232
2606:4700:4700::1111:+notcp:162.159.135.232 162.159.137.232 162.159.136.232 162.159.128.233 162.159.138.232
8.8.8.8::162.159.128.233 162.159.138.232 162.159.135.232 162.159.136.232 162.159.137.232
8.8.8.8:+tcp:162.159.136.232 162.159.138.232 162.159.128.233 162.159.135.232 162.159.137.232
8.8.8.8:+notcp:162.159.128.233 162.159.138.232 162.159.137.232 162.159.135.232 162.159.136.232
2001:4860:4860::8888::162.159.138.232 162.159.135.232 162.159.128.233 162.159.136.232 162.159.137.232
2001:4860:4860::8888:+tcp:162.159.136.232 162.159.135.232 162.159.128.233 162.159.137.232 162.159.138.232
2001:4860:4860::8888:+notcp:162.159.136.232 162.159.138.232 162.159.137.232 162.159.135.232 162.159.128.233
root@OpenWrt:~#

It's interesting that during the times when it's working okay, the 127.0.0.1 dig call goes through successfully. It's sometimes failing. Is that a local unbound DNS cache that's getting reset or something? Could it have anything to do with bootup order between Unbound and OpenVPN?

I'm also just going to attach this image of the Directed Zone config page in case any of these options look suspicious. As I write this, I have just restarted the router with this configuration and Discord is working but Twitch isn't.

Sorry that this is such a can of worms. I'll get in contact with ProtonVPN as well, but I'm just not sure whose side the issue's on.

vgaetera · November 10, 2020, 8:12am

Try to disable DNSSEC as it is known to be problematic in many cases:

uci set unbound.@unbound[0].validator="0"
uci commit unbound
/etc/init.d/unbound restart

etherb0x · November 10, 2020, 8:42pm

Disabled DNSSEC. As well, I realized that the VPN profiles I was using were for TCP but I had the provider's UDP DNS server slotted in.

Here's the output of the dual stack connectivity question you had asked previously as well:

root@OpenWrt:~# ip route get 1::; ip route get 1
RTNETLINK answers: Permission denied
1.0.0.0 via 10.17.0.1 dev tun0 src 10.17.0.21 uid 0
    cache
root@OpenWrt:~#

This AM after unchecking DNSSEC it was good and holding steady for about 25min, even while switching OpenVPN connections. I thought I had it beat.

Then while queueing up one or two large downloads, I decided to check again, and no dice on Discord or Twitch. Something seems to have dropped, and these are the results from your previous query when run again:

root@OpenWrt:~# ubus call system board; \
> for DNS in 127.0.0.1 ::1 10.8.8.1 1.1.1.1 2606:4700:4700::1111 8.8.8.
8 2001:4860:4860::8888; \
> do for OPT in "" +tcp +notcp; \
> do echo ${DNS}:${OPT}:$(dig @${DNS} -q discord.com +short ${OPT}); \
> done; done
{
        "kernel": "4.14.195",
        "hostname": "OpenWrt",
        "system": "ARMv7 Processor rev 1 (v7l)",
        "model": "Linksys WRT3200ACM",
        "board_name": "linksys,rango",
        "release": {
                "distribution": "OpenWrt",
                "version": "19.07.4",
                "revision": "r11208-ce6496d796",
                "target": "mvebu/cortexa9",
                "description": "OpenWrt 19.07.4 r11208-ce6496d796"
        }
}
127.0.0.1::
127.0.0.1:+tcp:
127.0.0.1:+notcp:
::1:: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
::1:+tcp:;; Connection to ::1#53(::1) for discord.com failed: connection refused.
::1:+notcp: ; <<>> DiG 9.16.8 <<>> @::1 -q discord.com +short +notcp ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached
10.8.8.1::162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+tcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
10.8.8.1:+notcp:162.159.128.233 162.159.135.232 162.159.136.232 162.159.137.232 162.159.138.232
1.1.1.1::162.159.135.232 162.159.137.232 162.159.136.232 162.159.128.233 162.159.138.232
1.1.1.1:+tcp:162.159.136.232 162.159.128.233 162.159.138.232 162.159.135.232 162.159.137.232
1.1.1.1:+notcp:162.159.138.232 162.159.136.232 162.159.135.232 162.159.137.232 162.159.128.233
2606:4700:4700::1111::162.159.135.232 162.159.138.232 162.159.128.233 162.159.136.232 162.159.137.232
2606:4700:4700::1111:+tcp:162.159.137.232 162.159.128.233 162.159.135.232 162.159.136.232 162.159.138.232
2606:4700:4700::1111:+notcp:162.159.138.232 162.159.136.232 162.159.135.232 162.159.128.233 162.159.137.232
8.8.8.8::162.159.136.232 162.159.128.233 162.159.138.232 162.159.137.232 162.159.135.232
8.8.8.8:+tcp:162.159.135.232 162.159.128.233 162.159.136.232 162.159.137.232 162.159.138.232
8.8.8.8:+notcp:162.159.135.232 162.159.136.232 162.159.138.232 162.159.137.232 162.159.128.233
2001:4860:4860::8888::162.159.136.232 162.159.128.233 162.159.137.232 162.159.135.232 162.159.138.232
2001:4860:4860::8888:+tcp:162.159.135.232 162.159.128.233 162.159.137.232 162.159.138.232 162.159.136.232
2001:4860:4860::8888:+notcp:162.159.135.232 162.159.137.232 162.159.136.232 162.159.128.233 162.159.138.232

Rebooting the router having made zero changes didn't fix the issue. I don't think it's due to the VPN connection as toggling that on/off doesn't affect anything, and since I have experienced success both with and without 10.8.8.1 in the DNS server chain and it has reliably produced resolution from that dump command you gave me, I don't think that's the problem either.

I wonder what matter of timing could be doing it.

Worth mentioning that my processes graph 'load' was up to around .86 while downloading two large files. It obviously went back down since, and if this had been an instance of high CPU usage botching some DNS related aspects of the connection (if that's even possible) I would have expected a reboot to resolve them.

Lemme know if there are any remaining leads on this inconsistent but persistent problem. Perhaps I need to kick it up to unbound's forums.

vgaetera · November 11, 2020, 5:15am

Plain DNS over TCP/UDP works for you with dig, so this should be some Unbound-specific issue.
Logically the next troubleshooting step is to disable both DNSSEC and DoT and try to make Unbound work with plain DNS.

etherb0x · November 15, 2020, 9:30pm

Case closed. Adblock was loading a list of 'gaming' related sites.

system · November 25, 2020, 9:30pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.