У меня должно быть несколько записей MX, которые указывают на другого дюйм/с, которые находятся в различных подсетях, даже если у меня только есть один выделенный сервер?
Я предложил бы использовать Лак вместо этого, поскольку это сделано быть обратным прокси и может работать намного быстрее, чем nginx в той способности.
Лак настраивается для производительности. Это делает сумасшедший материал, любят, компилируют его файлы конфигурации в объекты C, которые затем загружаются в его память. Это не могло бы походить на много, но это действительно имеет значение, когда у Вас есть некоторая логика, определенная в конфигурациях (через собственный язык VCL Лака, который прохладен сам по себе).
Я вижу то, что Вы достигаете, bu nginx не предназначен, чтобы быть монолитной программой, которая делает все (в отличие от апача). Это предназначено, чтобы сделать несколько вещей и сделать их хорошо..., если существует лучший обратный прокси (Лак), используйте это вместо этого!
Просто мои мысли :)
Нет ничего необычного в том, чтобы иметь один сервер, который является единственным поставщиком электронной почты для домена. Нет требования , чтобы у домена было несколько принимающих почтовых серверов или , чтобы эти почтовые серверы находились в разных подсетях. Это, конечно, лучшая практика, но ни один RFC не нарушается, если не делать этого.
Мы получили предупреждение в системе проверки DNS, которое предупреждает только о наличие одной записи MX, а также предупреждение о том, что наши записи NS и MX не в разных подсетях.
Какую проверку DNS вы используете? Я думаю, что они очень агрессивны в своих предупреждениях, если только они не перечисляют их просто как предложения или «лучшие практики». Кроме того, испытывают ли ваши клиенты какие-либо проблемы или жалуются?
Повлияет ли это на входящую нагрузку на почтовый сервер?
Наличие двух записей MX, указывающих на один и тот же почтовый сервер, не повлияет на нагрузку.
Это вообще актуальная проблема?
Да, это серьезная проблема. Однако вы должны оценить, сколько избыточности вам нужно и какие услуги удовлетворяют ваши клиенты. Две записи MX, указывающие на один сервер, ничего не делают, кроме как поддерживать видимость. То же самое и с записями NS. Наличие двух почтовых серверов для вашего домена, которые синхронизируются и принимают почту для одних и тех же адресов электронной почты, увеличивает избыточность ваших систем. Однако вы, безусловно, можете управлять набором почтовых доменов на одном сервере и, таким образом, иметь только одну запись MX, ничего не нарушая. Убедитесь, что вы защищаете себя с помощью адекватных процедур резервного копирования и восстановления, которые дают вам приемлемое целевое время восстановления (RTO) и восстановление Point Objectives (RPO).
Как мы можем справиться с проблемами, о которых идет речь при проверке DNS?
Вы можете назначить несколько IP-адресов своему серверу, и ваш почтовый демон будет прослушивать эти несколько IP-адресов. Затем создайте Запись для каждого IP-адреса, а затем сопутствующие записи MX, указывающие на записи A. Это «решает» проблему? Это соответствует букве закона, но не духу. Он подавляет это предупреждение от любой проверки DNS, которую вы используете, но не решает основную проблему, о которой предупреждает вас предупреждение. В предупреждении говорится, что у вас должно быть два почтовых сервера, а не только две записи MX.
Чтобы действительно решить проблему, по возможности используйте два почтовых сервера.
Я не знаю, как с этим справиться. предупреждение о том, что записи MX должны быть в разных подсетях друг от друга.
Это, на мой взгляд, очень агрессивное предложение. Технически вы могли бы еще раз удовлетворить букву закона, если не дух. Вы можете попросить вашего провайдера сервера предоставить вам IP-адрес в другой подсети, но той же VLAN, в которой находится ваш сервер, и назначить его интерфейсу. Однако это ничего не даст, кроме ваших денег и внесет бесплодную сложность.
Где я могу узнать больше по этим темам?
Я бы порекомендовал DNS and Bind от Cricket Liu как хорошее место для Начало. Кроме того, изучите соответствующие RFC и постарайтесь понять их.
TL; DR
Предупреждения, которые вы получаете, говорят вам о недостатках вашей системы в соответствии с передовыми практиками. Они не являются абсолютно необходимыми для безопасной работы почтовой системы.