Azure DNS не выполняет поиск политик SPF для определенных доменов

Я запускаю свой собственный почтовый сервер на виртуальной машине Azure Linux с Postfix. Поскольку я подвергся сильной спам-атаке, я усилил меры безопасности своего почтового сервера.

Не вдаваясь в вопросы безопасности, сегодня я заметил кое-что особенно необычное.

Postfix не получал почту с некоторых хорошо известных доменов. Только некоторые

#  /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

То, что я тупо сделал, - это эхо-запрос для записи SPF на ing.com / ing.net

Из моего ящика Windows 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 =

Из ящика почтового сервера nslookup

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

Из ящика почтового сервера, установив DNS Сервер для 8.8.8.8 возвращает те же полезные данные SPF.

Вопрос: что вызывает эту проблему с разрешением TXT DNS в виртуальной машине Azure? Прежде чем слепо изменять настройки системного DNS, я хотел бы понять ошибку и ее причину, а также почему происходит только в DNS по умолчанию в Azure

1
задан 30 April 2019 в 00:06
1 ответ

Похоже, переключение DNS на общедоступный DNS Google работает и в настоящее время является единственным способом заставить работать SPF.

Бывает, что если запрос DNS превышает 512 байт, он может ' t передаваться по стандартному UDP. nslookup , насколько я мог видеть, переключается на TCP автоматически.

Но DNS-сервер должен поддерживать запросы TCP, то есть должен прослушивать TCP 53.

Проблема кажется для работы с инфраструктурой Azure. Их DNS ( 168.63.129.16 ), вероятно, неправильно настроен просто потому, что время ожидания истекает при использовании 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

(Спящий режим)

Такая проблема не возникает с другими службами DNS, так что это позволяет мне думать это не проблема локального межсетевого экрана устройства SuSEfirewall .

Переключение /etc/resolv.conf на любой другой общедоступный DNS (например, 8.8.8.8 ) разрешает запросы TCP, и SPF возвращается к работе.

Одним из недостатков является то, что некоторые черные списки спама не очень подходят для Google DNS.

Например, мне пришлось оставить комментарий в моем main.cf

smtpd_client_restrictions =
#        reject_rbl_client multi.uribl.com,

Журналы имеют был повернут, поэтому я не могу вспомнить точное сообщение об ошибке, которое я получил с этим RBL.

0
ответ дан 4 December 2019 в 03:01

Теги

Похожие вопросы