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

Допустим, мы владеем зоной mywebservice.com.

Я бы хотел, чтобы каждый из моих клиентов получил свой собственный поддомен, такой как customer.mywebservice.com.

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

Люди также должны иметь возможность отправлять электронную почту на адрес inbox@customer.mywebservice.com, для чего потребуется простая запись MX.

Тем не менее, и вот где я хотел бы получить некоторые рекомендации:

Согласно RFC 1034 :

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.

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

Так что, похоже, у меня может быть проигрышная ситуация. Если я хочу использовать запись MX, мне нужно использовать A вместо CNAME.

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

К сожалению, вы сталкиваетесь с ограничением спецификации DNS. Наличие записи MX для того же имени хоста, которое определено как запись CNAME, не удастся в большинстве реализаций DNS-сервера. Некоторые старые DNS-серверы позволяют это, но в большинстве своем они были выведены из эксплуатации в пользу более новых и более безопасных реализаций.

Вместо того, чтобы использовать записи CNAME, вам нужно будет использовать записи «А» с IP-адресами сайтов клиентов напрямую, вместо того, чтобы совмещать имена.

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

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

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

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

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

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

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

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

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

Имеется ли в RHS CNAME customer.mywebservice.com запись MX?

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

Ответ Михаила Горсуха в значительной степени правильный, цепочка 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 / etc все решают правильно), но они, безусловно, заставляют нас искать лучшие решения.

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

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

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

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

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

клиент CNAME offsite.host.
Заказчик MX 10 mail.server.