Whenever I try to go to af.mil I get a SERVFAIL. I did some searching through the forums and noticed that this happens a lot with UNBOUND but I'm not running UNBOUND.
Pihole forwards to OpenDNS. Everything else works except websites ending in .af.mil.
I'm on Pihole v5.
d4vsxyhozw
I see the same using unboud, resolution works using google
nanopi@nanopi:~$ dig af.mil
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> af.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5418
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;af.mil. IN A
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Jun 09 20:04:26 CEST 2020
;; MSG SIZE rcvd: 35
nanopi@nanopi:~$ dig af.mil @8.8.8.8
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> af.mil @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44043
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;af.mil. IN A
;; AUTHORITY SECTION:
af.mil. 474 IN SOA langley-ns10.afnoc.af.mil. dnsman.us.af.mil. 2020056197 3600 360 604800 500
;; Query time: 77 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Di Jun 09 20:04:43 CEST 2020
;; MSG SIZE rcvd: 100
It seems there is a DNSSEC error:
ADD
Strange...now (5 min later) it's working using unbound and no DNSSEC error.
Maybe...
nanopi@nanopi:~$ dig af.mil
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> af.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18583
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;af.mil. IN A
;; AUTHORITY SECTION:
af.mil. 0 IN SOA langley-ns10.afnoc.af.mil. dnsman.us.af.mil. 2020056196 3600 360 604800 500
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Jun 09 20:14:32 CEST 2020
;; MSG SIZE rcvd: 100
nanopi@nanopi:~$ dig af.mil
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> af.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32462
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;af.mil. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Jun 09 20:17:23 CEST 2020
;; MSG SIZE rcvd: 35
nanopi@nanopi:~$ dig af.mil
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> af.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7198
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;af.mil. IN A
;; AUTHORITY SECTION:
af.mil. 0 IN SOA langley-ns10.afnoc.af.mil. dnsman.us.af.mil. 2020056202 3600 360 604800 500
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Jun 09 20:17:32 CEST 2020
;; MSG SIZE rcvd: 100
Records are updating, serial numbers are out of sync across the authoritative DNS servers, should fix itself as records propagate.
If I take my phone off of WiFi I can access the webpage fine, it's also been this was for almost 2 weeks. I know the government is slow, but why would I be able to access it via cell network if the issue was related to the serial?
As msatter notes, it's DNSSEC. If you disable DNSSEC on the Pi-hole then you'll likely see it working again.
DNSSEC is disabled on the PiHole already
Please generate a new debug log and post the token. Also, please post the output of any transactions in /var/log/pihole.log that result in a SERVFAIL reply. They might look something like this example:
Jun 9 10:06:10 dnsmasq[7676]: query[A] www.vodcars.com from 192.168.0.135
Jun 9 10:06:10 dnsmasq[7676]: forwarded www.vodcars.com to 127.0.0.1
Jun 9 10:06:11 dnsmasq[7676]: forwarded www.vodcars.com to 127.0.0.1
Jun 9 10:06:11 dnsmasq[7676]: reply error is SERVFAIL
https://tricorder.pi-hole.net/6jaybkl6ph
pi@raspberrypi:~ $ sudo cat /var/log/pihole.log | grep -B4 "SERVFAIL"
Jun 9 10:59:42 dnsmasq[1356]: query[A] watson.telemetry.microsoft.com from 192.168.2.88
Jun 9 10:59:42 dnsmasq[1356]: gravity blocked watson.telemetry.microsoft.com is 192.168.2.196
Jun 9 10:59:42 dnsmasq[1356]: query[A] www.google.com from 71.179.105.215
Jun 9 10:59:42 dnsmasq[1356]: cached www.google.com is 172.217.13.68
Jun 9 10:59:43 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:00:00 dnsmasq[1356]: query[A] docs.google.com from 192.168.2.160
Jun 9 11:00:00 dnsmasq[1356]: forwarded docs.google.com to 208.67.220.220
Jun 9 11:00:00 dnsmasq[1356]: forwarded docs.google.com to 208.67.222.222
Jun 9 11:00:00 dnsmasq[1356]: reply docs.google.com is 172.217.13.78
Jun 9 11:00:00 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:00:04 dnsmasq[1356]: forwarded 113.63.253.172.in-addr.arpa to 208.67.220.220
Jun 9 11:00:04 dnsmasq[1356]: query[PTR] 113.63.253.172.in-addr.arpa from 192.168.2.160
Jun 9 11:00:04 dnsmasq[1356]: forwarded 113.63.253.172.in-addr.arpa to 208.67.222.222
Jun 9 11:00:04 dnsmasq[1356]: forwarded 113.63.253.172.in-addr.arpa to 208.67.220.220
Jun 9 11:00:05 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:01:38 dnsmasq[1356]: forwarded 101.31.250.142.in-addr.arpa to 208.67.222.222
Jun 9 11:01:38 dnsmasq[1356]: forwarded 101.31.250.142.in-addr.arpa to 208.67.220.220
Jun 9 11:01:38 dnsmasq[1356]: query[PTR] 133.164.217.172.in-addr.arpa from 192.168.2.160
Jun 9 11:01:38 dnsmasq[1356]: cached 172.217.164.133 is iad30s24-in-f5.1e100.net
Jun 9 11:01:38 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:02:06 dnsmasq[1356]: query[PTR] 234.13.217.172.in-addr.arpa from 192.168.2.160
Jun 9 11:02:06 dnsmasq[1356]: cached 172.217.13.234 is iad23s61-in-f10.1e100.net
Jun 9 11:02:06 dnsmasq[1356]: query[PTR] 65.15.217.172.in-addr.arpa from 192.168.2.160
Jun 9 11:02:06 dnsmasq[1356]: cached 172.217.15.65 is iad23s63-in-f1.1e100.net
Jun 9 11:02:06 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:02:11 dnsmasq[1356]: forwarded rpns.cs.roku.com to 208.67.220.220
Jun 9 11:02:11 dnsmasq[1356]: forwarded rpns.cs.roku.com to 208.67.222.222
Jun 9 11:02:11 dnsmasq[1356]: reply rpns.cs.roku.com is 54.175.22.16
Jun 9 11:02:11 dnsmasq[1356]: reply rpns.cs.roku.com is 52.73.146.238
Jun 9 11:02:11 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 11:02:41 dnsmasq[1356]: forwarded us.tmobile.rcs.telephony.goog to 208.67.220.220
Jun 9 11:02:41 dnsmasq[1356]: forwarded us.tmobile.rcs.telephony.goog to 208.67.222.222
Jun 9 11:02:41 dnsmasq[1356]: query[SRV] _sips._tcp.us.tmobile.rcs.telephony.goog from 192.168.2.217
Jun 9 11:02:41 dnsmasq[1356]: forwarded _sips._tcp.us.tmobile.rcs.telephony.goog to 208.67.220.220
Jun 9 11:02:41 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:18:17 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:17 dnsmasq[1356]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:18:17 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:17 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:17 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:18:22 dnsmasq[1356]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:18:22 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:22 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:22 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:22 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:18:27 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:27 dnsmasq[1356]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:18:27 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:27 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:27 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:18:41 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:41 dnsmasq[1356]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:18:41 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:18:41 dnsmasq[1356]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:18:41 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:19:51 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:19:51 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:19:51 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:19:51 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:19:51 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:19:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:19:56 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:19:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:19:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:19:56 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:20:04 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:20:04 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:20:04 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:20:04 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:20:05 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:20:09 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:20:09 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:20:09 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:20:09 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:20:09 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:21:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:21:56 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:21:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:21:56 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:21:56 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:22:05 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:22:05 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:22:05 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:22:05 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:22:05 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:22:27 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:22:27 dnsmasq[1356]: query[A] afrc.eim.us.af.mil from 192.168.2.88
Jun 9 13:22:27 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.220.220
Jun 9 13:22:27 dnsmasq[1356]: forwarded afrc.eim.us.af.mil to 208.67.222.222
Jun 9 13:22:27 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:36:13 dnsmasq[1356]: query[A] federation.prod.cce.af.mil from 192.168.2.88
Jun 9 13:36:13 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:36:13 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 13:36:13 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:36:13 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:36:19 dnsmasq[1356]: query[A] federation.prod.cce.af.mil from 192.168.2.88
Jun 9 13:36:19 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:36:19 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 13:36:19 dnsmasq[1356]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:36:19 dnsmasq[1356]: reply error is SERVFAIL
--
Jun 9 13:45:49 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:45:49 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.88
Jun 9 13:45:49 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 13:45:49 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:45:49 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 13:46:09 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.88
Jun 9 13:46:09 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:46:10 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 13:46:10 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:46:10 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 13:46:15 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.88
Jun 9 13:46:15 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:46:15 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 13:46:15 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 13:46:15 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 13:48:29 dnsmasq[1388]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:48:29 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:48:30 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:48:30 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:48:30 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 13:48:35 dnsmasq[1388]: query[A] owa.us.af.mil from 192.168.2.88
Jun 9 13:48:35 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:48:35 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.220.220
Jun 9 13:48:35 dnsmasq[1388]: forwarded owa.us.af.mil to 208.67.222.222
Jun 9 13:48:35 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 15:22:57 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.143
Jun 9 15:22:57 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:57 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:57 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:57 dnsmasq[1388]: reply error is SERVFAIL
Jun 9 15:22:57 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.143
Jun 9 15:22:57 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:58 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 15:22:58 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.143
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:58 dnsmasq[1388]: reply error is SERVFAIL
Jun 9 15:22:58 dnsmasq[1388]: query[A] federation.prod.cce.af.mil from 192.168.2.143
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.220.220
Jun 9 15:22:58 dnsmasq[1388]: forwarded federation.prod.cce.af.mil to 208.67.222.222
Jun 9 15:22:58 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 15:50:06 dnsmasq[1388]: query[AAAA] www.duckdns.org from 127.0.0.1
Jun 9 15:50:06 dnsmasq[1388]: cached www.duckdns.org is <CNAME>
Jun 9 15:50:06 dnsmasq[1388]: forwarded www.duckdns.org to 208.67.220.220
Jun 9 15:50:06 dnsmasq[1388]: forwarded www.duckdns.org to 208.67.222.222
Jun 9 15:50:07 dnsmasq[1388]: reply error is SERVFAIL
--
Jun 9 17:29:04 dnsmasq[1388]: forwarded e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.brokendnssec.net to 208.67.222.222
Jun 9 17:29:04 dnsmasq[1388]: reply e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.encryptedsni.com is 104.22.73.170
Jun 9 17:29:04 dnsmasq[1388]: reply e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.encryptedsni.com is 172.67.13.180
Jun 9 17:29:04 dnsmasq[1388]: reply e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.encryptedsni.com is 104.22.72.170
Jun 9 17:29:04 dnsmasq[1388]: reply error is SERVFAIL
Jun 9 17:29:04 dnsmasq[1388]: query[A] e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.brokendnssec.net from 192.168.2.143
Jun 9 17:29:04 dnsmasq[1388]: forwarded e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.brokendnssec.net to 208.67.222.222
Jun 9 17:29:04 dnsmasq[1388]: forwarded e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.brokendnssec.net to 208.67.220.220
Jun 9 17:29:04 dnsmasq[1388]: forwarded e0bf5e42-a1c2-4a0e-872d-a2967bd27ce9.brokendnssec.net to 208.67.222.222
Jun 9 17:29:04 dnsmasq[1388]: reply error is SERVFAIL
That's a lot more than just af.mil domains.
On the Pi-hole run dig docs.google.com @208.67.220.220 and post the full results.
I noticed that were a lot more when I was going through the logs, but they seem like background stuff which is why I never noticed.
pi@raspberrypi:~ $ dig docs.google.com @208.67.220.220
; <<>> DiG 9.10.3-P4-Raspbian <<>> docs.google.com @208.67.220.220
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docs.google.com. IN A
;; ANSWER SECTION:
docs.google.com. 300 IN A 172.217.13.78
;; Query time: 16 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Tue Jun 09 19:00:03 EDT 2020
;; MSG SIZE rcvd: 60
Do you have any firewall or security software/hardware between the Pi and the internet?
Only the router.
But that firewall is block inbound/allow outbound so that shouldn't be causing the issue
Iptables on the pi as well
pi@raspberrypi:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
f2b-lighttpd-auth tcp -- anywhere anywhere multiport dports http,https
f2b-sshd-ddos tcp -- anywhere anywhere multiport dports 2324
f2b-sshd tcp -- anywhere anywhere multiport dports 2324
ACCEPT udp -- anywhere anywhere udp dpt:51820 /* wireguard-input-rule */
f2b-lighttpd-auth tcp -- anywhere anywhere multiport dports http,https
f2b-sshd-ddos tcp -- anywhere anywhere multiport dports 2324
f2b-sshd tcp -- anywhere anywhere multiport dports 2324
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
ACCEPT all -- anywhere anywhere
ACCEPT udp -- anywhere anywhere udp dpt:openvpn
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-USER all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-1 all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere 10.6.0.0/24 ctstate RELATED,ESTABLISHED /* wireguard-forward-rule */
ACCEPT all -- 10.6.0.0/24 anywhere /* wireguard-forward-rule */ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
DOCKER all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (2 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:9000
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:8000
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target prot opt source destination
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-lighttpd-auth (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain f2b-sshd (4 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain f2b-sshd-ddos (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
pi@raspberrypi:~ $ sudo iptables -L
I'd clean up the rules if that were my setup. You have a lot of duplicate rules and rules that won't do anything.
Is the rule on the firewall explicitly for port 53? Is there somewhere that could be set to 53udp only and blocking 53tcp?
On the router firewall or pihole firewall?
There's no rules for port 53 anywhere in my setup. Rules are standard allow outbound block inbound.
Not exactly.
Take your INPUT chain for example. It's set to ACCEPT as the default policy, but you have no DROP rules so nothing is going to be blocked. You also have the same rules repeated a few times. If the SERVFAIL is not caused by DNSSEC then there are communication issues between the Pi-hole and the upstream DNS servers.
But why would there only be SERVFAILs on certain domains? Wouldn't the issue be more frequent if it was a communication issue?
Also this issue just started but the rules have been the same for months.
So far I'm not seeing certain domains but random domains and not-reproduceable responses. Log shows a domain was SERVFAIL but a manual dig of that same domain doesn't.
I will say that .af.mil does it every time when trying to access via web browser
Okay, then can you give us some logs when you use that domain? A URL to try and duplicate?
Edit: A dig of the domain with the SERVFAIL error would be helpful as well.