DNS хостинг как выбрать сервис для управления зоной домена

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

DNS хостинг обслуживает записи домена и может находиться отдельно от регистратора и сервера сайта. Перед сменой NS перенесите всю зону, включая почтовые записи, и проверьте DNSSEC. Смена DNS-провайдера не переносит файлы сайта и почтовые ящики.

Регистратор, DNS и сервер сайта

Регистратор оформляет домен и делегирование. Авторитетные DNS-серверы отвечают, куда направить запросы к его именам. Веб-хостинг хранит приложение и принимает HTTP-запросы. Одна компания может оказывать все услуги, но технически это разные части, и перенос одной не означает перенос остальных.

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

Какие записи сохранить

Выгрузите существующую зону и отдельно сверьте A, AAAA, CNAME, MX, TXT и записи проверки владения. У почты могут быть SPF, DKIM и DMARC, а у внешних сервисов — собственные TXT. Экспорт помогает, но не доказывает полноту: некоторые панели скрывают автоматически созданные записи или используют собственные форматы.

Не копируйте старые NS как обычные записи без понимания делегирования. Для каждой записи сохраните имя, тип, значение и TTL. CNAME имеет ограничения совместного использования с другими типами на одном имени; особые функции провайдера для корня зоны нужно переносить с учётом их реализации. Проверьте также поддомены, которые не видны на главной странице сайта.

TTL и окно переключения

TTL задаёт срок кэширования DNS-ответа. Уменьшение значения непосредственно в момент переключения не удаляет уже сохранённые ответы у клиентов. Планируйте снижение заранее, если этого требует миграция, и учитывайте отдельное кэширование делегирования. Фраза «DNS обновится через несколько минут» не является гарантией для всех сетей.

Перед сменой NS запросите новую зону напрямую у её авторитетных серверов. После переключения сравните ответы из нескольких независимых сетей и проверьте сайт и почту. Разные ответы во время перехода могут быть ожидаемы, однако неверный MX или пропущенный TXT исправлять нужно сразу. Сохраните доступ к старой зоне до завершения согласованного окна.

DNSSEC и управление доступом

DNSSEC позволяет проверять подлинность подписанного DNS-ответа, но не шифрует посещение сайта и не заменяет HTTPS. При переносе важно согласовать подпись зоны и DS-запись у регистратора. Несогласованная цепочка может привести к ошибкам разрешения у валидирующих резолверов, даже если отдельный сервер отвечает правильно.

Назначайте отдельные роли для просмотра и изменения зоны, включайте доступные методы защиты аккаунта. API-токен должен иметь минимальную область действия. Наличие нескольких NS не доказывает независимость инфраструктуры: уточните архитектуру и доступность сервиса в условиях провайдера. Резервную DNS-схему проектируют заранее; случайное смешение несогласованных серверов создаёт непредсказуемые ответы.

Перенос только DNS-зоны

Сначала подготовьте новую зону, затем проверьте записи и согласуйте DNSSEC, после этого изменяйте делегирование. Сервер сайта продолжает хранить те же файлы, пока его адреса в зоне не изменены. Почта остаётся на прежнем сервисе, если MX и связанные записи перенесены корректно.

Для приёмки составьте таблицу важных имён: основной домен, www, почта, API и административные поддомены. Зафиксируйте ожидаемые значения и фактический ответ. Ошибку DNS отделяйте от ошибки приложения: правильный IP не подтверждает сертификат, а HTTP 500 после разрешения имени чаще требует проверки веб-сервера и кода.

Письма после переноса DNS

Перед сменой NS сравните новую зону со старой построчно. Проверить только A-запись сайта недостаточно: для почты нужны MX и связанные записи аутентификации. При включённом DNSSEC согласуйте изменение DS у регистратора с настройкой новой зоны. Несогласованная цепочка доверия может сделать правильные записи недоступными для проверяющих резолверов.

Когда менять DNS отдельно от хостинга

Если проблема находится в обслуживании зоны, перенос файлов сайта не обязательно нужен. И наоборот: новая машина не исправит неверный ответ старых NS. Сначала определите, где возникает отказ. Проверьте актуальную делегацию, ответы авторитетных серверов и то, какие записи получают обычные посетители. Отсутствие ответа одного промежуточного резолвера ещё не доказывает аварию всех NS поставщика.

