Hello Jon,
I am not an expert either.
So here is my updated system version that my IFFire box is on:
|IPFire version|IPFire 2.25 (x86_64) - core153|
|Pakfire version|2.25-x86_64|
I was showing the ever increasing number with date, your dates are built in, I like it.
The cmd line of yours, shows what happened for that week of the log file, restricting to the last 12 weeks/files.
Below is a screen shot of the weekly numbers.
Here is a screen shot of the DNS server page:
Hopefully we’ll learn something new!
Have you always had Protocol for DNS queries set to TCP? Or did that change in December 2020 (when the numbers were high > 100,000)??
Let’s try a few things.
Just so we have something to compare, this is what I see:
Jon, if I may add (to improve readability of the output), the command can be:
zgrep -ic "SERVFAIL" $(ls /var/log/messages* | sort -rV | tail -12) | sed 's/:/\t\t/'
/var/log/messages.11.gz 2668
/var/log/messages.10.gz 4
/var/log/messages.9.gz 11
/var/log/messages.8.gz 219
/var/log/messages.7.gz 8
/var/log/messages.6.gz 5
/var/log/messages.5.gz 9
/var/log/messages.4.gz 70
/var/log/messages.3.gz 1
/var/log/messages.2.gz 76
/var/log/messages.1.gz 3
/var/log/messages 5Thanks!
I had something similar but I wanted to know the file date.
@agibson - did things get any better? Different? Or?
@jon
I am giving it a bunch of days/weeks to get a reliable set of data.
Yes, I did all three items. I also set the Protocol of TCP, back to UDP.
@anon42188109 I like the dates to show with the log files. My preference. Now if the two methods could be combined for simple list with dates, that would be my new preference.
FYI - depending on what you see in the log files, the next step will be to change the Protocol for DNS queries to TLS.
@agibson this script will do what you asked
for f in $(ls /var/log/messages* | sort -rV | tail -12) ; do
fl=`ls -l $f`
zg=`zgrep -ic "SERVFAIL" $f`
printf "%s \t %s \n" "$fl" "$zg"
doneThe week is not done yet, but 920 is already much larger of a failure rate, than the 133-229 range of most weeks sense adding more DNS servers back in December when the rate was 23910-312525 range. The week of Feb 7 did see a crazy blip of 6737, that was before the changes that you, Jon, recommended trying. So with this data so far, is that enough to make a change to Protocol for DNS queries?
(Note: I still restart the IPFire network when some one in the house can not connect to a webpage. /etc/init.d/network restart Afterwards the webpage is accessible. This happens daily. )
for f in $(ls /var/log/messages* | sort -rV | tail -12) ; do fl=ls -l $f; zg=zgrep -ic "SERVFAIL" $f; printf “%s \t %s \n” “$fl” “$zg”; done
-rw-rw-r-- 1 root syslogd 6941020 Dec 6 00:01 /var/log/messages.11.gz 23910
-rw-rw-r-- 1 root syslogd 14964988 Dec 13 00:01 /var/log/messages.10.gz 148738
-rw-rw-r-- 1 root syslogd 3592199 Dec 20 00:01 /var/log/messages.9.gz 312525
-rw-rw-r-- 1 root syslogd 1883729 Dec 27 00:01 /var/log/messages.8.gz 212
-rw-rw-r-- 1 root syslogd 2539957 Jan 3 00:01 /var/log/messages.7.gz 193
-rw-rw-r-- 1 root syslogd 2437623 Jan 10 00:01 /var/log/messages.6.gz 133
-rw-rw-r-- 1 root syslogd 2822581 Jan 17 00:01 /var/log/messages.5.gz 135
-rw-rw-r-- 1 root syslogd 3355512 Jan 24 00:01 /var/log/messages.4.gz 148
-rw-rw-r-- 1 root syslogd 3170878 Jan 31 00:01 /var/log/messages.3.gz 228
-rw-rw-r-- 1 root syslogd 3903727 Feb 7 00:01 /var/log/messages.2.gz 6737
-rw-rw-r-- 1 root syslogd 2539309 Feb 14 00:01 /var/log/messages.1.gz 229
-rw-rw-r-- 1 root syslogd 53491831 Feb 19 13:47 /var/log/messages 920
Go for it and change the Protocol for DNS queries to TLS .
I enabled TLS for Protocol for DNS.
Here is a screen shot of dns servers:
Even though dns says it is broken, I tried a few sights and they still resolved and loaded.
The “SERV FAIL” count is going up rather fast. Let’s see what type of complaints I get.
Here is the SERV FAIL Count before the post/TLS change and six minutes later
-rw-rw-r-- 1 root syslogd 5304001 Feb 21 12:40 /var/log/messages 48
-rw-rw-r-- 1 root syslogd 5384913 Feb 21 12:46 /var/log/messages 209
There should not be an error. click on the pencil for 9.9.9.9. And post the screenshot
Keep in mind that you need to specify a correct domain name on the entry when you’re using TLS for DNS and this is because Transport Layer Security (TLS) does both encryption of DNS traffic and verification of the server-end which is designed to ensure that you are talking to the intended server and not a spoofed/malicious MITM attacker server.
With that in mind, ensure that the domain name that you set is:
dns.quad9.net
It’s supposed to work already provided you supplied the correct domain name for the ip address. In this case, that domain name points to 9.9.9.9 and I double checked it using nslookup so you should be good unless a different problem exists i.e. your ISP blocking/dropping outbound packets to port 853.
I only had the “9.9.9.9” and “test” when I first entered the option months ago. It appears that the DNS Server screen only displays the rDNS, not what was entered in the pencil screen. Live and learn.
9.9.9.9 now has a dns name of “dns.quad9.net”, so this field is now showing “OK” with TLS set, the main DNS Status is “Broken” still. (Update: after writing this, I checked again and now Status is “Working”.)
Here are the “SERVFail” numbers from the flawed broken 9.9.9.9 entry single DNS server, I will let it run for a while and see if the number increases for the new fixed “dns.quad9.net” “9.9.9.9” entry. Wow, wellover 39000 attributed to the misconfigured TLS 9.9.9.9 entry.
| -rw-rw-r-- 1 root syslogd 4118509 Feb 21 00:01 /var/log/messages.1.gz | 979 |
|---|---|
| -rw-rw-r-- 1 root syslogd 29545092 Feb 23 10:05 /var/log/messages | 38783 |
Glad to know it’s working now.
Spread the word and encourage your friends to use DoT! 
