DNS Resolution Fails

1

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 /etc/bind/named.conf.options the 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?

2

The same way Google resolves DNS without resorting to a forwarder (who would it ask?). :slight_smile: 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?

3

Good point :slight_smile:

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 opendkim-testkey:

mailinabox:~# opendkim-testkey -d mydomain.com -s google

I receive the following error (which is the same error that shows in mail.err):

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.

4

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:

  1. I haven’t made any configuration changes that could affect the DNS
  2. Queries directly against a local recursive server or against Google servers works fine.
  3. I’ve manually updated the db.cache from ftp://ftp.rs.internic.net/domain/ which hasn’t made any difference.

Any suggestions? There are no errors pertaining to bind9 in /var/log/syslog.

5

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

6

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.