Перед сменой сделайте экспорт и составьте карту зависимостей. Для каждой записи должно быть понятно назначение: сайт, почта, подтверждение сервиса, выдача сертификата или служебный поддомен. Если непонятно, зачем нужна TXT-запись, не удаляйте её только ради чистоты. Смена DNS не должна случайно отменить проверку домена у внешней платформы, которой продолжает пользоваться отдел продаж.

Запланируйте переходный период с учётом кеширования и DNSSEC. Снижение TTL непосредственно перед переносом не меняет срок уже сохранённых старых ответов. После делегации проверьте сайт и почту раздельно. Старую зону сохраняйте достаточно долго для предусмотренного перехода; готовность нового интерфейса не означает, что все клиенты уже перешли на него.

Как отличить отказ DNS от отказа самого сайта

Браузер сначала должен получить адрес сервера. Если этот шаг не завершился, приложение ещё не получало запрос и его журналы могут оставаться пустыми. В такой ситуации увеличение памяти, перезапуск базы и переустановка CMS не устраняют исходную проблему. Начните с полного имени, которое вводит посетитель: основной домен, www и поддомен кабинета могут иметь разные записи и обслуживаться разными площадками.

Сопоставьте ответы нескольких резолверов с действующей зоной у DNS-провайдера. Отдельно посмотрите A, AAAA и цепочки CNAME. Различие не всегда означает аварию: после недавней смены записи один кеш уже обновился, другой продолжает хранить старое значение. Запишите, когда менялась зона, какое значение было раньше и когда заканчивается срок его кеширования. Это поможет отделить ожидаемый переходный период от ошибки настройки.

При смене NS заранее перенесите всю зону. В ней находятся не только адреса сайта, но и записи почты, подтверждения владения, служебные поддомены и настройки внешних платформ. Скриншот панели удобен для быстрой сверки, однако машиночитаемый экспорт надёжнее: длинные TXT-записи легко скопировать с ошибкой. Доступ к регистратору и доступ к DNS-панели также могут принадлежать разным людям.

Если включён DNSSEC, изменение поставщика нужно согласовать с состоянием DS у регистратора. Правильный адрес не поможет, когда проверяющий резолвер не может проверить цепочку доверия. Удалять записи наугад опасно: сначала изучите процедуру выбранного поставщика и подготовьте возврат. Успех проверки фиксируют по доменному имени из внешней сети, а не по тому, что новая запись появилась в интерфейсе панели.

Сертификат, имя сайта и переадресация: три отдельные проверки

Проверку HTTPS выполняйте с тем именем, которым пользуется посетитель. Открытие IP вместо домена меняет условия: сервер может выбрать другой виртуальный хост, а сертификат — не содержать этот адрес. Ошибка в таком тесте ничего не говорит о нормальном обращении к сайту. Для предварительной проверки новой площадки используют корректное сопоставление имени и адреса, сохраняя проверку сертификата.

Разберите цепочку переходов целиком. Например, посетитель вводит www, получает редирект на домен без www, затем открывает форму на поддомене. HTTPS должен работать на первом адресе ещё до переадресации. Исправный сертификат конечной страницы не исправляет ошибку на входе. Повторяющиеся переходы между HTTP и HTTPS часто связаны с тем, что приложение неверно понимает исходную схему за прокси.

У сертификата есть срок действия, набор имён и цепочка доверия. Автоматическое продление — отдельная задача: для него нужны доступная проверка владения доменом, правильный маршрут и действующие настройки клиента. После переезда проверьте не только сегодняшнюю дату окончания, но и способ следующего продления. На старой площадке могли остаться настройки, от которых зависела автоматизация.

Предупреждение браузера нельзя устранять отключением проверки TLS на клиенте. Это скрывает симптом и ослабляет защиту соединения. Сначала сверяют имя, срок, цепочку и часы устройства, затем ищут проблему прокси или точки выдачи сертификата. В отчёте полезно указать, какой узел реально отвечал. Если перед сервером стоит CDN, сертификат у клиента и сертификат между CDN и источником могут управляться независимо.

Как составить журнал проверки, который действительно помогает

Вместо записи «иногда тормозит» зафиксируйте конкретное действие: какой адрес открывали, из какой сети, когда началась попытка и чем закончилась. Укажите часовой пояс, устройство и существенные настройки подключения. Для сравнения достаточно нескольких стабильных условий; большой журнал случайных экспериментов с разными браузерами и адресами часто только затрудняет поиск причины.

