DNS failures or rejections vs. mail.ispmail.de

I’m trying to email my pal Laura. I get bounce messages all the time when using MiaB. But not when sending from my gmail account. Starting to troubleshoot, I noticed something weird (to me):

cliff@box:~$ dig laura-baxter.com MX

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> laura-baxter.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58335
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bb8b7776cc6533fb08c50ff6611743d6916cde80e385dc33 (good)
;; QUESTION SECTION:
;laura-baxter.com.		IN	MX

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Aug 14 06:17:26 CEST 2021
;; MSG SIZE  rcvd: 73

The status is SERVFAIL with no MX record returned. Or, frequently, something more active, like REJECTED or REFUSED or similar.

But when I use a different DNS server for my dig, I get what seems like a normal status and the MX record mail.ispmail.de:

cliff@box:~$ dig @1.1.1.1 laura-baxter.com MX

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @1.1.1.1 laura-baxter.com MX
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32333
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;laura-baxter.com.		IN	MX

;; ANSWER SECTION:
laura-baxter.com.	28800	IN	MX	50 mail.ispmail.de.

;; Query time: 313 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Aug 14 06:22:19 CEST 2021
;; MSG SIZE  rcvd: 76

(Same as when using 8.8.8.8 or 208.67.222.222 for that matter.)

Does this mean that the company behind laura-baxter.com is actively preventing my Mail-in-a-Box instance from resolving her domain name into MX records?

Or is something broken about MiaB’s ability to resolve the domain?

More background info

  • Mails to her (but not the other usual suspects like outlook.com, etc.) have been bouncing since roughly the end of June.
  • All my system status stuff has the nice green checkmark (I even the DNSSEC DS records on the domains my box is serving this week)
  • This is on Digital Ocean with domain registration at NearlyFreeSpeech.NET and Gandi (not sure if that matters)
  • Laura is perplexed by this and wants to find the root cause (she doesn’t want to miss email from me or her potential customers)

Thanks for any suggestions!

The first question is always whether you have changed any configuration files in MiaB.

I’ve only limited experience in troubleshooting these sorts of DNS issues in Linux. I will note that there are odd goings-on with that domain, including a name server record on a domain that does not provide any WHOIS information, but I have limited experience with .DE TLDs.

If this is the only domain experiencing this issue, then it is somehow related with either the MiaB BIND/named configuration or something with Digital Ocean, but DO would most likely be blocking on the port level, which would impact more than one domain.

Usually hosting ISPs have an internal-use only (won’t work from outside DO network) caching DNS resolver IP address (or addresses) that is probably the default when using an unconfigured server. Try searching their documentation or, better, send them a support ticket that also includes your current issue.

For what it’s worth, Vultr doesn’t have any issues looking up that domain and neither does MiaB on Vultr.

That’s easy: NOPE. This is very much a stock install of MiaB.

I’ll submit a ticket to digital ocean. Thanks for the idea.

1 Like

Sharing the mail delivery failure report will be quite helpful … can you please share one?

So the very first test I did failed. The name servers on her domain did not reply. Subsequent tests from the command line using dig were fine though.

There is one issue with gwhois where if the nameserver is configured to reject requests for ANY or *, then that is the DNS record response. It’s more obvious with a Cloudflare DNS hosted domain because they will kindly return ‘rfc8482’ directly in the response in an HINFO record.

So you have to query each record manually.

There is a way for the dev who made gwhois to fix this, but at this point I think he isn’t going to fix it unless someone submits a PR, but it isn’t something trivial to fix.

Doing dome more digging I am finding that 2 of the 3 DNS servers her domain is using are not replying.


; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.ngate.de laura-baxter.com MX
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

accounting@do-ny2:~$ dig @ns3.ngate.de laura-baxter.com MX

; <<>> DiG 9.16.1-Ubuntu <<>> @ns3.ngate.de laura-baxter.com MX
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

accounting@do-ny2:~$ dig @ns2.ngate.de laura-baxter.com MX

; <<>> DiG 9.16.1-Ubuntu <<>> @ns2.ngate.de laura-baxter.com MX
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33381
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 940ed4d52522f33128d4c42b6117e583efcbad2dc31816a4 (good)
;; QUESTION SECTION:
;laura-baxter.com.		IN	MX

;; ANSWER SECTION:
laura-baxter.com.	28800	IN	MX	50 mail.ispmail.de.

;; AUTHORITY SECTION:
laura-baxter.com.	28800	IN	NS	ns3.ngate.de.
laura-baxter.com.	28800	IN	NS	ns1.ngate.de.
laura-baxter.com.	28800	IN	NS	ns2.ngate.de.

