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

Рекомендации по управлению проблемами DNS при размещении сайтов клиентов

Я работаю в компании, которая в основном предоставляет продукты SaaS, но также будет размещать некоторые корпоративные веб-сайты наших клиентов. Мой вопрос касается рекомендаций по управлению DNS для доменных имен клиентов. Мои цели:

  1. Не ограничивать мою возможность изменять IP-адрес сервера, например, когда я перемещаю свои серверы на новый хост. В частности, я не хочу, чтобы от меня требовали связываться с клиентом для изменения DNS своего домена, если мне нужно изменить IP-адрес сервера. Часто клиенты теряют эту информацию или им приходится искать одного человека, который хоть сколько-нибудь знает о настройках домена.
  2. Сопоставьте оба .clientdomain.com и www.clientdomain.com на соответствующий сайт IIS.

Однако я сталкиваюсь с некоторыми типичными проблемами:

  1. Иногда консоль DNS, предоставляемая хостинговой компанией клиента, не позволяет использовать записи CNAME.
  2. Иногда консоль DNS, предоставляемая хостинговой компанией клиента, не позволяет мне создать запись CNAME для .spiffydomain.com потому что данная хостинговая компания создала запись SOA для этой записи или просто требует, чтобы .spiffydomain.com быть A запись.

Я считаю, что одно из решений №2 - использовать подстановочный знак для записи CNAME (т.е. *.spiffydomain.com). Это правильно?

Как другие люди, которые размещают много сайтов клиентов, управляют изменением записей DNS на своих серверах?

Дополнение

Дополнительным ограничением является то, что многие клиенты не хотят, чтобы их DNS размещал кто-то другой, а не они сами. Это может быть проблема безопасности или контроля, но, несмотря на это, мы часто не можем убедить их передать контроль над DNS нам. Одно из решений, конечно, состоит в том, чтобы просто обязать нас контролировать DNS, чтобы разместить их сайт, но маловероятно, что у наших продавцов хватит духу выполнить это поручение, если это означает потенциальную потерю бизнеса. С точки зрения продавца, неудобство управления DNS вызывает проблемы только для ИТ, а не для них.

Решение (2) не является подстановочным знаком CNAME для *.example.com потому что это не соответствует example.com.

example.com должен есть записи SOA и NS, и это невозможно чтобы иметь CNAME с другими типами записей.

Ваши требования невозможно удовлетворить, поэтому вам придется отказаться от одного из них.

Похоже, вы смешиваете масло и воду со своими требованиями к DNS: для клиентов, корпоративные сайты которых вы планируете разместить для них, вы действительно мало что сможете сделать, если не будете управлять их DNS за них; именно так работают мировые поставщики хостинга, потому что статические IP-адреса являются для них ценным активом, и когда вы используете свои собственные серверы имен, вам нужен статический IP-адрес для ваших записей A, и весь дешевый хостинг перестает работать для них и для ты.

Что касается SaaS, почему бы не сделать то, что делают Google Apps? Требуйте от клиентов создания записи CNAME для your.app.com (как это делает Google с ghs.google.com). Таким образом, вы можете в любой момент изменить A-запись your.app.com, и их CNAME останется прежним.

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

Это не сработает в некоторых случаях:

  • У них есть собственный DNS-сервер локально в офисе, использующий этот домен. Для запуска Active Directory или для переопределения определенных записей DNS, например почтового сервера.
  • У них есть домен в таких местах, как godaddy, и они также используют godaddy для электронной почты. Изменение whois для вас делает недействительным использование ими электронной почты godaddy.