Разделяйте наблюдение и объяснение. «Соединение не установилось за время ожидания» — результат проверки. «Провайдер заблокировал сервер» — версия, которой нужны дополнительные подтверждения. Это различие важно при общении с поддержкой: специалист должен повторить отказ и найти нужный участок журналов, а не доказывать или опровергать заранее сформулированное обвинение. Повторяемость сильнее впечатления от одного неудачного открытия.

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

Не превращайте журнал в хранилище секретов. Для технического разбора обычно не нужны полный пароль, сессионные cookies, содержимое заявки или персональные данные покупателя. Идентификатор тестового обращения можно сопоставить с записью у ответственного сотрудника без публикации всей базы. Законченная проверка отвечает на четыре вопроса: что воспроизведено, что изменено, что после этого заработало и какие условия пока остаются непроверенными.

Как добиться от поддержки полезного ответа

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

Затем уточните границу ответственности. Хостер может проверить машину и канал, разработчик — приложение, а поставщик внешнего API — свою часть обмена. Фраза «сервер доступен» иногда верна, но не закрывает вопрос о форме или оплате. Попросите указать, какой уровень уже проверен, на каком основании и кому передать следующую часть диагностики. Это помогает избежать бесконечного пересылания одного тикета.

Если предлагают увеличить тариф, попросите связать предложение с измерением. Какой лимит достигнут, в какое время, какой процесс его использует и почему изменение должно помочь? Если рекомендуют сменить IP, выясните, чем подтверждена проблема адреса и как будет проверяться новый вариант. Конкретное объяснение важнее обещания «обычно помогает». Отсутствие немедленного ответа также полезно зафиксировать как нерешённый вопрос, а не как подтверждённую причину.

Для срочного случая заранее узнайте канал эскалации и круг включённых работ. Круглосуточный приём сообщений не обязательно означает круглосуточное сопровождение кода приложения. После восстановления запросите короткое описание выполненных действий и оставшихся ограничений. Не обязательно требовать большой отчёт при каждом отказе, но повторяющаяся проблема без понятной причины должна влиять на решение о дальнейшем размещении и сопровождении.

Кто управляет аккаунтом и как восстановить доступ

Контроль над размещением начинается раньше входа по SSH. Важны доступ к аккаунту провайдера, почте восстановления, оплате, домену и независимой консоли. Если всё зарегистрировано на личный адрес одного подрядчика, компания зависит от его доступности даже при исправном сервере. Проверьте, кто юридически и технически может восстановить вход, сменить ответственного и выгрузить данные.

Разделяйте роли. Сотруднику, который получает счета, обычно не нужен root, а разработчику не всегда нужен доступ к платёжным данным организации. Общий пароль для всех затрудняет отзыв прав и разбор инцидентов. По возможности используйте отдельные учётные записи, предусмотренные роли и многофакторную защиту. Секреты передают через согласованный защищённый канал, а не добавляют в общую таблицу проекта или публичный тикет.

Способ аварийного входа проверяют до изменения сети и правил доступа. Консоль провайдера полезна, если SSH недоступен, но она сама зависит от входа в личный кабинет. Поэтому путь восстановления нужно рассматривать целиком. После изменения ключей или административного порта проверяйте новое соединение, сохраняя текущую рабочую сессию до подтверждения результата. Не рассчитывайте на то, что когда-нибудь удастся восстановить доступ через знакомого инженера.

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

Переезд без потери новых данных

Главная сложность переноса часто находится между первой копией и окончательным переключением. Пока команда проверяет новую площадку, на старой появляются пользователи, заказы, файлы и изменения. Если просто включить вчерашнюю копию, эти данные останутся позади. Поэтому ещё до переноса определяют, где разрешена запись, как будет выполнена финальная синхронизация и нужен ли короткий режим обслуживания.

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

Перед переключением назначают один источник актуальных данных. Две независимо работающие базы быстро расходятся; последующее объединение не всегда возможно простым импортом. Для магазина важны новые заказы, для кабинета — действия пользователей, для файлового сервиса — загруженные объекты. Способ синхронизации выбирает специалист, который понимает эти данные. Универсальная команда копирования не заменяет это решение.

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

Как уменьшить зависимость от одной компании

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

Отдельно рассмотрите домен, DNS и почту. Размещение всех услуг в одном кабинете удобно, однако увеличивает последствия отказа этого кабинета или поставщика. Разделение тоже не бесплатно: появляются дополнительные настройки, счета и обязанности. Решение выбирают по критичности проекта и возможностям команды. Нет универсального требования непременно разнести каждую услугу, но общие точки отказа должны быть известны владельцу.

