Hello List
Does anyone know, how bluewin does 'verify' an MX?
The MX of our customer is prefectly reachable for sender verification but his emails sent 'to' bluewin recipients are getting blocked with:
MAIL FROM: <[scrubbed]@aerni.com> Unable to verify MX-Record for domain aerni.com
aerni.com mail is handled by 10 mail.aerni.com.
mail.aerni.com has address 87.102.181.130
Connected to mail.aerni.com. Escape character is '^]'. 220 mail.aerni.com ESMTP ready. quit 221 mail.aerni.com closing connection Connection closed by foreign host. benoit@krup:~$ telnet mail.aerni.com. smtp Trying 87.102.181.130... Connected to mail.aerni.com. Escape character is '^]'. 220 mail.aerni.com ESMTP ready. ehlo imp.ch 250-mail.aerni.com Hello dhcp-186.imp.ch [157.161.4.186] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-AUTH PLAIN LOGIN 250-STARTTLS 250 HELP mail from:<> 250 OK rcpt to:<[scrubbed]@aerni.com> 250 Accepted rset 250 Reset OK
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello Benoît
Put simply, we do DNS requests for MX or A records for the given sender domain, if either exists this check is passed.
As for the issue at hand: the DNS servers of your customer are (were) not properly reachable from our IP ranges or more specifically we are (were) unable to get the IPs for ns1.aerni.com or ns2.aerni.com. During our investigation this resolution has mostly recovered and we are able to resolve the domain properly, so this issue should now be resolved. This makes it harder though to pinpoint the exact cause here, to us it currently seems though that NS records have been changed and the old DNS servers been turned off before the TTLs of the old NS records had expired, so some intermediate DNS/CNS servers still had cached info that was now no longer working and this made the domain unresolvable to our servers.
As a side note: both NS entries now share a single IP and that is even the same IP as the mail server, this is definitely not an optimal setup, an offsite secondary DNS server that didn't need changing might have prevented this from the start.
Regards Marcel
-----Ursprüngliche Nachricht----- Von: swinog-bounces@lists.swinog.ch [mailto:swinog-bounces@lists.swinog.ch] Im Auftrag von Benoit Panizzon Gesendet: Freitag, 12. Januar 2018 10:31 An: swinog@lists.swinog.ch Betreff: [swinog] Bluewin Error: Der MX-Eintrag fuer die Domaene aerni.com kann nicht verifiziert werden
Hello List
Does anyone know, how bluewin does 'verify' an MX?
The MX of our customer is prefectly reachable for sender verification but his emails sent 'to' bluewin recipients are getting blocked with:
MAIL FROM: <[scrubbed]@aerni.com> Unable to verify MX-Record for domain aerni.com
aerni.com mail is handled by 10 mail.aerni.com.
mail.aerni.com has address 87.102.181.130
Connected to mail.aerni.com. Escape character is '^]'. 220 mail.aerni.com ESMTP ready. quit 221 mail.aerni.com closing connection Connection closed by foreign host. benoit@krup:~$ telnet mail.aerni.com. smtp Trying 87.102.181.130... Connected to mail.aerni.com. Escape character is '^]'. 220 mail.aerni.com ESMTP ready. ehlo imp.ch 250-mail.aerni.com Hello dhcp-186.imp.ch [157.161.4.186] 250-SIZE 52428800 250-8BITMIME 250-PIPELINING 250-AUTH PLAIN LOGIN 250-STARTTLS 250 HELP mail from:<> 250 OK rcpt to:<[scrubbed]@aerni.com> 250 Accepted rset 250 Reset OK
Mit freundlichen Grüssen
-Benoît Panizzon-
Dear List
Ok, thank you for the replies as they all point out an apparent PTR Problem, let me reply to the list.
According to my knowledge of the DNS rfcs (I did not look it up right now).
A Host resource may point to an A record another host resource is already pointing to. A Host resource could also point to multiple A records (DNS round robin).
A in-addr.arpa resource can only point to one PTR record.
So if an A record should be reachable under multiple hostnames, only one PTR can be set and that PTR should/must match a host Address resource (this is usually what is verified).
cable-static-181-130.breitband.ch => A 87.102.181.130 130.181.102.87.in-addr.arpa => PTR cable-static-181-130.breitband.ch
This is the 'main' entry, which matches and passes verification.
There is an additional host entry with the name 'mail.aerni.com' which points to the same A Address but cannot have an own PTR record without violating the rfcs about DNS.
In fact the customer only has troubles with a handful of destinations, most of smtp servers out there do accept his emails without problems.
But I must admit, this is not the 'normal' situation. The customer in question uses that 'dynamically assigned' static IP as a backup internet link only when his main connection is down, which is the case at the moment. So he made some quick DNS changes to restore email reception and noticed the problem sending to a couple of destinations.
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi Marcel
As for the issue at hand: the DNS servers of your customer are (were) not properly reachable from our IP ranges or more specifically we are (were) unable to get the IPs for ns1.aerni.com or ns2.aerni.com. During our investigation this resolution has mostly recovered and we are able to resolve the domain properly, so this issue should now be resolved. This makes it harder though to pinpoint the exact cause here, to us it currently seems though that NS records have been changed and the old DNS servers been turned off before the TTLs of the old NS records had expired, so some intermediate DNS/CNS servers still had cached info that was now no longer working and this made the domain unresolvable to our servers.
As a side note: both NS entries now share a single IP and that is even the same IP as the mail server, this is definitely not an optimal setup, an offsite secondary DNS server that didn't need changing might have prevented this from the start.
Ok, thank you, this clarifies and explains the issue. Yes, the customer has troubles with his main internet link at the moment and uses this ip address as his backup link.
I know he made mail.aerni.com pointing to the backup IP to be able to receive emails over the backup link.
I guess he also changed the NS entries at his registrar, so his DNS Servers can be reachable at this IP for the time of the outage. I'll suggest to him that he should have a secondary outside of his network so DNS is not dead if his link dies.
Mit freundlichen Grüssen
-Benoît Panizzon-
Benoit Panizzon wrote:
Dear List
Ok, thank you for the replies as they all point out an apparent PTR Problem, let me reply to the list.
According to my knowledge of the DNS rfcs (I did not look it up right now).
A Host resource may point to an A record another host resource is already pointing to. A Host resource could also point to multiple A records (DNS round robin).
A in-addr.arpa resource can only point to one PTR record.
In _can_ in fact have multiple, but it makes no sense and usually only the first one is used.
-
Benoit Panizzon -
Marcel.Gschwandl＠swisscom.com -
Per Jessen