Pi-hole: Bogus Responses with DNSSEC enabled
In raising this issue, I confirm the following: {please fill the checkboxes, e.g: [X]}
- [X] I have read and understood the contributors guide.
- [X] The issue I am reporting can be replicated.
- [X] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).
How familiar are you with the the source code relevant to this issue?:
{3}
Expected behaviour:
{Functional DNS Resolving with DNSSEC enabled}
Actual behaviour:
{Bogus responses, I've tested on DNS Watch, Cloudflare and Quad9}
Steps to reproduce:
{It's appearing out of the blue at random times}
Debug token provided by uploading pihole -d log:
{https://tricorder.pi-hole.net/nm8biwv0m1!}
Troubleshooting undertaken, and/or other relevant information:
{Disabling DNSSEC and re-enabling it after a whilefixes it. I've seen some Stalled Closed issues, no actual fix ever proposed though :( }
DenyDarko
All 62 comments
If you are getting BOGUS then the domains are not correctly configured. I can't see from the redacted domains to be able to tell, but one looks like it has a .lan TLD which can never be DNSSEC enabled so your configuration is not right.
dschaper
on 2 Mar 2019
If you are getting BOGUS then the domains are not correctly configured. I can't see from the redacted domains to be able to tell, but one looks like it has a .lan TLD which can never be DNSSEC enabled so your configuration is not right.
I never said DNSSEC doesn't work. It usually does and returns the normal "Insecure" response for non-dnssec domains.
When that bug is triggered. NO domain is resolved at all.
The list you see is 10 pages long full of BOGUS for every single domain, I just posted an example.
DenyDarko
on 2 Mar 2019
What are the settings at http://pi.hole/admin/settings.php?tab=dns
dschaper
on 2 Mar 2019
Something is not correct however, anything ending in .lan should be NXDOMAIN, not an IP. If you are getting an IP address for a .lan address from an upstream then there is a misconfiguration. .lan does not exist outside of local network segments.
dschaper
on 2 Mar 2019
What are the settings at http://pi.hole/admin/settings.php?tab=dns
Something is not correct however, anything ending in
.lanshould be NXDOMAIN, not an IP. If you are getting an IP address for a.lanaddress from an upstream then there is a misconfiguration..landoes not exist outside of local network segments.
Currently I have DNSSEC disabled.
Pihole acts as DHCP too.
As for the lan, not really, It responds just fine for my .lan addresses. The responses are coming from the raspberry's DHCP static addresse hostname, not upstream. It responds as the Authoritative DNS server:
nslookup printer.lan
Server: raspberrypi
Address: 192.168.2.10
Name: printer.lan
Address: 192.168.2.101
When the BOGUS think happens, I see it too now, it states "forwarded" even for those which is definitely not normal
DenyDarko
on 2 Mar 2019
Can you share the corresponding log lines? Have a look for validation result is BOGUS and copy the corresponding log plus a few lines before and later. You can remove the domains but please make it explicit and leave the TLD intact so we can see what is happening for what kind of domain.
Example for a suitable redaction:
somedomain.com->[removed].comprinter.lan->[removed].lan- etc.
DL6ER
on 2 Mar 2019
A friend just contacted me saying he couldn't load the following site, it took me disabling DNSSEC in order for him to fully access it -- i initially attempted to simply whitelist the domain(s), but no positive results. Was returning a BOGUS result on the request(s).
Domains in question -- https://www.vwvortex.com/ & https://forums.vwvortex.com/
He's running:
Pi-hole version is v4.2.2 (Latest: v4.2.2)
AdminLTE version is v4.2 (Latest: v4.2)
FTL version is v4.2.3 (Latest: v4.2.3)
Using his ISP's DNS servers as upstream. My setup is a little different, as I'm running Unbound, and had no issues loading the aforementioned pages in question, with DNSSEC enabled. I've left the domains whitelisted and attempted to re-enable DNSSEC, we'll see how soon he complains again about attempting to access those pages.
user@ubuserv:~$ dig www.vwvortex.com
; <<>> DiG 9.11.3-1ubuntu1.5-Ubuntu <<>> www.vwvortex.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15304
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.vwvortex.com. IN A
;; Query time: 62 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Mar 05 00:44:14 UTC 2019
;; MSG SIZE rcvd: 45
Your debug token is: https://tricorder.pi-hole.net/22xx4fztut!
WAS using DNSSEC until just an hour ago, all other settings are left unchecked, but using Conditional Forwarding to point back to an Edgerouter-X, which has dnsmasq enabled.
harrypnyce
on 5 Mar 2019
This issue is tracking a situation where every domain returns BOGUS, not just a specific domain/subdomain. In your case it looks like a valid response as SERVFAIL is the status and that signals a BOGUS state. If it occurs again please open a new issue.
dschaper
on 5 Mar 2019
If it occurs again please open a new issue.
As per your suggestion, sir new issue opened: https://github.com/pi-hole/pi-hole/issues/2664
[鉁揮 Your debug token is: https://tricorder.pi-hole.net/4dndlivson!
peatrick
on 5 Mar 2019
Sorry for the delay, I was waiting for it to happen again with DNS.WATCH:
Mar 6 06:17:16 dnsmasq[703]: started, version pi-hole-2.80 cachesize 10000
Mar 6 06:17:16 dnsmasq[703]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
Mar 6 06:17:16 dnsmasq[703]: DNSSEC validation enabled
Mar 6 06:17:16 dnsmasq[703]: configured with trust anchor forkeytag 20326
Mar 6 06:17:16 dnsmasq[703]: configured with trust anchor forkeytag 19036
Mar 6 06:17:16 dnsmasq-dhcp[703]: DHCP, IP range 192.168.2.2 -- 192.168.2.254, lease time 2h
Mar 6 06:17:16 dnsmasq[703]: using nameserver 84.200.70.40#53
Mar 6 06:17:16 dnsmasq[703]: using nameserver 84.200.69.80#53
Mar 6 06:17:16 dnsmasq[703]: read /etc/hosts - 2 addresses
Mar 6 06:17:16 dnsmasq[703]: read /etc/pihole/local.list - 2 addresses
Mar 6 06:17:16 dnsmasq[703]: read /etc/pihole/black.list - 0 addresses
Mar 6 06:17:22 dnsmasq[703]: read /etc/pihole/gravity.list - 589497 addresses
Mar 6 06:17:23 dnsmasq[703]: query[A] ssl.gstatic.com from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPDISCOVER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPOFFER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq[703]: query[A] checkip.dyndns.org from 192.168.2.1
Mar 6 06:17:23 dnsmasq[703]: forwarded checkip.dyndns.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded checkip.dyndns.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPDISCOVER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPOFFER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPDISCOVER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPOFFER(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq[703]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] app.manifest.ly from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded app.manifest.ly to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded app.manifest.ly to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] ssl.gstatic.com from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] ssl.gstatic.com from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded ssl.gstatic.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] 1.europe.pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded 1.europe.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] piaware.flightaware.com from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded piaware.flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[A] A2.CF.3A.0004A3.keys.sensornet.info from 192.168.2.193
Mar 6 06:17:23 dnsmasq[703]: forwarded A2.CF.3A.0004A3.keys.sensornet.info to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: forwarded A2.CF.3A.0004A3.keys.sensornet.info to 84.200.69.80
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPREQUEST(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq-dhcp[703]: DHCPACK(wlan0) 192.168.2.193 00:04:a3:3a:cf:a2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ly to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: query[A] www.greek-team.cc from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded www.greek-team.cc to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: query[A] www.greek-team.cc from 192.168.2.2
Mar 6 06:17:23 dnsmasq[703]: forwarded www.greek-team.cc to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: forwarded www.greek-team.cc to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] info to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] . to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] cc to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply com is DS keytag 30909, algo 8, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] gstatic.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply ly is no DS
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] herokudns.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply info is DS keytag 8674, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] dyndns.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reducing DNS packet size for nameserver 84.200.69.80 to 1280
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply com is DS keytag 30909, algo 8, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] gstatic.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply ly is no DS
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] herokudns.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply info is DS keytag 8674, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: reply info is DS keytag 8674, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] sensornet.info to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reducing DNS packet size for nameserver 84.200.70.40 to 1280
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply com is DS keytag 30909, algo 8, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] flightaware.com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply com is DS keytag 30909, algo 8, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] flightaware.com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 20326, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 16749, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply . is DNSKEY keytag 19164, algo 8
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 1
Mar 6 06:17:23 dnsmasq[703]: reply org is DS keytag 9795, algo 7, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply cc is DS keytag 519, algo 8, digest 1
Mar 6 06:17:23 dnsmasq[703]: reply cc is DS keytag 519, algo 8, digest 2
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DS] greek-team.cc to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] com to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply dyndns.org is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation checkip.dyndns.org is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.org is
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.com is 216.146.43.70
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.com is 216.146.43.71
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.org is
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.com is 216.146.43.70
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.com is 216.146.43.71
Mar 6 06:17:23 dnsmasq[703]: reply checkip.dyndns.com is 131.186.113.70
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply pool.ntp.org is 136.243.66.91
Mar 6 06:17:23 dnsmasq[703]: reply pool.ntp.org is 141.30.228.4
Mar 6 06:17:23 dnsmasq[703]: reply pool.ntp.org is 193.141.27.1
Mar 6 06:17:23 dnsmasq[703]: reply pool.ntp.org is 85.236.36.4
Mar 6 06:17:23 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation uk.pool.ntp.org is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 185.121.25.166
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 195.195.221.100
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 85.199.214.99
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 178.62.68.79
Mar 6 06:17:23 dnsmasq[703]: reply sensornet.info is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation A2.CF.3A.0004A3.keys.sensornet.info is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply A2.CF.3A.0004A3.keys.sensornet.info is 154.51.148.75
Mar 6 06:17:23 dnsmasq[703]: reply A2.CF.3A.0004A3.keys.sensornet.info is 154.51.148.74
Mar 6 06:17:23 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:23 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: dnssec-query[DNSKEY] com to 84.200.70.40
Mar 6 06:17:23 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply pool.ntp.org is NODATA-IPv6
Mar 6 06:17:23 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:23 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:23 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:23 dnsmasq[703]: validation uk.pool.ntp.org is BOGUS
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 217.114.59.66
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 129.250.35.251
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 145.239.118.233
Mar 6 06:17:23 dnsmasq[703]: reply uk.pool.ntp.org is 185.113.128.144
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation uk.pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 185.121.25.166
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 195.195.221.100
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 85.199.214.99
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 178.62.68.79
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:32 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is NODATA-IPv6
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 136.243.66.91
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 141.30.228.4
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 193.141.27.1
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 85.236.36.4
Mar 6 06:17:32 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation 1.north-america.pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 69.36.182.57
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 208.75.89.4
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 45.63.11.93
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 159.203.8.72
Mar 6 06:17:32 dnsmasq[703]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded 1.north-america.pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation uk.pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 185.121.25.166
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 195.195.221.100
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 85.199.214.99
Mar 6 06:17:32 dnsmasq[703]: reply uk.pool.ntp.org is 178.62.68.79
Mar 6 06:17:32 dnsmasq[703]: query[A] uk.pool.ntp.org from 192.168.2.193
Mar 6 06:17:32 dnsmasq[703]: forwarded uk.pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 136.243.66.91
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 141.30.228.4
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 193.141.27.1
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is 85.236.36.4
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply pool.ntp.org is NODATA-IPv6
Mar 6 06:17:32 dnsmasq[703]: query[A] pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: query[AAAA] pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS
Mar 6 06:17:32 dnsmasq[703]: validation 1.north-america.pool.ntp.org is BOGUS
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 69.36.182.57
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 208.75.89.4
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 45.63.11.93
Mar 6 06:17:32 dnsmasq[703]: reply 1.north-america.pool.ntp.org is 159.203.8.72
Mar 6 06:17:32 dnsmasq[703]: query[A] 1.north-america.pool.ntp.org from 127.0.0.1
Mar 6 06:17:32 dnsmasq[703]: forwarded 1.north-america.pool.ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
Mar 6 06:17:32 dnsmasq[703]: dnssec-query[DS] ntp.org to 84.200.69.80
DenyDarko
on 6 Mar 2019
DenyDarko
on 6 Mar 2019
What is the contents of /etc/dnsmasq.d/01-pihole.conf? Specifically we are looking for the trust-anchor lines.
dschaper
on 6 Mar 2019
What is the contents of
/etc/dnsmasq.d/01-pihole.conf? Specifically we are looking for the trust-anchor lines.
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
DenyDarko
on 6 Mar 2019
That's good, how about the whole config file. Can you run pihole -d when it's faulting and then upload that file curl --upload-file /var/log/pihole_debug.log https://tricorder.pi-hole.net:9998 ? Just post the URL that is returned so that we can take a look.
dschaper
on 6 Mar 2019
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DS is not right, ntp.org has no DS record.
Does this happen with other upstream servers?
dschaper
on 6 Mar 2019
That's good, how about the whole config file. Can you run
pihole -dwhen it's faulting and then upload that filecurl --upload-file /var/log/pihole_debug.log https://tricorder.pi-hole.net:9998? Just post the URL that is returned so that we can take a look.
addn-hosts=/etc/pihole/gravity.list
addn-hosts=/etc/pihole/black.list
addn-hosts=/etc/pihole/local.list
localise-queries
no-resolv
cache-size=10000
log-queries
log-facility=/var/log/pihole.log
local-ttl=2
log-async
server=84.200.69.80
server=84.200.70.40
domain-needed
bogus-priv
dnssec
trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
interface=wlan0
Mar 6 06:17:32 dnsmasq[703]: reply ntp.org is BOGUS DSis not right, ntp.org has no DS record.Does this happen with other upstream servers?
Yes, Cloudflare tested. And Quad9.
I don't know if it's relevant but this happens some minutes after a reboot usually.
/var/log is mounted as tmpfs to prevent too many writes to the SD Card (Raspberry) so it's technically empty after each boot.
Debug Log pending.
DenyDarko
on 6 Mar 2019
@dschaper
https://tricorder.pi-hole.net/c45i2q87ym! (pihole_debug.log)
https://tricorder.pi-hole.net/nd9tcwq388! (pihole_debug-sanitized.log)
DenyDarko
on 12 Mar 2019
It looks like those files are empty. What does ls -lah /var/log/pihole* show?
dschaper
on 13 Mar 2019
https://tricorder.pi-hole.net/q15do85fh4!
https://tricorder.pi-hole.net/uzr51rmo9g!
I've run it again for both files.
Hopefully this time it has some useful stuff in there :(
@dschaper
DenyDarko
on 13 Mar 2019
https://tricorder.pi-hole.net/uzr51rmo9g/ That doesn't show any BOGUS responses in the log. Take a look at that file and at the end is a copy of the pihole.log which really doesn't show anything at all. Were you getting BOGUS results when this log was generated?
dschaper
on 13 Mar 2019
I have just observed this issue as well. My power went out yesterday, and on reboot my pihole was recording "BOGUS" for all domains using quad9. Turning of dnssec solved the issue, but that's certainly not ideal.
Mar 19 10:09:41 dnsmasq[27157]: forwarded ad.afy11.net to 9.9.9.9
Mar 19 10:09:41 dnsmasq[27157]: forwarded ad.afy11.net to 149.112.112.112
Mar 19 10:09:41 dnsmasq[27157]: dnssec-query[DS] 360yield.com to 149.112.112.112
Mar 19 10:09:41 dnsmasq[27157]: validation ad.afy11.net is BOGUS
Mar 19 10:09:41 dnsmasq[27157]: reply error is SERVFAIL
pi@raspberrypi:~ $ dig @192.168.1.175 google.com
; <<>> DiG 9.10.3-P4-Raspbian <<>> @192.168.1.175 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64361
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 1080 msec
;; SERVER: 192.168.1.175#53(192.168.1.175)
;; WHEN: Sat Mar 23 06:08:54 GMT 2019
;; MSG SIZE rcvd: 39
[鉁揮 Your debug token is: https://tricorder.pi-hole.net/q3a7wf56u5!
jmoses
on 23 Mar 2019
So we can somehow safely conclude that this happens during reboot.
For me it also happens after the daily scheduled upgrade / reboot. Never randomly during the day.
PS: I didn't forget about the issue, just waiting for it to happen again.
DenyDarko
on 23 Mar 2019
Ah, I had that thought too. When I had initially enabled DNSSEC it worked just fine, and this was the first time the pi had been rebooted.
jmoses
on 23 Mar 2019
Maybe @dschaper will have more luck with your token 馃
DenyDarko
on 23 Mar 2019
If it happens during reboot the I'm going to hazard a guess that the RPi has not yet reset it's time.
From the snippet below, if this happened yesterday, then the date should have been Mar 22, not Mar 19. Invalid date/time on the RPi will result in a BOGUS response, you need to have accurate time as that is part of the DNSSEC validation process.
Mar 19 10:09:41 dnsmasq[27157]: forwarded ad.afy11.net to 9.9.9.9
Mar 19 10:09:41 dnsmasq[27157]: forwarded ad.afy11.net to 149.112.112.112
Mar 19 10:09:41 dnsmasq[27157]: dnssec-query[DS] 360yield.com to 149.112.112.112
Mar 19 10:09:41 dnsmasq[27157]: validation ad.afy11.net is BOGUS
Mar 19 10:09:41 dnsmasq[27157]: reply error is SERVFAIL
@dschaper
Well technically I have ntp running and the date is correct AFAIK, maybe if we somehow delay pihole for the ntp daemon to sync the clock on reboot or if we make it call ntpdate itself before initializing of DNSSEC?
Because if you see the logs, ntp doesn't have the chance to query the ntp pool servers. It gets bogus responses.
Just random thoughts
DenyDarko
on 23 Mar 2019
Huh, I probably screwed up my grep for bogus then, and that log snippet doesn't pertain here. I still certainly saw this issue post reboot, and (currently) my time is correct.
jmoses
on 23 Mar 2019
You need DNS in order to resolve the IP of the NTP server, and you need a correct and accurate date for DNS to give you the correct IP as valid. Something else is in play here though since we don't see this as a widespread issue that affects all devices without a RTC module.
dschaper
on 23 Mar 2019
The debug log that jmoses posted shows everything working, which is what is more confusing, there are no BOGUS results.
Mar 23 00:00:13 dnsmasq[27157]: validation result is INSECURE
Mar 23 00:00:16 dnsmasq[27157]: validation result is INSECURE
Mar 23 00:00:22 dnsmasq[27157]: validation result is INSECURE
Mar 23 05:54:55 dnsmasq[466]: reply cnn.com is BOGUS DS
Mar 23 05:54:55 dnsmasq[466]: validation www.cnn.com is BOGUS
Mar 23 05:54:55 dnsmasq[466]: reply www.cnn.com is <CNAME>
Mar 23 05:54:55 dnsmasq[466]: reply turner-tls.map.fastly.net is 151.101.209.67
Mar 23 05:54:55 dnsmasq[466]: query[A] www.cnn.com from 192.168.1.107
Mar 23 05:54:55 dnsmasq[466]: forwarded www.cnn.com to 9.9.9.9
Mar 23 05:54:55 dnsmasq[466]: dnssec-query[DS] cnn.com to 9.9.9.9
Mar 23 05:54:55 dnsmasq[466]: reply cnn.com is BOGUS DS
Mar 23 05:54:55 dnsmasq[466]: validation www.cnn.com is BOGUS
Mar 23 05:54:55 dnsmasq[466]: reply www.cnn.com is <CNAME>
Mar 23 05:54:55 dnsmasq[466]: reply turner-tls.map.fastly.net is 151.101.209.67
Mar 23 05:54:55 dnsmasq[466]: query[A] www.cnn.com from 192.168.1.107
Mar 23 05:54:55 dnsmasq[466]: forwarded www.cnn.com to 9.9.9.9
Mar 23 05:54:55 dnsmasq[466]: dnssec-query[DS] cnn.com to 9.9.9.9
Mar 23 05:54:55 dnsmasq[466]: reply cnn.com is BOGUS DS
Mar 23 05:54:55 dnsmasq[466]: validation www.cnn.com is BOGUS
Yeah, here's from today, and this would have been post power failure.
ar 23 05:54:07 dnsmasq[466]: query[A] calendar.google.com from 192.168.1.151
Mar 23 05:54:07 dnsmasq[466]: forwarded calendar.google.com to 149.112.112.112
Mar 23 05:54:07 dnsmasq[466]: forwarded calendar.google.com to 9.9.9.9
Mar 23 05:54:07 dnsmasq[466]: dnssec-query[DS] com to 149.112.112.112
Mar 23 05:54:07 dnsmasq[466]: dnssec-query[DNSKEY] . to 149.112.112.112
Mar 23 05:54:07 dnsmasq[466]: reply . is DNSKEY keytag 16749, algo 8
Mar 23 05:54:07 dnsmasq[466]: reply . is DNSKEY keytag 20326, algo 8
Mar 23 05:54:07 dnsmasq[466]: reply . is DNSKEY keytag 25266, algo 8
Mar 23 05:54:07 dnsmasq[466]: reply com is DS keytag 30909, algo 8, digest 2
Mar 23 05:54:07 dnsmasq[466]: dnssec-query[DS] google.com to 149.112.112.112
Mar 23 05:54:07 dnsmasq[466]: reply google.com is BOGUS DS
Can you search for the log starting with the line I show below?
ar 23 14:07:13 dnsmasq[4899]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
Mar 23 14:07:13 dnsmasq[4899]: DNSSEC validation enabled
Mar 23 14:07:13 dnsmasq[4899]: configured with trust anchor for <root> keytag 20326
Mar 23 14:07:13 dnsmasq[4899]: configured with trust anchor for <root> keytag 19036
Mar 23 14:07:13 dnsmasq[4899]: using nameserver 149.112.112.112#53
Mar 23 14:07:13 dnsmasq[4899]: using nameserver 9.9.9.9#53
Mar 23 14:07:13 dnsmasq[4899]: read /etc/hosts - 6 addresses
Mar 23 14:07:13 dnsmasq[4899]: read /etc/pihole/local.list - 2 addresses
Mar 23 14:07:13 dnsmasq[4899]: read /etc/pihole/black.list - 0 addresses
Mar 23 14:07:16 dnsmasq[4899]: read /etc/pihole/gravity.list - 112231 addresses
Mar 23 14:07:16 dnsmasq[4899]: query[A] a.root-servers.net from 192.168.101.124
Mar 23 14:07:16 dnsmasq[4899]: forwarded a.root-servers.net to 149.112.112.112
Mar 23 14:07:16 dnsmasq[4899]: forwarded a.root-servers.net to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: query[A] a.root-servers.net from 192.168.101.124
Mar 23 14:07:16 dnsmasq[4899]: forwarded a.root-servers.net to 149.112.112.112
Mar 23 14:07:16 dnsmasq[4899]: forwarded a.root-servers.net to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: dnssec-query[DS] net to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: dnssec-query[DNSKEY] . to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: reply . is DNSKEY keytag 20326, algo 8
Mar 23 14:07:16 dnsmasq[4899]: reply . is DNSKEY keytag 16749, algo 8
Mar 23 14:07:16 dnsmasq[4899]: reply . is DNSKEY keytag 25266, algo 8
Mar 23 14:07:16 dnsmasq[4899]: reply net is DS keytag 35886, algo 8, digest 2
Mar 23 14:07:16 dnsmasq[4899]: dnssec-query[DS] root-servers.net to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: dnssec-query[DNSKEY] net to 9.9.9.9
Mar 23 14:07:16 dnsmasq[4899]: reply net is DNSKEY keytag 51638, algo 8
Mar 23 14:07:16 dnsmasq[4899]: reply net is DNSKEY keytag 35886, algo 8
Mar 23 14:07:16 dnsmasq[4899]: reply root-servers.net is no DS
Mar 23 14:07:16 dnsmasq[4899]: validation result is INSECURE
Mar 23 14:07:16 dnsmasq[4899]: reply a.root-servers.net is 198.41.0.4
Mar 23 14:07:17 dnsmasq[4899]: query[AAAA] api.segment.io from 192.168.101.102
Mar 23 14:07:17 dnsmasq[4899]: /etc/pihole/gravity.list api.segment.io is 0.0.0.0
Mar 23 14:07:17 dnsmasq[4899]: query[A] api.segment.io from 192.168.101.102
Mar 23 14:07:17 dnsmasq[4899]: /etc/pihole/gravity.list api.segment.io is 0.0.0.0
Mar 23 14:07:24 dnsmasq[4899]: query[A] a.root-servers.net from 192.168.101.124
Mar 23 14:07:24 dnsmasq[4899]: cached a.root-servers.net is 198.41.0.4
Mar 23 14:07:34 dnsmasq[4899]: query[A] a.root-servers.net from 192.168.101.124
Mar 23 14:07:34 dnsmasq[4899]: cached a.root-servers.net is 198.41.0.4
Mar 23 14:07:34 dnsmasq[4899]: query[A] pi.hole from 192.168.101.163
Mar 23 14:07:34 dnsmasq[4899]: /etc/pihole/local.list pi.hole is 192.168.100.2
Mar 23 14:07:34 dnsmasq[4899]: query[AAAA] pi.hole from 192.168.101.163
Mar 23 14:07:34 dnsmasq[4899]: forwarded pi.hole to 9.9.9.9
Mar 23 14:07:34 dnsmasq[4899]: validation result is SECURE
Mar 23 05:53:10 dnsmasq[466]: started, version pi-hole-2.80 cachesize 10000
Mar 23 05:53:10 dnsmasq[466]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
Mar 23 05:53:10 dnsmasq[466]: DNSSEC validation enabled
Mar 23 05:53:10 dnsmasq[466]: configured with trust anchor for <root> keytag 20326
Mar 23 05:53:10 dnsmasq[466]: configured with trust anchor for <root> keytag 19036
Mar 23 05:53:10 dnsmasq[466]: warning: interface eth0 does not currently exist
Mar 23 05:53:10 dnsmasq[466]: using nameserver 149.112.112.112#53
Mar 23 05:53:10 dnsmasq[466]: using nameserver 9.9.9.9#53
Mar 23 05:53:10 dnsmasq[466]: read /etc/hosts - 5 addresses
Mar 23 05:53:10 dnsmasq[466]: read /etc/pihole/local.list - 2 addresses
Mar 23 05:53:10 dnsmasq[466]: failed to load names from /etc/pihole/black.list: No such file or directory
Mar 23 05:53:11 dnsmasq[466]: read /etc/pihole/gravity.list - 27282 addresses
Mar 23 05:53:20 dnsmasq[466]: query[AAAA] bolt.dropbox.com from 192.168.1.151
Mar 23 05:53:20 dnsmasq[466]: forwarded bolt.dropbox.com to 149.112.112.112
Mar 23 05:53:20 dnsmasq[466]: forwarded bolt.dropbox.com to 9.9.9.9
Mar 23 05:53:20 dnsmasq[466]: query[A] scribe.logs.roku.com from 192.168.1.174
Mar 23 05:53:20 dnsmasq[466]: forwarded scribe.logs.roku.com to 149.112.112.112
Mar 23 05:53:20 dnsmasq[466]: forwarded scribe.logs.roku.com to 9.9.9.9
Mar 23 05:53:21 dnsmasq[466]: query[A] calendar.google.com from 192.168.1.151
Mar 23 05:53:21 dnsmasq[466]: forwarded calendar.google.com to 149.112.112.112
Mar 23 05:53:21 dnsmasq[466]: forwarded calendar.google.com to 9.9.9.9
Mar 23 05:53:22 dnsmasq[466]: query[A] Dc-na02-uSeaSt1.conNECT.SmarTThIngS.cOM from 192.168.1.217
Mar 23 05:53:22 dnsmasq[466]: forwarded Dc-na02-uSeaSt1.conNECT.SmarTThIngS.cOM to 149.112.112.112
Mar 23 05:53:22 dnsmasq[466]: forwarded Dc-na02-uSeaSt1.conNECT.SmarTThIngS.cOM to 9.9.9.9
Mar 23 05:53:23 dnsmasq[466]: query[A] 192-168-1-151.79d54f535ac7416f89f12d68bf8406dd.plex.direct from 192.168.1.174
Mar 23 05:53:23 dnsmasq[466]: forwarded 192-168-1-151.79d54f535ac7416f89f12d68bf8406dd.plex.direct to 149.112.112.112
Mar 23 05:53:23 dnsmasq[466]: forwarded 192-168-1-151.79d54f535ac7416f89f12d68bf8406dd.plex.direct to 9.9.9.9
Mar 23 05:53:25 dnsmasq[466]: query[A] play.google.com from 192.168.1.151
Mar 23 05:53:25 dnsmasq[466]: forwarded play.google.com to 149.112.112.112
Mar 23 05:53:25 dnsmasq[466]: forwarded play.google.com to 9.9.9.9
Mar 23 05:53:25 dnsmasq[466]: query[A] docs.google.com from 192.168.1.151
Mar 23 05:53:25 dnsmasq[466]: forwarded docs.google.com to 149.112.112.112
Mar 23 05:53:25 dnsmasq[466]: forwarded docs.google.com to 9.9.9.9
Immediately before that is the blob of binary data, which is odd.
jmoses
on 23 Mar 2019
Binary data? The log file shouldn't have anything other than ascii output with datestamps on each line.
Can you post the binary data that you are seeing?
dschaper
on 23 Mar 2019
I can, but I think the overall issue is related to time. The last time dnsmasq would have restarted would have been at like, 09-ish eastern, but that latest "compile time" line shows 6UTC (2a, easter) as the time, and then I have these log lines back to back:
Mar 23 06:15:00 dnsmasq[1736]: reply 0.debian.pool.ntp.org is 96.244.96.19
Mar 23 06:15:00 dnsmasq[1736]: reply 0.debian.pool.ntp.org is 185.41.243.30
Mar 23 06:15:00 dnsmasq[1736]: reply 0.debian.pool.ntp.org is 85.21.78.91
Mar 23 06:15:00 dnsmasq[1736]: reply 0.debian.pool.ntp.org is 139.162.219.252
...snipped....
Mar 23 06:15:01 dnsmasq[1736]: forwarded 10.112.112.149.in-addr.arpa to 149.112.112.10
Mar 23 13:19:21 dnsmasq[1736]: reply 149.112.112.10 is NXDOMAIN
And that's about _exactly_ when I disabled DNSSEC and things started working again. I bet the scenario is the system boots with a time that's invalid enough to break DNSSEC and then can't get properly validated results for the NTP server DNS lookup, and thus can't set it's time to be able to properly validate the DNSSEC results, and repeat until DNSSEEC is disabled
jmoses
on 23 Mar 2019
$ dig @192.168.1.175 google.com
; <<>> DiG 9.8.3-P1 <<>> @192.168.1.175 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 794
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 50 msec
;; SERVER: 192.168.1.175#53(192.168.1.175)
;; WHEN: Sat Mar 23 09:17:17 2019
;; MSG SIZE rcvd: 28
$ dig @192.168.1.175 google.com
; <<>> DiG 9.8.3-P1 <<>> @192.168.1.175 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3293
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 234 IN A 172.217.7.14
;; Query time: 24 msec
;; SERVER: 192.168.1.175#53(192.168.1.175)
;; WHEN: Sat Mar 23 09:19:05 2019
;; MSG SIZE rcvd: 44
Interesting article:
So again, I suspect we somehow need to allow the device to update its time before enabling DNSSEC queries.
DenyDarko
on 23 Mar 2019
Yeah, and mine certainly doesn't have an RTC, it's a rev, uh, b?
jmoses
on 23 Mar 2019
I would definitely suggest an RTC module for the RPi if you are going to be running something that is time sensitive like DNSSEC. They are very inexpensive and most are just hats that slip on the headers. No RPi board has RTCs on board as that requires a battery to keep the time.
dschaper
on 23 Mar 2019
Is software solution considered a possibility though?
Like an option for "DNSSEC excluded" hosts (for ntp pool) or something like that?
DenyDarko
on 23 Mar 2019
There isn't a software solution that is feasible. It's a lack of necessary hardware on the Pi.
dschaper
on 23 Mar 2019
ebay it is then
DenyDarko
on 23 Mar 2019
I guess you could be a geek like me and set up your own NTP server at your location and then you wouldn't need to be going off network for a timeserver. Some router firmwares also will allow you to turn the router in to an NTP server that could be used on the local network segment as well.
dschaper
on 23 Mar 2019
The whole point of my Pi is having a small low consumption machine with all the required services for my lan (dns, dhcp, ,ntp, flightaware feeding, etc etc xD).
If I have to install another piece of hardware for NTP it defeats the whole purpose of my Pi.
Long story short I've already ordered an RCT module. Their cost is next to nothing xD
DenyDarko
on 23 Mar 2019
Yes, RTC's are cheap. Since you are running an ADS-B service you might want to add GPS as something to add as an extra toy. With most GPS receivers you can take the output and the PPS pulse-per-second signal and create your own Stratum 1 NTP server. (That's what I do, and my feeder is very accurate for MLAT calculation, and then provides my whole network with NTP services.) GPS is a little more expensive than just and RTC but you get a whole lot more use out of it.
dschaper
on 23 Mar 2019
I haven't heard of roughtime, but tlsdate will not work since it needs to talk to a remote endpoint that is declared as a URL and you need DNS to convert that URL into IP.
dschaper
on 23 Mar 2019
Maybe this time thing with DNSSEC should be shown as warning or something when raspberry is detected.
Hopefully I'm done with this annoying issue:
DenyDarko
on 27 Mar 2019
@DenyDarko what RTC did you end up ordering, sir? I saw Adafruit had a couple available, but the DS3231 is the only one considered to be precise enough? My apologies in advance, this was just something I recently ran up against and know almost nothing. Using RPi 3 B+ as my secondary name server, but if/when the primary goes down, I've been having some issues with my RPi taking over. Just configured my router to be NTP server for LAN (as it synchronizes with Stratum 1 servers), but apparently that's not enough.
Was considering taking a chance with one of these (as you so aptly noted, the costs are negligible): https://www.amazon.com/gp/product/B01M105UFC/
peatrick
on 27 Mar 2019
@DenyDarko what RTC did you end up ordering, sir? I saw Adafruit had a couple available, but the DS3231 is the only one considered to be precise enough? My apologies in advance, this was just something I recently ran up against and know almost nothing. Using RPi 3 B+ as my secondary name server, but if/when the primary goes down, I've been having some issues with my RPi taking over. Just configured my router to be NTP server for LAN, but apparently that's not enough.
Was considering taking a chance with one of these (as you so aptly noted, the costs are negligible): https://www.amazon.com/gp/product/B01M105UFC/
The one quoted is totally fine.
I got one DS3231 myself. :)
And follow this guide (Ignore the wiring part obviously):
DenyDarko
on 27 Mar 2019
Thank you kindly, sir. You are nice! Ordered... will arrive Friday afternoon. Appreciate the assistance trying to help me resolve my particular brand of madness. This community is fantastic. Can't wait to get this little guy upgraded:
That UPS battery should run all my important networking gear (ONT, Edgerouter, Wireless AP via PoE and RPi, with Pi-hole, Unbound & OpenVPN server) for up to ~2.5 hours in the event we lose power. Truly appreciate the assistance. Thanks for allowing me to copy your great idea(s), fellas. Be safe, happy hump day, gents.
EDIT: I'd been tempted to try one of the "new" PoE hats for the RPi when they came out, but glad I held off, as i read about a bunch of issues with the first gen that were released.
peatrick
on 27 Mar 2019
@DenyDarko thank you kindly for the _extremely_ helpful link, as well as original product recommendation/confirmation. Without your link, I probably would have struggled to get this setup properly, as the documentation I was originally referring to (from thepihut.com) appears to be incredibly outdated and varied quite dramatically from what you provided.
$6.99 USD well spent:
I'm not sure why my router isn't accepting peers for the NTP daemon/server I had setup, possibly due to the fact that much of my custom configurations were written over when I updated firmware this past week and I neglected to realize it, but that's an entirely different topic. Really pumped about the state of
the upgraded RPi 3 B+ Pi-hole, which seems silly, considering the fact that I wasn't even aware that the device didn't have its own real-time clock until earlier this week. Many thanks, to all who have helped and continue to contribute to this amazing community and project!
peatrick
on 30 Mar 2019
After reading all the comments here it looks like not only the raspberry but also the Odroid XU4 (which I am using) is haveing this issue - it starts around 2:00 a.m. and lasts till DNSSEC is switched on/off - all queries come from localhost, going to *.debian.pool.ntp.org.
I'm currently trying to ship around this issue by setting a local ntp server up on another host.
It would be nice to have a warning during install or at the webui if thats possible for those devices lacking a suiteable clock.
Edit:
This could be a DietPi issue, since the default installation for time sync mode is boot & daily which would explain the exact same time of dns failing every night.
The solution for me is using an IP for NTP server (dietpi-config > Network Options: Misc > NTP mirror)
I could reliably reproduce the behaviour via systemctl restart systemd-timesyncd
No Problems with IP but failing with a name to resolv first.
I don't know if this is more a pi-hole or a dietpi issue but i felt maybe those hints could help others in trouble.
Cardes
on 4 Jun 2019
@Cardes i know this probably isn't the solution you are looking for, but after a fair bit of trial and error with various RPi devices (Raspberry Pi 3 B, Raspberry Pi 3 B+ & Pi Zero W) I finally settled on adding a ~six dollar real-time clock to put these DNSSEC issues in the past. I believe you can pick up an ODroid compatible RTC for $4.50, obviously YMMV: https://www.hardkernel.com/shop/rtc-shield/
RTC Shield
SKU: G146000366985
There's a specific section in the Wiki that advises against using an NTP server. I believe (don't quote me on this without doing your own research, as I'm far from an expert), but I have come to believe that the issue stems from the simple fact that in order to obtain accurate DNSSEC information from an NTP server, the networking stack in any of these devices needs to be up/online, which doesn't happen early enough in the boot process -- I was trying to force the issue by applying this fake-hwclock module (you mentioned DietPi, so this generic Debian related guide should apply to your situation): https://manpages.debian.org/jessie/fake-hwclock/fake-hwclock.8.en.html
Good luck, hoping you are able to overcome the issues. My choices came down to disabling DNSSEC, dealing with the constant issues, or simply adding the proper hardware to accurately support it. Obviously I chose the latter -- it was a wake-up call, as most machines we've used in our lives were equipped with a simple hardware clock, but that involves batteries and other messiness. Again, YMMV. I've also had fantastic success running my own little recursive DNS server(s) in-house, using Pi-hole with Unbound, but DNS over HTTPS & DNS over TLS are also good options. All depends who you can, or will want to place your trust in. Good luck, sir!
EDIT: Check @dschaper 's comment from above (March 23), he provides the answer to your question(s):
There isn't a software solution that is feasible. It's a lack of necessary hardware on the Pi.
peatrick
on 5 Jun 2019
@peatrick thanks a lot for all those good hints. I'm in the lucky situation that my router has a reliable NTP server - the wiki article is (as far as i can tell) only warning for the RTC&NTP combination on the same machine as this can cause problems while rebooting.
I also did make a very fantastic experience with pi-hole and unbound and just tried to add some redudancy 'cause i had this spare odroid... i think some of the most time consuming stories start with such a tiny little idea :)
Anyways, now i got 2 exact same configured pi-hole machines and no more trouble updating & rebooting one of them cause the other one is keeping my "internet" alive, yay!
Cardes
on 5 Jun 2019
in the lucky situation that my router has a reliable NTP server
Mind if i inquire what router you are using? I started out with a little Edgerouter and recently upgraded to an early release store model and have been thrilled with it (running firmware v2.0.3). My primary Pi-hole (+Unbound) runs on a little Ubuntu Server 18.04.2 VM and secondary (Pihole + Unbound and OpenVPN Server) is the RPi 3 B+ _running Raspbian GNU/Linux 9.9 (stretch)_, but i totally feel ya on having redundancy, especially considering the fact that my VM runs on top of a type 2 Windows 10 w/ Hyper-V host, obviously Windows Updates can cause issues a couple/few times a year.
Glad things are working out nicely for you, @Cardes sir. I can't take any credit here, it's all shared experiences and expertise from the likes of @dschaper, @DL6ER, et al. Fantastic community that only makes an amazing product that much better. I push Pi-hole on a lot of folks and couldn't imagine browsing without it (hence the value added of OpenVPN server).
EDIT: Added (italics) Pi-hole OS version.
peatrick
on 5 Jun 2019
It's an AVM Fritzbox, those things are rock solid but i have no idea if those are available in your region.
Hrm I don't whant do "spam" this Issue with off-topic stuff, is there not some kind of direct PM or so to discuss something? sad
Anyways:
My goals seems to be the same as yours, surfing without to much of a disturbance from fullscreen vids and stuff. Pi-hole really saves every single day here so i got one running as VM on an KVM Host which lies in a DMZ between router and opnsense firewall together with the second pi-hole on the odroid which is also my ipv6 gateway (because my ISP is oldschool and serves only ipv4 grr). I'm not using openvpn as this is so painfull to configure compaired to wireguard which is setup in minutes to serve as gateway for roadwarriors. I was suprised how well the odroid is handling encryption load, even faster than the KVM Host which was way more expensive.
Good day to you!
Cardes
on 5 Jun 2019
Is it possible to disable DNSSEC for a few domains?
arjunak234
on 29 Jul 2019
@arjunak234 Ask on our community forum at https://discourse.pi-hole.net and your question will be seen by a lot more people.
dschaper
on 29 Jul 2019
I also noticed something weird regarding the main topic of this issue (DNSSEC and bogus) :
When DNSSEC is enabled, it resolves my local domain just fine (insecure of course) but delivers SERVFAIL (bogus) on PTR-records for my local lan.
I am using the following setup:
An opwnwrt-alike device as gateway, and dhcp (10.10.10.1, also runs a dns, but is not used by clients, but by pihole as only upstream resolver. it also has a knot resolver running and therefore a working dnssec-setup).
Example:
10.10.10.1: router
10.10.10.12: pihole
with dnssec on on pihole:
forward lookup:
```
root@gil:~# host mysql 10.10.10.12
Using domain server:
Name: 10.10.10.12
Address: 10.10.10.12#53
Aliases:
mysql.lan.k**x.de has address 10.10.10.13
reverse lookup:
root@gil:~# host 10.10.10.13 10.10.10.12
Using domain server:
Name: 10.10.10.12
Address: 10.10.10.12#53
Aliases:
Host 13.10.10.10.in-addr.arpa not found: 2(SERVFAIL)
with dnssec `off` on pihole:
forward lookup:
```
root@gil:~# host mysql 10.10.10.12
Using domain server:
Name: 10.10.10.12
Address: 10.10.10.12#53
Aliases:
mysql.lan.k**x.de has address 10.10.10.13
reverse lookup:
root@gil:~# host 10.10.10.13 10.10.10.12
Using domain server:
Name: 10.10.10.12
Address: 10.10.10.12#53
Aliases:
13.10.10.10.in-addr.arpa domain name pointer mysql.lan.k**x.de.
Of course the next upstream-resolver on my lan (the gateway) gives a correct PTR:
root@gil:~# host 10.10.10.13 10.10.10.1
Using domain server:
Name: 10.10.10.1
Address: 10.10.10.1#53
Aliases:
13.10.10.10.in-addr.arpa domain name pointer mysql.lan.k**x.de.
I also noticed, that with DNSSEC on, PTR-Records on the Internet take unusually long comapred to their forward counterparts, even if for both records DNSSEC is not available (>1sec, compared a few addresses of random websites like "heise.de").
zeus86
on 23 Aug 2020
Ask on our community forum at https://discourse.pi-hole.net and your question will be seen by a lot more people
dschaper
on 23 Aug 2020
Related issues
ghalfacree
路
32Comments
technicalpyro
路
46Comments
asoliman
路
33Comments
emmtte
路
33Comments
ghost
路
36Comments
Most helpful comment
It's an AVM Fritzbox, those things are rock solid but i have no idea if those are available in your region.
Hrm I don't whant do "spam" this Issue with off-topic stuff, is there not some kind of direct PM or so to discuss something? sad
Anyways:
My goals seems to be the same as yours, surfing without to much of a disturbance from fullscreen vids and stuff. Pi-hole really saves every single day here so i got one running as VM on an KVM Host which lies in a DMZ between router and opnsense firewall together with the second pi-hole on the odroid which is also my ipv6 gateway (because my ISP is oldschool and serves only ipv4 grr). I'm not using openvpn as this is so painfull to configure compaired to wireguard which is setup in minutes to serve as gateway for roadwarriors. I was suprised how well the odroid is handling encryption load, even faster than the KVM Host which was way more expensive.
Good day to you!