;; ADDITIONAL SECTION:
ns2.ngate.de.		28800	IN	AAAA	2001:41d0:701:1100::19d2
mail.ispmail.de.	28800	IN	A	195.185.212.46
mail.ispmail.de.	28800	IN	A	62.26.12.182
mail.ispmail.de.	28800	IN	A	62.26.12.183
mail.ispmail.de.	28800	IN	A	195.185.212.45
ns1.ngate.de.		28800	IN	A	195.185.212.176
ns2.ngate.de.		28800	IN	A	51.68.175.53
ns3.ngate.de.		28800	IN	A	62.26.12.231

;; Query time: 83 msec
;; SERVER: 2001:41d0:701:1100::19d2#53(2001:41d0:701:1100::19d2)
;; WHEN: Sat Aug 14 15:47:16 UTC 2021
;; MSG SIZE  rcvd: 304

And notice, that the one lookup which was successful was via IPv6. Interesting. At this point, I am suspecting her DNS as being a part of the issue, if not the entire issue. Of the three name servers only one has an AAAA record.

I did these lookups from a Digital Ocean server. Off to check them from a BuyVM server, just because. Ok, no issues.

I am suspecting that the name servers being ran by ngate.de are blocking requests from DO IPv4 IP ranges.

@cliff1976 Do you have IPv6 enabled on your MiaB server?

I get what appears to be expected responses on all of those queries from both my MiaB and another generic Ubuntu Server both on Vultr.

Oh, and same on another generic Ubuntu Server that is IPv4 only.

Sure, yes, there is an initial report that it failed and is still trying, and then a final one. I redacted her actual email address.

Final one:

This is the mail system at host box.cliff1976.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<REDACTED@laura-baxter.com>: Host or domain name not found. Name service error for
    name=laura-baxter.com type=MX: Host not found, try again

--A2D411008E3.1628949114/box.cliff1976.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; box.cliff1976.com
X-Postfix-Queue-ID: A2D411008E3
X-Postfix-Sender: rfc822; mattermost@cliff1976.com
Arrival-Date: Thu, 12 Aug 2021 14:44:38 +0200 (CEST)

Final-Recipient: rfc822; REDACTED@laura-baxter.com
Original-Recipient: rfc822;REDACTED@laura-baxter.com
Action: failed
Status: 4.4.3
Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error
    for name=laura-baxter.com type=MX: Host not found, try again

--A2D411008E3.1628949114/box.cliff1976.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Return-Path: <mattermost@cliff1976.com>
Received: from authenticated-user (box.cliff1976.com [46.101.237.35])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))
	(No client certificate requested)
	by box.cliff1976.com (Postfix) with ESMTPSA id A2D411008E3
	for <REDACTED@laura-baxter.com>; Thu, 12 Aug 2021 14:44:38 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cliff1976.com; s=mail;
	t=1628772278; bh=DQrxgxuLDdyTf1md04uiy0CRFbrxnF9kUPsLB4Idepk=;
	h=Subject:Reply-To:Date:From:To:From;
	b=EQ7uposlmJMsqsPRwEILSXKdKU3R6+fFph3+1tI3EMvoF6WvkUfugOJ4rOVd80n+r
	 5pHWE1BZ8/XJhqhpN9Z1kqsnW015x/jdLyGUBeAVyafEdBPbP/Kar7X5ffRLFQQsqg
	 H3Uobb+dZJW70x2U7BUMV104NeVO60Ck0+FG7thLJ7zWn6W6Sh2iVMDi/mZ8QQXM0c
	 Hg/ibY3N2ioAac1y3EvfnMBFHGq3B6SO5iL6mZ2vA/9GzjvvTqzFpHOwzJK9aFvJVm
	 rUTXKniZN/EhOlAWmZ2xCZMt9RDvtrRfuP1q5zVIsFhXgWsTsP3p7v2CPTwpEpH4R7
	 7r8KHHWaStE8w==
MIME-Version: 1.0
Subject: [Mattermost] Notification in DemsAbroadNCB (GOTV Events) on August
 12, 2021
Content-Transfer-Encoding: 8bit
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: "cliff1976's Mattermost Server" <mattermost@cliff1976.com>
Date: Thu, 12 Aug 2021 12:44:38 +0000
From: "cliff1976's Mattermost Server" <mattermost@cliff1976.com>
To: REDACTED@laura-baxter.com
Content-Type: multipart/alternative;
 boundary=6fd08f659273c689a423deae7dc1698fc727dc997905406fc7b3d6ad7f32

--6fd08f659273c689a423deae7dc1698fc727dc997905406fc7b3d6ad7f32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

