Mail-in-a-Box DNS resolution stopped working

I’ve been running MIB on a VPS on Contabo with the domain registered through Gandi dot net using glue records since March 2026 - Nothing has changed at Gandi, and there have been two upgrades to MIB.

Today my Mail client has been unable to connect, the mailinabox domain name does not resolve.

SSH into the box, I cannot resolve any hostnames from the mailinabox. I can’t run apt update or mailinabox. All conf files look fine. (google suggested checking for spaces in conf files)

systemd-resolved, nsd and named are running.

I can bring up mailinabox admin using IP address in a browser, but status won’t run (cause of DNS resolution I assume)

I can use dig +tcp @1 . 1 . 1 . 1 domain.name successfully from the mailinabox.

I have rebooted - I have searched these forums as well as many others - the closest thing was on this forum under dns-stopped-working-related-to-glue-records/6840 (new users can’t post links) but my box does not list as a serverHold as his did, and his solution was to use a different domain name. I would prefer to fix this issue (whatever it is).

My last resort has been to post here hoping someone can point me in the right direction.

Thanks!

It looks like my original post was 4 hours or so ago. I had a session and as soon as the band left I closed Pro Tools and loaded up my mailer and browsers - lo and behold - it fixed itself?

I’m now running apt update && apt upgrade -y and mailinabox followed by a reboot.

What worried me most while the box wasn’t resolving is that watching the mail.log, I could see the RBL lookups failing - I don’t know how those other mail servers were finding me while my domain didn’t resolve (cause my authoritative name server was unreachable) - but, not being able to do RBL lookups or even hostnames for that matter wasn’t helping mail flow or not.

Shouldn’t the mail server stop running if it can’t look up RBLs?

I really wish I knew where the problem was.

Gandi dot Net (registrar), Contabo VPS (although I could ssh into the server just fine), or mailinabox’s authoritative name server.

I’ve no idea if this is related to your problems … but … lots of stuff depends on having a reasonably accurate clock. Anything that verifies a host/address on connection (eg https) will fail if the system clock is way off. Most installs and updates use https.

I’ve taken to checking the system date/time when lookup and/or download stuff fails unexpectedly.

PS. Set the clock to approximately correct, or there is an ntpd option (-g) which allows ntpd to make a big correction.

1 Like

Thanks for your no idea - idea :laughing:

I believe the box regularly uses ntp to sync with the world clock, no?

I checked Munin via the admin panel and found ntp stopped during my outage (probably due to DNS failing):
Screenshot 2026-06-03 at 10.18.08 PM

… and also noticed that it appears that all prior ntp states have vanished prior to my issue:

My box was not resolving from itself. Command line dig and ping would time out unable to resolve domain.name. 127.0.0.1:53 wasn’t working plus my FQDN disappeared from the world as well. All DNS kaput!

I also noticed while starting and restarting services that this reported “bug” still exists:
NSD daemon fails to log into /var/log/ directory #2313 but I don’t know that that would have caused my issue.

I’m still digging - I don’t want this to happen again.

I’m very much considering moving from Gandi as most of the problems MIAB related that I’m finding in my searches were using Gandi, plus Gandi upsells their domains nearly 4 times cost. $40 a year?! I’ve talked to Coudflare - and they apparently can do the same thing for me that Gandi is providing - I just have to have their support do it for me.

Thank you for your response - and if any moderator could move this to the “Maintenance” forum, I now see that this is where this thread should go … Thanks again!

By the way, Dns stopped working, related to glue records? was the post I found on this forum.

I just realized it was originally from 2020, but it seems to be so similar?

Just noticed this post was moved to Maintenance, so thanks moderator - but it didn’t up the close time to a month - so still only 7 days for someone to chime in whether this is an unknown or a known known.

Thanks!

Maybe you know this, but I want to put this here to be sure. There are two pieces of DNS software running on your box. One is nsd which hosts your zones to the outside world. This is the server that responds to the configuration at your domain hoster (gandi)
The second one is bind9 (also known as named) that does the local DNS resolution. This is used when something on your box wants to resolve a hostname.

It sounds like local DNS resolution failed for a while. That would mean looking at e.g. journalctl -u named for the logs of this DNS software. Glue records have nothing to do with this part.

I would think that sending of email would be impacted by this, but receiving should still work. Failed lookups of RBL should not impact the delivery of mail to your box.

You state systemd-resolved is running, but you would not use this in the Mail-in-a-Box setup. It also sounds like the issue resolved itself?

Could you post the output of the status screen parts which are not green? If it does not work, look at journalctl -u mailinabox because it should. This points at an error.

3 Likes

Thanks so much for your reply! It sent me on an educational fact finding mission.

MIAB uses all 3 DNS apps. As you said, nsd for authoritative name resolution only, bind9 (named) for local resolution, and systemd-resolved for the Ubuntu OS disabled with DNSStubListener=no so as to not conflict with named.

I also looked through the logs you mentioned and found the precise times of the outage. The only log that provided information was named, apparently stuck in a loop commonly referred to as DNS Resolver Death Loop:

named[5265]: shut down hung fetch while resolving '*.*.*.*.in-addr.arpa/PTR'
named[787]: resolver priming query complete: timed out

Yes, mail did go through during this DNS outage and my concern about the RBL lookups failing was that mail wouldn’t or couldn’t be verified as being on a blocklist. Consequently emails would be let through rather than rejected or marked as SPAM.

The System Status via the MIAB admin web interface accessed by http://ip.ad.dr.ess/admin was accessible (without https) but would not run without DNS resolving. When healthy DNS, my box.mydomain.com and mydomain.com are all “green”.

I’ve sent a support ticket to Contabo asking if they had an outage or a triggered event at that time. It’s been suggested that there could have been abuse triggered that would cause Cantabo to shut down ports due to a bot-storm or something, and I was an innocent bystander.

Nothing was changed on my MIAB and it’s been running fine since it just started working. Total down time was 5 hours 50 minutes. 16:07 - 21:57 EST 6/2/2026.

I do feel a bit more edumacated about how MIAB works and diagnosing this issue, although, I’m predicting a “What? No problems here” response from Contabo. :pensive:

Thank you again - it helps so much to be pointed in the right direction and hopefully achieve a resolution so when this topic is searched again, there’s an actual answer or explanation. Frustrating to find like threads that have been abandoned.

Additional Edit

I should probably also add that the glue records at Gandi would have effected the nsd, but not the behavior observed from named. Since it was DNS in both directions, I’m assuming Contabo as the cause.

Update; as I thought, Contabo didn’t log any problems with their network.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.