The DNS resolution on our mailinabox stopped working a few days ago. The box is a standard install, and nothing has been changed. The contents of
/etc/resolv.conf points to 127.0.0.1, and bind9 is definitely running.
I see that in
forwarders section is commented out. If I uncomment this, and add a local resolver or Google’s DNS servers and then restart bind9, DNS resolution works again without a problem.
Which leads me to my question: how did DNS resolution work in the first place without a forwarder listed in bind9? And what changed that now it no longer works without specifying a forwarder?
The same way Google resolves DNS without resorting to a forwarder (who would it ask?). Each DNS request starts with the root zone and works down recursively through the domain name hierarchy until it gets an answer.
We do this to properly support DNSSEC for locally-initiated DNS queries. (I’m not 100% sure this is the only way to do that, but that was the motivation for having a locally running nameserver.)
I don’t know why your box might not be working correctly. Try a reboot, or running
mailinabox to reconfigure services?
I’ve tried a reboot. I’ll run
mailinabox to reconfigure and see whether that fixes it. I just find it strange that this randomly happened without any changes from my side.
On an unrelated note (or maybe not so unrelated), I’ve noticed the
mail.err logs show that DKIM verification fails for all incoming mail. If I test using
mailinabox:~# opendkim-testkey -d mydomain.com -s google
I receive the following error (which is the same error that shows in
opendkim-testkey: 'google._domainkey.mydomain.com' query timed out
However, when I manually query the TXT record using
dig, it works successfully:
mailinabox:~# dig txt google._domainkey.mydomain.com
;; ANSWER SECTION:
google._domainkey.mydomain.com. 299 IN TXT "v=DKIM1\; k=rsa\; p=XXXXXXXXXXXXXXXXXXXXXXX"
This seems to have been happening for months already, so I’m not entirely sure whether it’s related to the DNS resolution issue. In any case, I’ll do a full update and report back.
Right, so an update and a reboot didn’t fix it. And I’m a bit at a loss to where to go to from here.
Things I know:
- I haven’t made any configuration changes that could affect the DNS
- Queries directly against a local recursive server or against Google servers works fine.
- I’ve manually updated the
ftp://ftp.rs.internic.net/domain/ which hasn’t made any difference.
Any suggestions? There are no errors pertaining to bind9 in
Can’t understand what google._domainkey.mydomain.com plays in your mentioned test… Undestanding my default domain is mail.mydomain.xyz the default DKIM TXT record created by MiaB for my box looks as follows mail._domainkey.mail.mydomain.xyz
Apologies, in my example I should have used
remotedomain.com instead of
mydomain.com. In other words, this problem occurs for incoming mail from remote servers.
To clarify: for all incoming mail, Mail-in-a-box will DKIM for the sender’s domain using OpenDKIM. In the example I provided, the sender is
mydomain.com, having the DKIM TXT record of
google._domainkey.remotedomain.com, since it uses Google Apps.
I’m able to manually querying the remote domain’s DKIM TXT record using
dig, but when I test it using
opendkim-testkey, I get a timeout. This happens for all domains for all incoming mail.