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

Возврат почты при использовании CNAME для корневого домена и балансировки нагрузки

Недавно мы перешли на EC2 и начали использовать amazon elb для балансировки нагрузки. Мы используем CloudFlare для DNS, что позволяет нам использовать cname для корня домена. Однако иногда люди говорят нам, что наши электронные письма возвращаются с некоторыми вариациями следующей ошибки:

first.last@ourdomain.com ... Отложено: наш-production-loadbalancer.elb.amazonaws.com отказал в подключении.

Мы используем приложения Google для почты, и наши записи MX настроены правильно, поэтому я не уверен, в какой момент почтовые клиенты или серверы пытаются разрешить наш домен и вместо этого получают запись cname.

Кто-нибудь понимает, почему записи MX игнорируются? Это результат использования CNAME? Я предполагаю, что то же самое могло бы / случиться, если бы мы указали запись A на IP-адрес, который также не принимал почту.

Если у вас есть домен example.invalid:

; example.invalid
$TTL    604800
@       IN      SOA     ns1.example.invalid. root.example.invalid. (
                     2006020201 ; Serial
                         604800 ; Refresh
                          86400 ; Retry
                        2419200 ; Expire
                         604800); Negative Cache TTL
;
@       IN      NS      ns1
        IN      MX      10 mail
        IN      CNAME   anotherdomain.invalid

Ты говоришь:

Эй, ты можешь найти example.invalid под любым адресом anotherdomain.invalid может быть найден. И, кстати, любые записи MX, записи SRV или другие материалы для example.invalid тоже что-то anotherdomain.invalid говорит тебе. Это означает, что почта отправлена ​​на example.invalid будет использовать запись MX для anotherdomain.invalid

Ссылки:

Я предполагаю, что у вас есть CNAME для балансировщика, помеченного оранжевым облаком в настройках DNS в CloudFlare? Если это так, вам следует войти в систему и изменить цвет облака с оранжевого на серый для этой записи CNAME.

Согласно RFC1034 §3.6.2

If a CNAME RR is present at a node, no other data should be present; this 
ensures that the data for a canonical name and its aliases cannot be different.

Таким образом, если у вас настроен CNAME в example.com тогда это единственная запись, которую вы могли там настроить. Все записи, относящиеся к этому домену, должны находиться под псевдонимом.

Например. Если у вас есть example.com IN CNAME acme.hosting-co.com тогда ваши записи NS, SOA, MX и т. д. должны находиться под acme.hosting-so.com. Они не могут быть под example.com.

Кроме того, если для домена не найдена запись MX, то в крайнем случае можно попробовать запись A для этого домена. Таким образом, правильно работающий MTA должен выполнить поиск вашего домена, найти CNAME, попробовать псевдоним, не найти там запись MX, вместо этого попробовать запись A (в данном случае ваш балансировщик нагрузки). Ваш балансировщик нагрузки, по-видимому, не может получать электронную почту.

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