Picking up on my suggestion to add dnssec-no-timecheck, for use on systems without a hardware clock, such as a raspberry pi. I've investigated this further and came to the unpleasant surprise that it takes my pi (running the latest raspbian jessie lite, all packages updated) about 15 minutes to achieve time synchronization, this after a simple reboot.
As I see the question coming, here is my NTP configuration, default configuration, just changed the servers to europe
server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org iburst
server 3.europe.pool.ntp.org iburst
This is what I did (no extra packages required - ntp-wait comes out of the box)
created /etc/cron.d/ntpcheck, containing:
@reboot root PATH="$PATH:/home/pi/" /home/pi/ntpcheck.sh
created /home/pi/ntpcheck.sh, containing:
#!/bin/bash
echo "Waiting for Time Synchronization (NTP)..."
if [[ $EUID -ne 0 ]]; then
# you are NOT root (not @reboot), no sleep, system already initialized...
:
else
# you are root (@reboot), sleep, let the system initialize...
sleep 60s
fi
/usr/sbin/ntp-wait -s 10
RETVAL=$?
if [ "$RETVAL" != "0" ];then
echo "Time NOT synchronized (NTP)!!!"
exit 1
else
echo "Time synchronized established (NTP)."
/bin/kill -HUP $(ps -e | grep 'dnsmasq' | awk '{print $1}')
fi
remarks:
- the sleep function is absolutely required, the system seems NOT ready if you remove it, the script simply fails, not even an email will be sent, as the mail system cannot find the domain.
Jan 31 18:02:53 raspberrypi sSMTP[504]: Unable to locate smtp.gmail.com
Jan 31 18:02:53 raspberrypi sSMTP[504]: Cannot open smtp.gmail.com:587 - according to the man page, ntp-wait retries a 1000 times, the -s parameter specifies there is a 10 second delay between each attempt.
- neither the ntp deamon, nor ntp-wait, send a SIGHUP signal, that would trigger dnsmasq, so we have to generate it, using kill.
Now we analyze the pihole log:
at boot time, dnsmasq loads, generating the following messages:
Jan 31 18:29:32 dnsmasq[631]: started, version 2.76 cachesize 10000
Jan 31 18:29:32 dnsmasq[631]: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
Jan 31 18:29:32 dnsmasq[631]: DNSSEC validation enabled
Jan 31 18:29:32 dnsmasq[631]: DNSSEC signature timestamps not checked until first cache reload
Jan 31 18:29:32 dnsmasq[631]: warning: ignoring resolv-file flag because no-resolv is set
Jan 31 18:29:32 dnsmasq[631]: using nameserver 127.10.10.4#5554
Jan 31 18:29:32 dnsmasq[631]: using nameserver 127.10.10.3#5553
Jan 31 18:29:32 dnsmasq[631]: using nameserver 127.10.10.2#5552
Jan 31 18:29:32 dnsmasq[631]: using nameserver 127.10.10.1#5551
Jan 31 18:29:32 dnsmasq[631]: read /etc/hosts - 9 addresses
Jan 31 18:29:32 dnsmasq[631]: read /etc/pihole/local.list - 2 addresses
Jan 31 18:29:42 dnsmasq[631]: read /etc/pihole/gravity.list - 599517 addresses
In the mean time, while we're waiting, run ps aux | grep sh, you will notice the script is in the list twice; the first reference comes from cron, the second one is the actual running script.
As the script finally completes (nervously waiting - receiving a mail with the expected echo messages), time is synchronized and the SIGHUP signal is sent, resulting in the following messages in the pihole log:
Jan 31 18:45:15 dnsmasq[631]: now checking DNSSEC signature timestamps
Jan 31 18:45:16 dnsmasq[631]: read /etc/hosts - 9 addresses
Jan 31 18:45:16 dnsmasq[631]: read /etc/pihole/local.list - 2 addresses
Jan 31 18:45:25 dnsmasq[631]: read /etc/pihole/gravity.list - 599517 addresses
As you can see, the SIGHUP signal also triggers a reload of the various lists.
My concerns, regarding DNSSEC remain, as my log is filled with INSECURE (pages do load), ABANDONED (pages don't load), BOGUS (pages don't load). I only saw SECURE a few times and can't even replicate this.
Another concern of mine are the strange replies, that keep coming up, notice the uppercase character in the domain name. Examples (some of many):
Jan 31 18:50:58 dnsmasq[631]: reply aus5.mozilla.orG is
Jan 31 19:23:00 dnsmasq[631]: reply ocsp.int-x3.letsencrypt.orG is
Jan 31 19:26:09 dnsmasq[631]: reply cdn.bizible.coM is
Jan 31 19:26:09 dnsmasq[631]: reply www.cloudflare.coM is 198.41.215.162
The strange thing here is: when using dig, the domain is resolved as expected
pi@raspberrypi:~ $ dig www.cloudflare.com @127.10.10.3 -p 5553
; <<>> DiG 9.9.5-9+deb8u9-Raspbian <<>> www.cloudflare.com @127.10.10.3 -p 5553
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25162
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 15 IN A 198.41.214.162
www.cloudflare.com. 15 IN A 198.41.215.162
;; Query time: 54 msec
;; SERVER: 127.10.10.3#5553(127.10.10.3)
;; WHEN: Tue Jan 31 19:58:19 CET 2017
;; MSG SIZE rcvd: 79
the output is identical when using dig www.cloudflare.com @127.0.0.1 -p 53
Eagerly awaiting your thoughts...