DNS: Субдомены, которые Требуют И Записи MX и CNAME

customer.mywebservice.com должен быть CNAME к данному удаленному серверу. Так как тот сайт управляет своим собственным оборудованием и может изменить адреса в любом моменте времени, CNAME является требованием.

Кто-либо может думать о каких-либо обходных решениях?Спасибо!

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

Я не попробовал его, но gnudip, кажется, инструмент с открытым исходным кодом для упрощения динамических обновлений, не имея необходимость иметь дело с аутентификацией и создавая много зон на Вашем сервере DNS.

RHS CNAME customer.mywebservice.com имеют запись MX?

Если так, затем почтовый сервер будет использовать тот MX, чтобы найти, что почтовый сервер использует. Надо надеяться, можно управлять этим.

После большой работы и исследования здесь, я нашел приемлемое решение. Во-первых, важно, чтобы все мы следовали за RFCs. Я исправил свой сервер DNS для нарушения RFC, и я обнаружил, что несколько других главных серверов DNS не будут уважать изменение.

Соответствующее перемещение должно поместить MX на хост, на который указывает CNAME. Так, если customer.mywebservice.com является CNAME к рекордный loadbalancer.mywebservice.com, следует также создать запись MX для loadbalancer.mywebservice.com. Я проверил, что это работает со всеми главными сопоставителями.

Если запрос MX будет сделан для customer.mywebservice.com, то библиотека сопоставителя будет следовать за CNAME и получать надлежащий MX для финала запись. Ура!

Если ваши записи MX будут одинаковыми для всех этих записей, вы можете попытаться использовать DNAME для перенаправления XYZ.mywebservice.com на hosting.mywebservice.com. В разделе hosting.mywebservice.com добавьте соответствующие записи MX и A.

Я должен сказать, что я никогда не использовал записи DNAME в производстве, но вы можете прочитать о них подробнее в RFC2672 .

MX и CNAME - это полностью отдельные записи: первая определяет почтовый сервер для данного домена, вторая дает адрес домена. Это должно сработать:

@       IN      SOA     ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8h
)

                        NS      ns1.mywebservice.com.
                        NS      ns2.mywebservice.com.

customer                CNAME   offsite.host.
customer                MX 10   mail.server.

Ответ Майкла Горсуча в основном правильный, цепочка CNAME -> A + MX действительно работает ... в основном . Однако это вызывает некоторую некорректную работу некоторых MTA. Что я обнаружил при запуске этого решения в приличном масштабе:

• некоторые MTA просто отказываются найти запись.
• другие неправильно заменяют запись A там, где должно быть CNAME: т.е. я отправил письмо на адрес " joe@foo.example.com ", который соединяет CNAMES с web.example.com, у которого есть MX mail.example.com, а MTA переписывает заголовок конверта как" To: joe@web.example.com ".

Пока не ясно, насколько широко распространены эти проблемы (похоже, все google / hotmail / yahoo / и т. Д. Решают это правильно), но они определенно заставляют нас искать лучшие решения.

Возможным и действенным решением было бы создать базовое имя хоста для всех ваших клиентов и установить для него записи a и aaaa для внешнего сайта webserver и ваш mx, а затем CNAME для всех ваших клиентских доменов на одно имя хоста. Таким образом, вам нужно будет изменить только одну запись при изменении внешнего IP-адреса.

Это единственная проверка и возможный способ, поскольку CNAME является псевдонимом для полного набора записей, а не только.