Сегодня у нас есть 5 компаний, которые все используют Google для почтовых услуг.
example1.com. 3w IN MX 10 mail.Google.com.
example2.com. 3w IN MX 10 mail.Google.com.
example3.com. 3w IN MX 10 mail.Google.com.
example4.com. 3w IN MX 10 mail.Google.com.
example5.com. 3w IN MX 10 mail.Google.com.
На следующей неделе мы будем использовать другого поставщика (Cisco). Можно ли указывать на A или CNAME в MX?
example1.com. 3w IN MX 10 myCNAMEToCisco.example.com.
example2.com. 3w IN MX 10 myCNAMEToCisco.example.com.
example3.com. 3w IN MX 10 myCNAMEToCisco.example.com.
example4.com. 3w IN MX 10 myCNAMEToCisco.example.com.
example5.com. 3w IN MX 10 myCNAMEToCisco.example.com.
Идея в том, что я могу изменить myCNAMEToCisco.example.com любому другому поставщику. Меня беспокоит то, что может быть какая-то странная проверка, когда клиент говорит helo domain.com и ответ 220 может содержать неожиданное имя хоста или домена.
Есть ли проблема с использованием CNAME или записи A с электронной почтой таким образом?
Это определенно создало бы проблему, если бы вы указали MX записи в CNAME записи, поскольку это противоречит стандартам. Наиболее ясное объяснение дает RFC2181 §10.3:
10.3. Записи MX и NS
Имя домена, используемое в качестве значения записи ресурса NS, или часть значения записи ресурса MX не должны быть псевдонимом. Мало того, что спецификация ясна по этому поводу, но и использование псевдонима в любой из этих позиций не работает так хорошо, как можно было бы надеяться, и не отвечает амбициям, которые, возможно, привели к этому подходу. Это доменное имя должно иметь в качестве значения одну или несколько адресных записей. В настоящее время это будут записи A, однако в будущем могут быть приемлемы другие типы записей, дающие адресную информацию. Он также может иметь другие записи RR, но не CNAME RR.
Поиск записей NS или MX вызывает «дополнительную обработку раздела», в которой к ответу добавляются записи адреса, связанные со значением искомой записи. Это помогает избежать ненужных дополнительных запросов, которые легко предвидеть, когда был сделан первый.
Дополнительная обработка раздела не включает записи CNAME, не говоря уже об адресных записях, которые могут быть связаны с каноническим именем, полученным из псевдонима. Таким образом, если в качестве значения записи NS или MX используется псевдоним, адрес не будет возвращен со значением NS или MX. Это может вызвать дополнительные запросы и дополнительную нагрузку на сеть для каждого запроса. Администратору DNS легко избежать этого, разрешив псевдоним и поместив каноническое имя непосредственно в затронутую запись только один раз при ее обновлении или установке. В некоторых особо сложных случаях отсутствие дополнительных записей адреса раздела в результатах поиска NS может привести к сбою запроса.
Вы можете найти анекдотические доказательства через поисковые системы, которые некоторые Программное обеспечение DNS и MTA поддерживает это, но это следует рассматривать как исключение, а не правило. Отсутствие этой поддержки не будет считаться ошибкой большинством авторов программного обеспечения. Всегда избегайте указывать MX запись на CNAME.
Самая большая проблема, с которой вы сейчас сталкиваетесь, заключается в том, что TTL для MX записи в вашем примере - все три недели, а ваше изменение Следующая неделя. Я настоятельно рекомендую вам попросить отложить это переключение и снизить TTL примерно до десяти минут. Вы можете снова повысить TTL после завершения переключения.