Strange behaviour when sending emails




my debug token: 0w3efz0oxp

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 query[A] from
May 19 06:25:24 dnsmasq[1127]: 10075 forwarded to
May 19 06:25:24 dnsmasq[1127]: 10076 query[AAAA] from
May 19 06:25:24 dnsmasq[1127]: 10076 forwarded to
May 19 06:25:26 dnsmasq[1127]: 10073 validation is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10074 validation is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10075 validation is BOGUS
May 19 06:25:26 dnsmasq[1127]: 10076 validation 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 query[A] from
May 19 08:46:42 dnsmasq[1127]: 10095 forwarded to
May 19 08:46:42 dnsmasq[1127]: 10096 query[AAAA] from
May 19 08:46:42 dnsmasq[1127]: 10096 forwarded to
May 19 08:46:43 dnsmasq[1127]: * dnssec-query[DS] to
May 19 08:46:43 dnsmasq[1127]: * dnssec-query[DNSKEY] de to
May 19 08:46:43 dnsmasq[1127]: * reply de is DNSKEY keytag 39227, algo 8
May 19 08:46:43 dnsmasq[1127]: * reply de is DNSKEY keytag 10498, algo 8
May 19 08:46:43 dnsmasq[1127]: * reply is no DS
May 19 08:46:43 dnsmasq[1127]: 10095 validation result is INSECURE
May 19 08:46:43 dnsmasq[1127]: 10095 reply is
May 19 08:46:43 dnsmasq[1127]: 10096 validation result is INSECURE
May 19 08:46:43 dnsmasq[1127]: 10096 reply is 2a01:238:20a:202:55f0::1133

I can’t find any event which is “disturbung” the validating of
Any ideas?

Thanks in advance


dnsmasq (FTLDNS is based on dnsmasq 2.79) considers the domain 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. 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 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:

 dig @ -p 5552 +dnssec

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, 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 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 @ -p 53 +dnssec

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 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
May 20 07:03:13 xxxxxxxx sSMTP[28436]: Cannot open

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 ‘’, I’ve heard from some readers the domain is in some lists, used by pihole.

If You’re having so much trouble with ‘’, you could try to simply use the IP address ( in the configuration, this eliminates the DNS lookups. I’ don’t think ‘’ will be changing the IP address any time soon (inconvenient for there customers). This would eliminate the need to restart services.’ seems to have their own DNS servers          86400   IN      A          86400   IN      A          86400   IN      A          86400   IN      AAAA    2a00:e10:2004::2          86400   IN      A          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 ==> (Unbound) forwards to ==> (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 is already running unbound, so you’re setup runs everything trough unbound twice…

@mibere , @DL6ER, your thoughts please…


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 service is running unbound behind the scenes. We had a conversation, regarding the settins afew dys ago, if you remember…


Yes, my server is running Unbound 1.7.1.


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”:wink:
pi-hole ==> (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.


I you have any further specific questions, I’ll be able to answer them if I can.

Is everything now working for you?


Yes, everything is working now.

Thanks again