1

I run my own mail server on an Azure Linux VM with Postfix. Since I was under heavy spam attack I reinforced my mail server security measures.

Without going into the security things, today I noticed something particularly unusual.

Postfix was not getting mail from some well known domains. Only some

#  /var/log/mail
postfix/smtpd[40702]: NOQUEUE: reject: RCPT from xxxx.ing.net[xx.xx.xx.xx]: 451 4.3.5 <prvs=2022b5a257=xxxxx@ing.com>: Sender address rejected: Server configuration problem; from=<xxxxxxx@ing.com> to=<xxxxxxxxxx> proto=ESMTP helo=<xxxx.ing.net>

# /var/log/warn
postfix/smtpd[32944]: warning: problem talking to server private/spf-policy: Connection timed out

What I dumbly did was to ping for SPF record on ing.com / ing.net

From my Windows box nslookup

 ing.com
Server:  [8.8.8.8]
Address:  8.8.8.8

Risposta da un server non autorevole:
ing.com text =

        "MS=ms77059065"
ing.com text =

        "v=spf1 include:_spf.ing.net ip4:91.209.197.6 ip4:89.20.160.55 ip4:78.136.53.254 ip4:95.138.135.251 ip4:92.52.81.2 ip4:146.148.26.249 ip4:83.231.160.132 ip4:83.231.160.128/26 ip4:212.187.169.64/26"
        " include:_spf_mx.solvinity.com include:mailplus.nl ip4:24.157.48.85 ip4:141.155.214.85 ip4:160.34.64.28 ip4:192.254.112.185 ip4:118.127.87.207 ip4:128.242.118.200 ip4:62.73.172.35 ip4:83.217.248.35 ip4:91.209.197.7 -all"
ing.com text =

        "adobe-idp-site-verification=8b81f7b92ccac0b65bab7d47f9fcecaeda6f04ac870b79133d8ac54be7b53534"
ing.com text =

From the email server box nslookup

> nslookup
> set type=txt
> ing.com
;; Truncated, retrying in TCP mode.

From mail server box setting the DNS server to 8.8.8.8 returns the same SPF payload.

Question is: what is causing this issue with TXT DNS resolution in Azure VM? Before blindly changing the system DNS settings, I would like to understand the error and its cause, and why happening only on Azure default DNS

usr-local-ΕΨΗΕΛΩΝ
  • 2,359
  • 7
  • 34
  • 52

1 Answers1

0

Looks like that switching the DNS to Google public DNS works and is currently the only way to get SPF working.

It happens that if a DNS query is larger than 512 bytes it can't be transmitted over the standard UDP. nslookup, from what I could see, switches to TCP automagically.

But the DNS server has to support TCP querying, i.e. must be listening on TCP 53.

The problem seems to be with Azure infrastructure. Their DNS (168.63.129.16) is likely misconfigured, simply because it timeouts when using TCP.

$ telnet 168.63.129.16 53
Trying 168.63.129.16...
Connected to 168.63.129.16.
Escape character is '^]'.
eee





^C^C^C^C^C^C^C^C^C^C^C^C

(Sleep)

Such problem does not occur with other DNS services, so this allows me to think it's not a problem with the appliance's local firewall SuSEfirewall.

Switching /etc/resolv.conf to any other public DNS (e.g. 8.8.8.8) allows TCP querying and SPF returns to work.

One drawback is that a few spam blacklist are not very friendly with Google DNS.

For example I had to comment in my main.cf

smtpd_client_restrictions =
#        reject_rbl_client multi.uribl.com,

Logs have been rotated, so I can't recall the exact error message I got with that RBL.

usr-local-ΕΨΗΕΛΩΝ
  • 2,359
  • 7
  • 34
  • 52