A lot of SOA type blocked queries and many domains not resolving

Yesterday my Pi-Hole (latest version 4.1.1) started to list a lot of SOA type queries for my MacBook. It didn't do it before and all of a sudden I got this.

It's only for my Mac, all other devices don't do it. Long ago I've specifically change the Pi-Hole domain name to .device instead of .local to make sure it doesn't interfere with other devices that might use the .local domain.

Also, at the same time I've noticed that some legitimate domains do not resolve, for example wikipedia.org, or lloydsbank.co.uk. The Pi-Hole query log looks like this, I don't understand why the domain is not resolved in the browser if it's not blocked in Pi-Hole

And very curiously, only some random domains don't resolve, in rest I'm online, I can browse, etc. If I connect via VPN the domains resolve very well, meaning that the websites are up and running and it's my Pi-Hole where the problem lies. Currently I'm using the DNSWatch with DNSSEC enabled, but I've tried with Google (8.8.8.8), Cloudfare, I've tried to switch DNSSEC Off, restart RaspberyPi, etc. and nothing, Lloyds and Wikipedia still not resolving

Does anyone have similar issues, or if you know what's the problem, can you please point me in the right direction? Many thanks.

Here are the details of my Pi-Hole version and setup variables

Core: v4.1.1
Branch: master
Commit: v4.1.1-0-g8d85d46c

Web: v4.1.1
Branch: master
Commit: v4.1.1-0-gde7aa5a3

FTL: v4.1.2

Setup variables

API_EXCLUDE_DOMAINS=
API_EXCLUDE_CLIENTS=
API_QUERY_LOG_SHOW=all
API_PRIVACY_MODE=false
API_GET_UPSTREAM_DNS_HOSTNAME=true
API_GET_CLIENT_HOSTNAME=true
DHCP_ACTIVE=true
DHCP_START=192.168.1.2
DHCP_END=192.168.1.254
DHCP_ROUTER=192.168.1.1
DHCP_LEASETIME=24
PIHOLE_DOMAIN=device
DHCP_IPv6=true
BLOCKING_ENABLED=true
PIHOLE_INTERFACE=eth0
IPV4_ADDRESS=192.168.1.16/24
IPV6_ADDRESS=
QUERY_LOGGING=true
INSTALL_WEB_SERVER=true
INSTALL_WEB_INTERFACE=true
LIGHTTPD_ENABLED=true
DNSMASQ_LISTENING=single
PIHOLE_DNS_1=84.200.69.80
PIHOLE_DNS_2=84.200.70.40
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=true
DNSSEC=true
CONDITIONAL_FORWARDING=false

The first screen you posted shows that the SOA request for "local", coming from the macbook laptop, is being blocked by your upstream server. This makes sense, since that server doesn't know anything about a local domain. What do the entries in /var/log/pihole.log look like for these requests (the log will have a bit more detail than shown in the query log).

It appears that something on your Mac is coded to find something on a "local" domain.

For the second problem, what is the result of a dig from the Mac to these two domains? Of interest, the first request returned a CNAME very slowly (over a second).

dig online.lloydsbank.co.uk

dig marketing.lloydsbank.co.uk

And, the correspoding entries in /var/log/pihole.log for these requests.

Lastly, run this command on the Mac terminal and post the result. This shows the DNS servers that the Mac is using, in preferred order:

scutil --dns

Thank you jfb, regarding the .local domain query that my mac generates here's an example of related queries logged in the /etc/var/pihole.log file

Jan 26 13:46:03 dnsmasq[736]: query[SOA] local from 192.168.1.4
Jan 26 13:46:03 dnsmasq[736]: forwarded local to 84.200.70.40
Jan 26 13:46:03 dnsmasq[736]: validation result is SECURE
Jan 26 13:46:04 dnsmasq[736]: query[SOA] local from 192.168.1.4
Jan 26 13:46:04 dnsmasq[736]: forwarded local to 84.200.70.40
Jan 26 13:46:05 dnsmasq[736]: validation result is SECURE
Jan 26 13:46:13 dnsmasq[736]: query[SOA] local from 192.168.1.4
Jan 26 13:46:13 dnsmasq[736]: forwarded local to 84.200.70.40
Jan 26 13:46:13 dnsmasq[736]: validation result is SECURE

Regarding the second problem with the unresolved Lloyds domain here's the result of dig online.lloydsbank.co.uk

dig online.lloydsbank.co.uk

; ; Truncated, retrying in TCP mode.

; <<>> DiG 9.10.6 <<>> online.lloydsbank.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22202
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;online.lloydsbank.co.uk. IN A

;; ANSWER SECTION:
online.lloydsbank.co.uk. 39 IN CNAME online.lloydsbank.co.uk.edgekey.net.
online.lloydsbank.co.uk.edgekey.net. 21519 IN CNAME e4535.ksd.akamaiedge.net.
e4535.ksd.akamaiedge.net. 20 IN A 104.74.131.21

;; Query time: 5923 msec
;; SERVER: 192.168.1.16#53(192.168.1.16)
;; WHEN: Sat Jan 26 17:55:01 GMT 2019
;; MSG SIZE rcvd: 152

And here's the corresponding entry in /etc/var/pihole.log

