every morning when logwatch is started by a cronjob, sending of the Mail doesn't work. In pi-hole.log I've found the following lines:
May 19 06:25:24 dnsmasq[1127]: 10075 127.0.0.1/43498 query[A] smtp.strato.de from 127.0.0.1
May 19 06:25:24 dnsmasq[1127]: 10075 127.0.0.1/43498 forwarded smtp.strato.de to 127.0.0.1
May 19 06:25:24 dnsmasq[1127]: 10076 127.0.0.1/43498 query[AAAA] smtp.strato.de from 127.0.0.1
May 19 06:25:24 dnsmasq[1127]: 10076 127.0.0.1/43498 forwarded smtp.strato.de to 127.0.0.1
May 19 06:25:26 dnsmasq[1127]: 10073 127.0.0.1/36644 validation smtp.strato.de is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10074 127.0.0.1/36644 validation smtp.strato.de is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10075 127.0.0.1/43498 validation smtp.strato.de is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10076 127.0.0.1/43498 validation smtp.strato.de is BOGUS
Some hours later, when I run logwatch successfully in a terminal I find these lines in pi-hole:
May 19 08:46:42 dnsmasq[1127]: 10095 127.0.0.1/49390 query[A] smtp.strato.de from 127.0.0.1
May 19 08:46:42 dnsmasq[1127]: 10095 127.0.0.1/49390 forwarded smtp.strato.de to 127.0.0.1
May 19 08:46:42 dnsmasq[1127]: 10096 127.0.0.1/49390 query[AAAA] smtp.strato.de from 127.0.0.1
May 19 08:46:42 dnsmasq[1127]: 10096 127.0.0.1/49390 forwarded smtp.strato.de to 127.0.0.1
May 19 08:46:43 dnsmasq[1127]: * 127.0.0.1/49390 dnssec-query[DS] strato.de to 127.0.0.1
May 19 08:46:43 dnsmasq[1127]: * 127.0.0.1/49390 dnssec-query[DNSKEY] de to 127.0.0.1
May 19 08:46:43 dnsmasq[1127]: * 127.0.0.1/49390 reply de is DNSKEY keytag 39227, algo 8
May 19 08:46:43 dnsmasq[1127]: * 127.0.0.1/49390 reply de is DNSKEY keytag 10498, algo 8
May 19 08:46:43 dnsmasq[1127]: * 127.0.0.1/49390 reply strato.de is no DS
May 19 08:46:43 dnsmasq[1127]: 10095 127.0.0.1/49390 validation result is INSECURE
May 19 08:46:43 dnsmasq[1127]: 10095 127.0.0.1/49390 reply smtp.strato.de is 81.169.145.133
May 19 08:46:43 dnsmasq[1127]: 10096 127.0.0.1/49390 validation result is INSECURE
May 19 08:46:43 dnsmasq[1127]: 10096 127.0.0.1/49390 reply smtp.strato.de is 2a01:238:20a:202:55f0::1133
I can't find any event which is "disturbung" the validating of smtp.strato.de.
Any ideas?
dnsmasq (FTLDNS is based on dnsmasq 2.79) considers the domain smtp.strato.de as BOGUS, meaning invalid. There are some issues with dnsmasq, regarding DNSSEC. You can read more about it here.
For now, the best solution seems to be to either simply disable DNSSEC (on the pihole settings page) OR to implement the solution from DLER6, witch bassicly implies running pihole without DNSSEC and install unbound, witch will handle the DNSSEC evaluation far better.
That's because that domain is broken. DNSSEC Analyzer - smtp.strato.de This is why DNSSEC can be bad, one mistake and the chain breaks, they are missing a couple of necessary records.
I've already installed unbound and have unchecked DNSSEC in the pi-hole UI. But this wrong validation of smtp.strato.de happens every morning at the same time. I'm not really sure if this is a problem of the implementation of the strato servers.
But here it says "Result is insecure" (and not BOGUS) and here too. So, what happens every morning at 6:25 to get a BOGUS result? I don't have all the tools to make a root cause. Perhaps we will find a workaround (or simply disable DNSSEC?).
It's sometimes hard to figure out what's wrong.
First of all, it depends on the number of "server=" settings You have in /etc/dnsmasq.d (check all the files).
dnsmasq has a build in feature to determine witch is the fastest configured resolver (every 20 seconds OR 50 queries), you'll see (in /var/log/pihole.log) that the next query is sent to ALL resolvers. That's the speed test. This also means dnsmasq is possibly not using the same resolver all of the time (changed because of the speed test).
To check if all of your configured resolvers are giving a correct result, you need to check the result of the dig command(s)
For each resolver, you have configured, enter the command:
Replace the IP with the IP of the configured resolver, the port with the configured port for that resolver, and optionally the domain. I always use www.raspberrypi.org, because it has a perfect score here. Repeat the DIG test for every configured resolver, the results should be identical.
If your using dnscrypt-proxy v2, remember that dnscrypt-proxy also has a build in speed test, and switches automatically to the fastest configured dnscrypt service. So to make the results of the DIG test accurate, you need to (temporary) limit the dnscrypt-proxy configuration to one (1) resolver, reconfiguring each time to test them all...
However, regarding the smtp.strato.de domain, @DanSchaper correctly identified the problem, their DNSSEC records really s**k, I'm getting the same result here.
You can also use the DIG test to check any resolver, that is, if your firewall allows it, for instance, for google:
dig @8.8.8.8 -p 53 +dnssec www.raspberrypi.org
You might consider repeating this test with the resolver, before you reconfigured your system (the resolver you were using when you started the topic).
@jpgpi250 thanks for your hints using dig. But I still can't find the root cause. All dig-commands are giving the same and correct result.
One thing I've found was a wrong entry in my ssmtp.conf which explains other errors like "Domain does not exist". But the validation of smtp.strato.de was successful at this time:
May 20 04:30:13 xxxxxxxx SMTP[8283]: Creating SSL connection to host
May 20 04:30:13 xxxxxxxx sSMTP[8283]: SSL connection using RSA_AES_256_CBC_SHA1
May 20 04:30:14 xxxxxxxx sSMTP[8283]: RCPT TO:<message@xxxxxxxx .demessage> (521 5.1.2 Domain does not exist: xxxxxxxx .demessage)
May 20 07:03:13 xxxxxxxx sSMTP[28436]: Unable to locate smtp.strato.de
May 20 07:03:13 xxxxxxxx sSMTP[28436]: Cannot open smtp.strato.de:587
To improve this I will try to run a script testing mail before and after restarting some services.
Never the less you are right, this domain is badly configured....
Given the fact you're trying to send email from your raspberry (or whatever your distro is), you obviously have configured your system to do so. I've been doing exactly the same for quite some time now, using gmail. You can see how I set it up here (section 4/9 - Install mail). You might need to whitelist 'users.telenet.be', I've heard from some readers the domain is in some lists, used by pihole.
If You're having so much trouble with 'smtp.strato.de', you could try to simply use the IP address (81.169.145.133) in the configuration, this eliminates the DNS lookups. I' don't think 'strato.de' will be changing the IP address any time soon (inconvenient for there customers). This would eliminate the need to restart services.
ns1.strato.de. 86400 IN A 193.141.3.6
ns2.strato.de. 86400 IN A 81.169.144.234
ns3.strato.de. 86400 IN A 195.122.141.2
ns3.strato.de. 86400 IN AAAA 2a00:e10:2004::2
ns4.strato.de. 86400 IN A 192.166.192.4
ns4.strato.de. 86400 IN AAAA 2a01:238:e100:192::4
I've tested them all, using DIG commands, there seems to be nothing wrong with their configuration, all their server report the same record info. Normally, if you're using unbound as the ONLY resolver (server=), configured in dnsmasq, dnsmasq ends up getting the info from their severs (or the unbound cache, or the dnsmasq cache).
Thank you again. Yes I'm sending email from my raspberry (PI3 B+, stretch). I have changed the ssmtp conf-files using the IP address. So, I will give this a try.
Some words to my actual configuration:
pi-hole forwards to ==> 127.0.0.1#5354 (Unbound) forwards to ==> 127.0.0.1#41 (DNScrypt-proxy v2).
This is by far the most daring combination I've ever read about here. I can only imagine you've added the local unbound to handle the DNSSEC evaluation, since dnsmasq isn't doing a very good job. A dnscrypt proxy resolver (for example dnscrypt.me) is already running unbound, so you're setup runs everything trough unbound twice...
It's possible to set it up like this as long as you configure your unbound to run only module validation and configure forward destinations (no recursive resolving). However, I agree with @jpgpi250 that this is might be too much. Note that I'm not knowledgeable about what dnscrypt may or not be doing, so it'd be nice if you could clarify why you have the intermediate unbound in place.
Yes, they are a very big hosting and server provider in Germany. I have some DNS records on their name servers as well.
I've read somewhere the current version of dnscryp-proxy (2.0.14) isn't capable yet of evaluating DNSSEC, but might be able in the (near?) future. @mibere will confirm (hopefully) his dnscrypt.me service is running unbound behind the scenes. We had a conversation, regarding the settins afew dys ago, if you remember...
Oh I know that this is a very questionable configuration. I've done this only for testing and educational purposes. For my next "production" environment I will use a different config.
I assume that DNScrypt could make trouble in resolving DNSSEC, because on my "production PI" only running pi-hole (Jessie) everything works fine. And on my new one everything was fine before dnscrypt was installed.
So, I will try the next "daring combination"
pi-hole ==> 127.0.0.1#5353 (Unbound)
In addition to this example I've added forward zones to the Cloudflare DNS Servers. Does this make sense? Otherwise DNS lookups will go to my ISP, right?
No. unbound is unlike dnsmasq. Everything is explained in my guide, you linked, I cannot add much to this. unbound resolves by contacting the corresponding DNS servers directly. It does not connect to any large DNS provider like your ISP or CF. In fact, forward zones defeat the entire purpose of what I want to achieve in this guide...
Thank you @DL6ER and sorry for the misunderstanding on my side. I did not quite well understand the "mechanism" of resolving DNS Names in Unbound.
To make it short I've red it again and some other stuff. It should now work as aspected.
Again thank you all very much for your patience.
