Назад | Перейти на главную страницу

Обратный DNS не соответствует баннеру SMTP против несоответствия обратного DNS

Мне нужно решить, должен ли мой обратный DNS соответствовать баннеру SMTP, но обратный DNS к DNS и наоборот остается другим или наоборот. Какой выбрать?

У меня есть 2 сервера Exchange 2010 с одним отправителем SMTP с TMG 2010. TMG имеет 2 подключенных канала, поэтому у нас есть 2 отдельных интернет-провайдера. Проблема в том, что у меня нет возможности контролировать поведение TMG, по которому ссылка используется для отправки электронных писем, поскольку он выбирает ее случайным образом.

У меня есть 2 записи MX: - mail.test.com, который разрешает IP, а IP - mail.test.com - mail2.test.com, который разрешает IP2, а IP2 - mail.test.com

Это было сделано для предотвращения проблем с баннером smtp, но это создает проблемы с обратным DNS, если сервер на другой стороне достаточно нетерпелив, чтобы провести сравнение. Но я проверил в Google, и у них тоже нет этого в идеальном состоянии.

Если вам нужно выбрать между двумя сопоставимыми rDNS и A-записью, чтобы оба IP-адреса все еще были FcRDNS, но убедитесь, что имя хоста, представленное в баннере smtp, также разрешимо (выберите одно из двух имен хоста). Сломанный FcRDNS намного хуже, чем баннер SMTP, не соответствующий rDNS.

В качестве альтернативы вы можете полностью избавиться от второго имени хоста, и у вас вообще не будет никакого несоответствия

  • ditch mail2.test.com A и MX запись
  • сделать ДВЕ A-записи для mail.test.com (по одной для каждого ip)
  • установите rDNS PTR для обоих IP-адресов на mail.test.com
  • установить smtp-баннер (HELO) на mail.test.com

с этим решением вы получите лучшее из обоих миров. HELO / A / PTR будет соответствовать в каждом случае, и у вас все равно будет балансировка нагрузки / переключение при отказе MX:

из rfc5321:

Целевой хост (возможно, взятый из предпочтительной записи MX) может быть многосетевым, и в этом случае преобразователь доменного имени вернет
список альтернативных IP-адресов. [...] и отправитель SMTP ДОЛЖЕН попробовать их в указанном порядке.

Я понимаю вашу боль, но имейте в виду, что RFC5321 состояния:

Сервер SMTP МОЖЕТ проверить, что аргумент имени домена в команде EHLO действительно соответствует IP-адресу клиента. Однако, если проверка не удалась, сервер НЕ ДОЛЖЕН отказывать в приеме сообщения на этом основании. Информация, полученная при попытке проверки, предназначена для ведения журнала и отслеживания. Обратите внимание, что этот запрет распространяется только на сопоставление параметра только с его IP-адресом; см. Раздел 7.9 для более подробного обсуждения отклонения входящих соединений или почтовых сообщений.

Так что соблюдайте точное соответствие между mail.test.com <-> IP1 и mail2.test.com <-> IP2 и постарайтесь сообщить принимающим сайтам, которые блокируют это, что они должны быть более изящными на этом.