Jan 26 17:54:35 dnsmasq[736]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 17:54:35 dnsmasq[736]: forwarded online.lloydsbank.co.uk to 84.200.70.40
Jan 26 17:54:35 dnsmasq[736]: dnssec-query[DNSKEY] lloydsbank.co.uk to 84.200.70.40
Jan 26 17:54:35 dnsmasq[736]: reply online.lloydsbank.co.uk is <CNAME>
Jan 26 17:54:35 dnsmasq[736]: reply online.lloydsbank.co.uk.edgekey.net is <CNAME>
Jan 26 17:54:35 dnsmasq[736]: reply e4535.ksd.akamaiedge.net is 104.74.131.21
Jan 26 17:54:35 dnsmasq[15253]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 17:54:45 dnsmasq[15254]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 17:54:47 dnsmasq-dhcp[736]: no address range available for DHCPv6 request via eth0
Jan 26 17:54:53 dnsmasq[15255]: query[A] 0.debian.pool.ntp.org from 127.0.0.1
Jan 26 17:54:55 dnsmasq[15256]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 17:55:01 dnsmasq[15256]: forwarded online.lloydsbank.co.uk to 84.200.70.40
Jan 26 17:55:01 dnsmasq[15256]: dnssec-query[DNSKEY] lloydsbank.co.uk to 84.200.70.40
Jan 26 17:55:01 dnsmasq[15256]: reply lloydsbank.co.uk is DNSKEY keytag 24067, algo 8
Jan 26 17:55:01 dnsmasq[15256]: reply lloydsbank.co.uk is DNSKEY keytag 44230, algo 8
Jan 26 17:55:01 dnsmasq[15256]: reply lloydsbank.co.uk is DNSKEY keytag 8190, algo 8
Jan 26 17:55:01 dnsmasq[15256]: dnssec-query[DS] edgekey.net to 84.200.70.40
Jan 26 17:55:01 dnsmasq[15256]: reply edgekey.net is no DS
Jan 26 17:55:01 dnsmasq[15256]: validation result is INSECURE
Jan 26 17:55:01 dnsmasq[15256]: reply online.lloydsbank.co.uk is <CNAME>
Jan 26 17:55:01 dnsmasq[15256]: reply online.lloydsbank.co.uk.edgekey.net is <CNAME>
Jan 26 17:55:01 dnsmasq[15256]: reply e4535.ksd.akamaiedge.net is 104.74.131.21

The very weird thing is that about an hour later I tried again dig online.lloydsbank.co.uk and I had no response whatsoever:

dig online.lloydsbank.co.uk

;; Truncated, retrying in TCP mode.
; <<>> DiG 9.10.6 <<>> online.lloydsbank.co.uk
;; global options: +cmd
;; connection timed out; no servers could be reached

And the corresponding entry in `/etc/var/pihole.log`

Jan 26 19:24:03 dnsmasq[736]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 19:24:03 dnsmasq[736]: forwarded online.lloydsbank.co.uk to 84.200.70.40
Jan 26 19:24:03 dnsmasq[736]: dnssec-query[DNSKEY] lloydsbank.co.uk to 84.200.70.40
Jan 26 19:24:03 dnsmasq[736]: reply online.lloydsbank.co.uk is <CNAME>
Jan 26 19:24:03 dnsmasq[736]: reply online.lloydsbank.co.uk.edgekey.net is <CNAME>
Jan 26 19:24:03 dnsmasq[736]: reply e4535.ksd.akamaiedge.net is 104.89.35.51
Jan 26 19:24:03 dnsmasq[16379]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 19:24:13 dnsmasq[16380]: query[A] online.lloydsbank.co.uk from 192.168.1.4
Jan 26 19:24:23 dnsmasq[16381]: query[A] online.lloydsbank.co.uk from 192.168.1.4

Finally, here's the result of the scutil --dns command on my Mac

DNS configuration

resolver #1
  search domain[0] : device
  nameserver[0] : 192.168.1.16
  if_index : 7 (en0)
  flags    : Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300000

resolver #3
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300200

resolver #4
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300400

resolver #5
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300600

resolver #6
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 300800

resolver #7
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : 0x00000000 (Not Reachable)
  order    : 301000

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : device
  nameserver[0] : 192.168.1.16
  if_index : 7 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

That's what I thought, it takes way too long. I use DNS.WATCH as the upstream DNS server with DNSSEC enabled

Turn off DNSSEC in Pi-Hole. The version of dnsmasq in the current version has some known DNSSEC problems (to be fixed in release 4.2).

I would also shift to another upstream provider and see if the situation improves.

I just switched off DNSSEC and changed the upstream provider to Cloudflare and restarted the DNS resolver from the web interface. Same thing as before. It still doesn't resolve Lloyds or Wikipedia. Dig still returns a connection timeout with servers unreachable for online.lloydsbank.co.uk domain. Honestly. I'm scratching my head, have no idea what to try

I've tried what you suggested and when I restarted Pi-hole the dnsmasq and FTL service didn't start, even if I manually tried to do so with pihole restartdns. However, as soon as I removed the line from /etc/dnsmasq.d/01-pihole.confand restarted the system then DNS and FTL both started fine.

But guess what msatter: now it resolves both Lloyds and Wikipedia. Of course, the problem is now sorted, but that let me thinking: what the hell caused the issue in the first place, because like I said /etc/dnsmasq.d/01-pihole.conf is still unchanged :thinking:

Anyhow, now that it came back to life, I'm very happy, of course :smile:
Many thanks again to both of you msatter and jfb, I appreciate very much your help

Good question, now that I'm thinking after jfb's suggestion I only restarted the DNS service from the web interface, not the whole system, so probably that solved the problem.
This also explains why it still didn't work after I've changed different upstream DNS servers in the web interface, because I only restarted the DNS service, not the whole Pi-hole.

All in all, I think that DNSSEC was the culprit, so switching it off solved it.
I'll also try your suggestion with lowering the packet size to 512. Thanks for the edit.

Cheers again

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