Для резервного варианта важны совместимость и доступность средств оплаты. Запасной провайдер, у которого нельзя быстро активировать нужный продукт, мало помогает во время простоя. Заранее проверьте процедуру регистрации, допустимое использование, способ загрузки данных и требования к окружению. Не нужно покупать всё сразу; иногда достаточно проверенной копии и понятного маршрута развёртывания, если допустимое время перерыва это позволяет.

Уход от зависимости не означает постоянные переезды в поиске идеальной компании. Каждая миграция несёт собственные риски. Полезнее регулярно проверять экспорт и восстановление, сохранять контроль над аккаунтами и знать стоимость выхода. Тогда решение о смене площадки можно принять по подтверждённым причинам, не оставаясь заложником отсутствующего архива или единственного человека, который знает, как устроен проект.

Как настроить проверку, которая замечает полезный результат

Самая простая проверка отвечает на вопрос, доступен ли конкретный адрес. Этого достаточно для части технических задач, но недостаточно для бизнеса. Страница ошибки может вернуть успешный код, а главная — открываться из кеша при неисправной базе. Поэтому рядом с проверкой HTTP нужен хотя бы один сценарий, связанный с назначением проекта: поиск, вход, безопасная тестовая заявка или чтение данных из API.

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

Выберите несколько точек наблюдения по аудитории. Удалённый сервер мониторинга не показывает опыт каждого мобильного оператора, но помогает заметить общую недоступность. Ручные контрольные проверки из реальных сетей дополняют картину. Записывайте ограничения: тестовый пользователь, отдельный адрес и неполный сценарий не равны всем возможным действиям посетителей. Не следует утверждать «работает у всех» по одной зелёной панели.

Для каждого уведомления нужен получатель и следующий шаг. Если сообщения приходят в канал, который никто не читает ночью, круглосуточный мониторинг ещё не означает круглосуточную реакцию. Договоритесь, кто подтверждает получение, кто связывается с поставщиком и кто информирует бизнес. После исправления выполните исходную проверку, разберите пропущенные обращения и скорректируйте сигнал, если он оказался слишком шумным или не заметил реальную проблему.

Почему наличие архива ещё не означает готовность к восстановлению

Резервная копия должна соответствовать тому, что потребуется запустить заново. Для простого сайта это файлы и база, для приложения дополнительно нужны конфигурация, перечень версий, постоянные данные и доступ к секретам. Содержимое диска нельзя считать достаточным без понимания того, где лежит актуальная информация. Некоторые данные могут храниться в подключённом объектном хранилище, внешней базе или отдельном сервисе.

Проверьте согласованность копии. Если файлы и база относятся к разным моментам, восстановленное приложение может ссылаться на отсутствующие вложения или неверные записи. Метод резервирования выбирают с учётом движка и нагрузки: штатная выгрузка, снимок с предусмотренной подготовкой либо другая документированная процедура. Слепое копирование каталога работающей базы не является универсальным способом безопасного бекапа.

Хранение только в том же аккаунте оставляет общий риск. Ошибка доступа, компрометация аккаунта или серьёзный отказ площадки может затронуть и рабочую систему, и архив. Независимая копия полезна лишь при понятном управлении: кто получает уведомления об ошибке, кто может скачать данные и где находится инструкция. Не переносите секреты в открытые папки ради удобства; доступ к резерву часто не менее чувствителен, чем доступ к самому серверу.

Проверка восстановления проводится на отдельной площадке. Рабочие письма, оплаты, уведомления и фоновые задания там отключают или переводят в предусмотренный тестовый режим. Сначала проверяют чтение данных и запуск, затем критичное действие. В результате должны быть известны не только дата архива, но и время восстановления, необходимая помощь и способ учёта данных, появившихся после копии. Без этого обещание «бекапы каждый день» мало говорит о реальном перерыве.

Первые действия во время недоступности

Сначала подтвердите масштаб. Не работает только ваш браузер, одна сеть, одна функция или весь проект? Проверьте независимый канал, официальное сообщение поставщика и свои последние изменения. Зафиксируйте время начала по имеющимся данным, не подменяя его моментом первой жалобы. Это поможет отличить массовый инцидент от локальной ошибки и не выполнять лишние операции на исправных компонентах.

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