I am also getting mixed results. I have 5 DigitalOcean droplets. Two of them are returning SERVFAIL or REFUSED results. The other 3 seem to find the MX record just fine via dig.

Yes, indeed I do, and on all 5 of my DigitalOcean droplets for that matter.

Also the two that are NOT working are in two different DO data centers, interestingly: FRA1 and NYC3. The three that are (apparently) working fine are in FRA1 (x2) and NYC2.

What else can I try to test? I’m in the middle of submitting a support request to DigitalOcean like @openletter already suggested – should I hold off on that or press on?

Thank you!

Are you digging the authoritative name servers? Specifically ns1.ngate.de ns2.ngate.de and ns3.ngate.de.

Which specific ones fail?

I don’t think that you’ll get anywhere with DO, but I suppose it never hurts to try. I would be taking the approach of having Laura ask why her name servers are not replying on to requests from Digital Ocean servers via IPv4 at all, and why only one of them replies on IPv6.

I have an IPv4 only server that gets everything just fine.

1 Like

Thanks for catching that … @cliff1976 please see my edit to my last post…

This is getting weird.

FRA1 MiaB instance:

cliff@box:~$ dig @ns1.ngate.de laura-baxter.com MX +short; dig @ns2.ngate.de laura-baxter.com MX +short; dig @ns3.ngate.de laura-baxter.com MX +short;
dig: couldn't get address for 'ns1.ngate.de': failure
dig: couldn't get address for 'ns2.ngate.de': failure
dig: couldn't get address for 'ns3.ngate.de': failure

NYC3 instance:

cliff@drop19:~$ dig @ns1.ngate.de laura-baxter.com MX +short; dig @ns2.ngate.de laura-baxter.com MX +short; dig @ns3.ngate.de laura-baxter.com MX +short;
dig: couldn't get address for 'ns1.ngate.de': failure
dig: couldn't get address for 'ns2.ngate.de': failure
dig: couldn't get address for 'ns3.ngate.de': failure

NYC2 instance:

root@cliff1976-ovpn:~# dig @ns1.ngate.de laura-baxter.com MX +short; dig @ns2.ngate.de laura-baxter.com MX +short; dig @ns3.ngate.de laura-baxter.com MX +short;
50 mail.ispmail.de.
50 mail.ispmail.de.
50 mail.ispmail.de.

FRA1 instance:

root@mastodon-ubuntu-s-1vcpu-1gb-fra1-01:~# dig @ns1.ngate.de laura-baxter.com MX +short; dig @ns2.ngate.de laura-baxter.com MX +short; dig @ns3.ngate.de laura-baxter.com MX +short;
50 mail.ispmail.de.
50 mail.ispmail.de.
50 mail.ispmail.de.

FRA1 instance:

root@chat:~#  dig @ns1.ngate.de laura-baxter.com MX +short; dig @ns2.ngate.de laura-baxter.com MX +short; dig @ns3.ngate.de laura-baxter.com MX +short;

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @ns1.ngate.de laura-baxter.com MX +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
50 mail.ispmail.de.

; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> @ns3.ngate.de laura-baxter.com MX +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Sometimes it looks like ns2.ngate.de works (see this last one in FRA1 where only ns2.ngate.de worked), like your results show, @alento, but not always. From one FRA1 instance all three authoritative servers worked.

Chiming in, querying from my side (i.e. from my box) says everything is fine DNS-wise. If I had to guess, it can be an issue with the box’s internal DNS resolver - aka bind/named (they’re actually the same piece of software but potentially under different names).

On your box, are there any logs indicating something erroring out? These commands might help:

sudo service named status
sudo journalctl -xe | grep named
cat /etc/resolv.conf

It’s also possible that your provider is actually overwriting the last file in such a way that your box uses THEIR DNS resolver. It could happen their resolver is faulty somehow.

Hi @davness and thanks for chiming in.

Yes. Here’s a screenshot of the output of those three commands:

Does that reveal anything new to you? Looks like further confirmation of the stuff we already detected to me.

Regarding the contents of /etc/resolv.conf: I guess that’s normal for a machine functioning as a nameserver, right? My other VPSen have entries like this:

# cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "systemd-resolve --status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0

Yeah, it clearly shows that the one ns that is answering is refusing your requests. Time to bounce the issue over to Laura for her ISP to answer.

She may want to refer them to this thread … problem is that level 1 support likely won’t be of help, she will need to escalate it.

Same problem here last year. Certain mail servers (not all) rejecting incoming mail from my miab instance. The IP address assigned to my mail server by Digital Ocean was blocked as suspicious by certain mail servers.
I ended up switching Digital Ocean server/location therefore getting a completely different IP address assigned to my maib server, resolving the problem.