"dig @1.0.0.1 microsoft.com" is working (4 address(s)) but when, "dig microsoft.com" no address(s)
Cloudflare both primary and secondary are selected
How do I troubleshoot this, also where is the debug token I was expecting it to be at the end of pihole -d when it says ** FINISHED DEBUGGING! ** I see nothing that looks like a token
i̶t̶ ̶a̶p̶p̶e̶a̶r̶s̶ ̶t̶o̶ ̶b̶e̶ ̶a̶ ̶R̶a̶s̶p̶b̶i̶a̶n̶ ̶B̶u̶s̶t̶e̶r̶ ̶p̶r̶o̶b̶l̶e̶m̶
why is it not using the default route, "route -n" everything looks fine
Did you answer Yes to the question that followed that line? If you answer yes, the debug log uploads and you get a token in return.
[✓] ** FINISHED DEBUGGING! **
* The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
* For more information, see: https://pi-hole.net/2016/11/07/crack-our-medical-tricorder-win-a-raspberry-pi-3/
* If available, we'll use openssl to upload the log, otherwise it will fall back to netcat.
[?] Would you like to upload the log? [y/N]
[✓] ** FINISHED DEBUGGING! **
* The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
* For more information, see: https://pi-hole.net/2016/11/07/crack-our-medical-tricorder-win-a-raspberry-pi-3/
* If available, we'll use openssl to upload the log, otherwise it will fall back to netcat.
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
[✗] There was an error uploading your debug log.
also, ping 8.8.8.8 works
This will temporarily reset the nameserver on the Pi to bypass Pi-Hole DNS.
sudo nano /etc/resolv.conf
edit nameserver 127.0.0.1 to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit
Run pihole -d and upload the debug log
Your Pi has the following IP:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.1.2/24 matches the IP found in /etc/pihole/setupVars.conf
But, it is looking for a gateway on a different IP range:
[i] Default IPv4 gateway: 192.168.100.1
* Pinging 192.168.100.1...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)
This may be a recent problem, as Pi-Hole shows the following activity for the previous 24 hours:
[2019-10-01 06:07:16.549 30036] Imported 4983 queries from the long-term database
[2019-10-01 06:07:16.550 30036] -> Total DNS queries: 4983
[2019-10-01 06:07:16.550 30036] -> Cached DNS queries: 904
[2019-10-01 06:07:16.550 30036] -> Forwarded DNS queries: 3738
[2019-10-01 06:07:16.550 30036] -> Exactly blocked DNS queries: 242
[2019-10-01 06:07:16.550 30036] -> Unknown DNS queries: 99
[2019-10-01 06:07:16.550 30036] -> Unique domains: 154
[2019-10-01 06:07:16.550 30036] -> Unique clients: 17
[2019-10-01 06:07:16.550 30036] -> Known forward destinations: 7
It appears that you are located in the US? But, the timezone on the Pi is set to Great Britain.
The log output shows a date/time that has not yet been achieved in the US. Incorrect time can also impact DNSSEC authentication, and you have DNSSEC enabled.
*** [ INITIALIZING ]
[i] 2019-10-01:06:11:39 debug log has been initialized.
I temporarily turned off DNSSEC and it resolves names as normal.
DNSSEC is back on, Changing timezone to local and rebooting still not working with DNSSEC on
time on the pihole is 30 sec slow
debian.pool.ntp.org is 30 sec slow, after changing time servers time is correct but still not working with dnssec turned on.
Please upload a new debug log and post the token. The old log has expired.
What is the output of this command from the Pi terminal:
dig cnn.com
dig cnn.com
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37580
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com. IN A
;; Query time: 613 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct 11 23:12:44 CDT 2019
;; MSG SIZE rcvd: 36
One of the servers pihole is using is Cloudflare the pihole can reach Cloudflare
dig cnn.com @1.0.0.1
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> cnn.com @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59235
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com. IN A
;; ANSWER SECTION:
cnn.com. 60 IN A 151.101.1.67
cnn.com. 60 IN A 151.101.193.67
cnn.com. 60 IN A 151.101.129.67
cnn.com. 60 IN A 151.101.65.67
;; Query time: 568 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Oct 11 23:14:34 CDT 2019
;; MSG SIZE rcvd: 100
When you dig for cnn.com using the Cloudflare DNS, you don't go through Pi-Hole, so this command is not using DNSSEC.
When you disable DNSSEC on Pi-Hole, you are able to complete the dig using Pi-Hole DNS?
With dnssec turned off...
also is there a way to dig with dnssec?
dig cnn.com
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38645
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com. IN A;; ANSWER SECTION:
cnn.com. 24 IN A 151.101.129.67
cnn.com. 24 IN A 151.101.65.67
cnn.com. 24 IN A 151.101.193.67
cnn.com. 24 IN A 151.101.1.67;; Query time: 137 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Oct 11 23:33:32 CDT 2019
;; MSG SIZE rcvd: 10
From man dig
pi@Pi-3B-DEV:~ $ man dig
QUERY OPTIONS
dig provides a number of query options which affect the way in which lookups are made and the results displayed. Some of these set or reset flag bits in the query header, some determine which sections of the answer get printed, and others determine the timeout and retry strategies.
Each query option is identified by a keyword preceded by a plus sign (+). Some keywords set or reset an option. These may be preceded by the string no to negate the meaning of that keyword. Other keywords assign values to options like the timeout interval. They have the form +keyword=value. Keywords may be abbreviated, provided the abbreviation is unambiguous; for example, +cd is equivalent to +cdflag. The query options are:
**+[no]dnssec**
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional section of the query
Whether the time is correct or wrong by a few hours the response is the same, Can I have an example syntax for dig with dnssec?
dig @1.0.0.1 cnn.com [no]dnssec
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> @1.0.0.1 cnn.com [no]dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14005
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com. IN A;; ANSWER SECTION:
cnn.com. 13 IN A 151.101.193.67
cnn.com. 13 IN A 151.101.129.67
cnn.com. 13 IN A 151.101.1.67
cnn.com. 13 IN A 151.101.65.67;; Query time: 523 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Oct 11 23:46:01 CDT 2019
;; MSG SIZE rcvd: 100;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26398
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;[no]dnssec. IN A;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019101101 1800 900 604800 86400;; Query time: 291 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri Oct 11 23:46:02 CDT 2019
;; MSG SIZE rcvd: 114
R̶a̶s̶p̶b̶e̶r̶r̶y̶ ̶p̶i̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶a̶p̶e̶a̶r̶ ̶t̶o̶ ̶h̶a̶v̶e̶ ̶a̶ ̶R̶T̶C̶,̶ ̶a̶f̶t̶e̶r̶ ̶r̶e̶b̶o̶o̶t̶ ̶c̶l̶o̶c̶k̶ ̶i̶s̶ ̶3̶0̶ ̶s̶e̶c̶ ̶s̶l̶o̶w̶ ̶i̶t̶ ̶t̶a̶k̶e̶s̶ ̶l̶o̶n̶g̶ ̶t̶i̶m̶e̶ ̶b̶e̶f̶o̶r̶e̶ ̶c̶l̶o̶c̶k̶ ̶s̶y̶n̶c̶h̶r̶o̶n̶i̶z̶e̶;̶ ̶d̶e̶b̶i̶a̶n̶.̶p̶o̶o̶l̶.̶n̶t̶p̶.̶o̶r̶g̶ ̶s̶e̶e̶m̶s̶ ̶f̶i̶n̶e̶ ̶j̶u̶s̶t̶ ̶h̶a̶v̶e̶ ̶t̶o̶ ̶w̶a̶i̶t̶ ̶a̶ ̶f̶e̶w̶ ̶h̶o̶u̶r̶s̶ ̶o̶r̶ ̶m̶a̶n̶u̶a̶l̶ ̶s̶y̶n̶c̶h̶r̶o̶n̶i̶z̶e̶,̶ ̶o̶n̶c̶e̶ ̶s̶y̶n̶c̶h̶r̶o̶n̶i̶z̶e̶d̶ ̶t̶h̶e̶ ̶t̶i̶m̶e̶ ̶s̶e̶e̶m̶s̶ ̶t̶o̶ ̶s̶t̶a̶y̶ ̶s̶y̶n̶c̶h̶r̶o̶n̶i̶z̶e̶d̶.̶ 
Still no working dnssec.
Nope I was very wrong, systemd-timesyncd sets the date immediately, but huge delay before it corrects the time.
dig +dnssec cnn.com @1.0.0.1
"(dig +dnssec cnn.com @1.0.0.1 and dig cnn.com @1.0.0.1) look the same"
but dig dnssec cnn.com @1.0.0.1 has longer output: so I'm still not sure of syntax.
Ether way I cannot tell if dnssec is working or not(with dig). Dig still seems to work even if the date is two months slow.
If you look at the output, you will see it is longer because the query is trying to resolve the IP of dnssec as well as cnn.com. The syntax for options is to put a "+" in front of the option. See man dig on your Pi terminal.