Бизнесу нужна отдельная связь с клиентами. Контактная страница на том же недоступном сервере не подходит для сообщения об аварии. Подготовьте независимый канал, объяснение текущего ограничения и способ передать срочное обращение. Не обещайте время восстановления без основания. Если есть платная реклама или запись на услуги, ответственный должен решить, продолжать ли привлекать людей на неработающий путь.

После технического запуска не завершайте разбор немедленно. Проверьте вход, запись данных, доставку обращений и очереди. Найдите действия, которые пользователи начали в период отказа и могли повторить. Затем составьте короткий итог: причина с уровнем подтверждения, выполненные изменения, последствия и конкретная профилактика. Формулировка «всё починили» не помогает, если через неделю команда снова будет искать тот же контакт и ту же резервную копию.

Договор, счета и ответственность команды

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

Для организации заранее проверьте оформление аккаунта, выставление счёта, подтверждающие документы и уведомления о продлении. Отдельный вопрос — изменения реквизитов и ответственного сотрудника. Удобный первый платёж не означает, что следующий пройдёт без участия человека. Если остановка услуги связана с оплатой, технические проверки сервера не помогут до решения административной причины. Уведомления должны попадать к тем, кто способен вовремя отреагировать.

Обсудите прекращение использования: как получить данные, сколько сохраняется доступ и что происходит после остановки. Конкретные сроки и возможность возврата средств подтверждают по действующим условиям, а не по чужому обзору. Если для проекта важна претензия или компенсация, сохраните сведения о периоде отказа и обращения. Сам факт простоя не позволяет обещать определённую выплату без изучения договора и обстоятельств.

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

Что оставить следующему специалисту после запуска

Рабочая система не должна существовать только в памяти человека, который её установил. Нужна короткая инструкция: что запущено, где находятся данные, как выполняется штатный перезапуск и какие действия опасны. Она не обязана повторять всю документацию продуктов. Её задача — объяснить особенности именно этого проекта, которые нельзя надёжно угадать по списку установленных пакетов.

Разделите описание и секреты. В инструкции можно указать, что для интеграции нужен определённый доступ и кто его выдаёт, но не хранить сам пароль. Для каждой внешней зависимости полезны владелец, назначение и способ проверки. Если один домен используется только для фонового обмена, это всё равно важная часть работы. При аварии его легко забыть, рассматривая только видимые страницы.

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

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

Рейтинг: 7 хостингов для сравнения условий

Ссылки на провайдеров партнёрские: автор может получить вознаграждение. Рейтинг помогает составить список для сравнения; наличие компании в нём не подтверждает поддержку всех описанных функций. Уточните их для выбранного тарифа вместе с ценой продления.

1 место. Timeweb

До оплаты уточните: экспорт всех записей и история изменений.

2 место. МакХост

До оплаты уточните: a, aaaa, cname, mx и служебные txt.

3 место. Бегет

До оплаты уточните: поддержка dnssec и перенос ds.

4 место. SpaceWeb

До оплаты уточните: api, роли и защита аккаунта.

5 место. Hostland

До оплаты уточните: ttl и независимость ns.

6 место. SprintHost

До оплаты уточните: проверка новой зоны до делегирования.

Практический сценарий

В условной компании сайт размещён у одного хостера, почта — у другого. При переносе DNS администратор копирует только A и www, и входящие письма перестают приходить. Исправление начинается со сравнения старой и новой зоны: восстанавливаются MX и записи почтовой аутентификации, затем проверяются DNS-ответы и реальная доставка согласованным тестом. Переустановка сайта не требуется. Чтобы избежать повторения, список критичных записей включают в приёмку, а доступ к старой зоне сохраняют до окончания перехода.

Таблица приёмки и вопросы поддержке

Частые вопросы

Можно ли держать DNS отдельно от сайта?

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

Меняется ли почта при смене NS?

Сами ящики не переносятся, но отсутствие правильных MX и TXT нарушит маршрутизацию и аутентификацию.

Заменяет ли DNS хостинг сервер сайта?

Нет. DNS сообщает адрес сервиса, а файлы и приложение обслуживаются веб-хостингом.

Вывод и источники

Технические сведения проверены при подготовке материала 10 октября 2026 года. Перед настройкой сверьтесь с документацией своей версии.

• Типы DNS-записей
• Принцип DNSSEC

Подробнее:

Основной рейтинг хостингов 2026 года

Дополнительные технические источники, проверены 2 ноября 2026 года:

• Cloudflare: TTL и кеширование DNS