Сайт состоит из двух отдельных услуг: домена, то есть имени сайта в интернете, и хостинга — сервера, где лежат файлы сайта и база данных. Большинство берёт оба сервиса в одном месте, и это удобно. Но некоторые компании намеренно держат домен у одного провайдера, а хостинг у другого. У такого подхода есть своя логика, и он особенно полезен бизнесу, сайт которого должен жить долго. Разберём, когда этот выбор себя оправдывает и какие в нём есть ловушки.
Домен — актив бизнеса, хостинг — заменяемая услуга
Доменное имя годами запоминают клиенты, его печатают на визитках, в рекламе, в почтовых адресах. Хостинг же по мере роста сайта можно сменить несколько раз: с небольшого виртуального хостинга на VPS, затем на выделенный сервер. Поэтому многие специалисты советуют рассматривать домен как долгосрочный актив, а хостинг — как временную инфраструктуру. Если они разделены, смена хостинга никак не затрагивает домен.
На практике это значит, что при разногласиях с хостинг-провайдером, ухудшении качества или неподходящей цене вы просто берёте новый хостинг и меняете DNS-записи домена. Не нужно переносить домен к другому регистратору, ждать код авторизации или решать вопросы владения.
Контроль владения и доступа
Главное преимущество раздельного хранения — контроль. Бывает, что веб-студия или разработчик, сделавшие сайт, регистрируют домен и хостинг на свой аккаунт. Когда сотрудничество заканчивается, клиент не знает, кому на самом деле принадлежит домен. Если же домен находится в собственном аккаунте компании и зарегистрирован на неё, право управлять именем остаётся у вас, у кого бы ни был хостинг.
При этом два аккаунта — это две точки безопасности. Поставьте на аккаунт домена сильный уникальный пароль, по возможности включите двухфакторную проверку, а привязанный к аккаунту почтовый адрес держите не на сервере хостинга, а в надёжной отдельной почте. Иначе при отключении хостинга вы не сможете даже получить письмо для восстановления пароля.
Где управлять DNS
При раздельном хранении возможны две схемы. В первой NS-записи домена указывают на DNS-серверы хостинг-провайдера, и все записи управляются в панели хостинга. Во второй DNS остаётся у провайдера домена, а вы вручную направляете записи A, MX и TXT на адреса хостинга. Вторая схема заметно ускоряет смену хостинга: вместо ожидания смены NS вы меняете одну A-запись.
; DNS у провайдера домена, хостинг в другом месте
misol.uz. 3600 IN A 203.0.113.10
www.misol.uz. 3600 IN CNAME misol.uz.
misol.uz. 3600 IN MX 10 mail.misol.uz.
mail.misol.uz. 3600 IN A 203.0.113.10
misol.uz. 3600 IN TXT "v=spf1 a mx ~all"
Для проверки текущего состояния достаточно команд:
dig +short NS misol.uz
dig +short A misol.uz
dig +short MX misol.uz
Если домен находится в sayt.uz, и смена NS-серверов, и ручное добавление DNS-записей выполняются на странице домена в кабинете.
Как сменить хостинг без простоя
Преимущество раздельного хранения особенно заметно при переезде. При правильном порядке действий сайт переходит на новый сервер почти незаметно для клиентов:
- За день-два до переезда снизьте TTL A-записи, например до 300 секунд, чтобы изменение распространилось быстрее.
- Полностью скопируйте сайт и базу на новый хостинг и проверьте работу.
- Протестируйте новый сервер до смены DNS: временно привяжите домен к новому IP в файле
hostsсвоего компьютера. - Смените A-запись на новый IP и оставьте оба сервера работать несколько часов.
- Когда всё стабильно, верните TTL и отключите старый хостинг.
# проверка нового сервера до смены DNS
curl -I --resolve misol.uz:443:203.0.113.20 https://misol.uz/
# проверка распространения изменения
dig +short A misol.uz @8.8.8.8
SSL-сертификат на новом сервере обычно выпускается после того, как домен направлен на новый IP, поэтому учтите этот шаг в плане. Если почта тоже на сервере хостинга, отдельно спланируйте перенос MX-записей и ящиков, иначе в день переезда письма могут потеряться.
Пример: логистическая компания в Ташкенте
Допустим, сайт средней логистической компании в Ташкенте изначально вёл знакомый разработчик: на своём хостинге и с доменом, зарегистрированным на свой аккаунт. Когда разработчик ушёл на другую работу, компания не могла обновлять сайт, а письма о скором окончании домена уходили на почту разработчика. После долгой переписки домен переоформили на компанию.
После этого компания изменила правило: домен хранится в её собственном аккаунте с включённым автопродлением, а хостинг выбирается по договорённости с обслуживающим разработчиком. Через два года, когда сайт вырос и переехал на VPS, поменяли только A-запись, и клиенты не заметили никакого перерыва.
Недостатки раздельного хранения
Этот подход не бесплатен: приходится работать с двумя аккаунтами, двумя сроками оплаты и двумя службами поддержки. Самая частая ошибка — пропустить срок одной из услуг. Хостинг оплачен, а домен истёк — и сайт всё равно не открывается. А при проблеме два провайдера могут кивать друг на друга: хостинг говорит «проверьте DNS», а провайдер домена — «сервер не отвечает». Поэтому полезно, чтобы в команде был человек, понимающий основы DNS.
- Включите автопродление домена и следите за балансом.
- Храните доступы к обоим аккаунтам в компании в надёжном месте.
- Запишите список DNS-записей в виде документа.
Для небольшого сайта такая сложность может оказаться лишней, и тогда удобнее держать всё в одном месте. Но если сайт важен для бизнеса и в будущем ожидаются изменения инфраструктуры, отдельное хранение домена под вашим контролем в долгосрочной перспективе себя оправдывает.