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

17

Допустим, мы владеем зоной 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.

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

domain-name-system cname-record mx-record

— Михаил Горсух
источник

20

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

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

— Джастин скотт
источник

Да, я полагаю, что с этим столкнусь. Благодарность!

— Михаил Горсух

2

Я также должен отметить, что для тех, кто читает это в будущем, причина этого ограничения заключается в том, что CNAME должен ссылаться на «каноническое имя» для поиска хоста. Например, если у вас есть хост x2.example.com, который является записью CNAME, указывающей на x1.example.com, то любой распознаватель, ищущий x2, должен увидеть CNAME, заменить все, что он делает для x2, на x1 и начать все сначала. , Если у вас была запись MX для x2 в дополнение к CNAME, то, если у x1 также была запись MX, есть вероятность, что они будут другими, что нежелательно, поэтому они просто запрещают это.

— Джастин Скотт

18

После большой работы и исследований здесь я нашел приемлемое решение. Во-первых, важно, чтобы мы все следовали 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. Ура!

— Михаил Горсух
источник

4

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

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

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

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

— Zoredache
источник

3

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

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

— Дуг Люксем
источник

Я хотел попробовать использовать DNAME с некоторыми из наших доменов SSL, но я слышал, что все еще есть проблемы со старыми DNS-серверами и т. П. Или DNAME безопасно использовать на производственных серверах?

— Drybjed

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

— Даг Люксем

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

— bortzmeyer

3

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

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

— MikeyB
источник

1

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

— Ошеров
источник

2

Это верно; документированное поведение для SMTP-серверов, совместимых с RFC5321, заключается в том, чтобы сначала проверить наличие записи MX для домена, а в случае сбоя - проверить наличие записи A. Такое поведение является реальной технической причиной, по которой MX не должен быть CNAME: он перестанет разрешаться после первого пригодного ответа.

— Адаптер

0

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

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

— Bachsau
источник

-4

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.

— drybjed
источник

4

Это может работать, но это нарушает RFC1034 и RFC1219, которые утверждают, что никакие другие записи ресурсов не могут иметь то же имя, что и CNAME.

— Даг Люксем

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

— Михаил Горсух

Какой DNS-демон? Я использую BIND9, который должен работать с этой конфигурацией без проблем. Может пора обновить? Большая инфраструктура, я полагаю?

— Drybjed

Я использую MyDNS. Это довольно большая конфигурация, и этот маленький демон был благословением до этого момента. Я подумываю над его исправлением, но мне не очень интересно иметь дело с какими-либо побочными эффектами, которые его вызывают. Если это идет вразрез с RFC, это звучит как плохая идея.

— Майкл Горсуч

@Maciej - конечно, ваш авторитетный сервер может разместить эти записи. Тем не менее, они могут запутать большинство рекурсивных серверов, которые их запрашивают.

— Альнитак