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):
(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)
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.
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?
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?
Are you digging the authoritative name servers? Specifically ns1.ngate.dens2.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.
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.
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
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.
