[Главная](https://hmbastion.com/ru/) [Блог](https://hmbastion.com/ru/blog/) Инфраструктура Инфраструктура 5 мин чтения # Записи и TTL DNS: подготовьте изменение, которое можно проверить DNS сообщает клиентам, где искать сервис. Он не переносит данные приложения, не устанавливает сертификат и не делает новый сервер готовым. Надёжное изменение начинается с инвентаризации записей и заканчивается как подтверждением DNS, так и работающим приложением. Редакция HM Bastion Опубликовано 2026-10-26 ## В этом руководстве - [Определите авторитетную зону и людей, которые ею управляют](https://hmbastion.com/ru/blog/dns-records-ttl-cutover-checklist/#find-authoritative-zone) - [Знайте, что даёт каждая запись](https://hmbastion.com/ru/blog/dns-records-ttl-cutover-checklist/#map-record-types) - [Учитывайте ответы, уже находящиеся в кэшах](https://hmbastion.com/ru/blog/dns-records-ttl-cutover-checklist/#understand-cache-time) - [Проверьте ответ DNS, затем сервис за ним](https://hmbastion.com/ru/blog/dns-records-ttl-cutover-checklist/#verify-change-by-layer) - [Защитите валидацию DNSSEC и сохраняйте реалистичный откат](https://hmbastion.com/ru/blog/dns-records-ttl-cutover-checklist/#preserve-validation-and-rollback) [Все руководства по хостингу](https://hmbastion.com/ru/blog/) ## Практический вывод Меняйте записи, которые действительно управляют сервисом, учитывайте существующие сроки жизни кэша, проверяйте авторитетные и рекурсивные ответы отдельно и держите предыдущую конечную точку под контролем. ## Определите авторитетную зону и людей, которые ею управляют Разделите в своих заметках регистратора домена, авторитетного провайдера DNS и место хостинга. Они могут управляться через разные учётные записи. Регистратор управляет регистрацией домена и делегированием, а авторитетный сервис DNS публикует записи зоны, которые запрашивают резолверы. Перенос сайта на новый хост не обязательно требует изменения регистратора или серверов имён. Найдите активные авторитетные серверы имён и экспортируйте или конфиденциально запишите текущую зону перед её редактированием. Укажите точные имена, типы, значения и TTL, а не только скриншот основной записи сайта. Подтвердите, кто может одобрить и восстановить изменение. Панель DNS в старой учётной записи не доказывает, что её записи по-прежнему авторитетны для домена. Рассматривайте миграцию серверов имён как отдельное изменение с собственной проверкой. Она может затронуть всю зону, включая записи почты и подтверждения. Когда меняется только веб-назначение, сохранение существующей авторитетности DNS и редактирование соответствующей записи адреса или псевдонима часто упрощает проверку области изменений. ## Знайте, что даёт каждая запись | Тип | Назначение | Проверьте перед изменением хостинга | | --- | --- | --- | | A | Сопоставляет имя с адресом IPv4 | Цель обслуживает нужное имя хоста и конфигурацию HTTPS | | AAAA | Сопоставляет имя с адресом IPv6 | IPv6 достигает того же работающего сервиса, что и IPv4 | | CNAME | Создаёт псевдоним одного имени для другого имени | Цель — имя хоста, а не IP-адрес или полный URL | | MX | Определяет назначения доставки почты | Изменения сайта не перенаправляют входящую почту непреднамеренно | | TXT | Содержит подтверждения и другие текстовые политики | Необходимые записи владения и аутентификации почты остаются нетронутыми | | CAA | Ограничивает выпуск сертификатов удостоверяющими центрами | Предполагаемый издатель сертификата совместим с политикой | Например, у example.com может быть запись A, а www.example.com может ссылаться на неё через CNAME. Проверьте оба имени, видимые пользователям. Изменение адреса для первого может повлиять на псевдоним, тогда как несвязанное имя хоста может по-прежнему указывать напрямую на старый сервер. Возможности псевдонима на вершине зоны зависят от провайдера DNS; следуйте его документированному механизму, а не предполагайте, что любой интерфейс принимает обычный CNAME на вершине. Не оставляйте старую запись AAAA, когда назначение IPv4 перемещается. Некоторые клиенты могут продолжать обращаться к устаревшему сервису IPv6, пока другие используют новый адрес IPv4. Подтвердите предполагаемую доступность IPv6 перед публикацией этого пути. Аналогично, перенос сайта не является причиной заменять записи MX или TXT, если почтовый сервис остаётся на месте. ## Учитывайте ответы, уже находящиеся в кэшах TTL задаёт время жизни ответа в кэше для DNS. Уменьшение значения в авторитетной записи не сокращает более старый ответ, уже закэшированный в другом месте. Если текущее значение — 86 400 секунд, а для запланированного переключения нужно значение 300 секунд, снизьте его заранее настолько, чтобы прежний срок жизни успел истечь. Эти значения иллюстрируют планирование; доступные варианты зависят от сервиса DNS и записи. DNS также может кэшировать ответ о том, что имя не существует или не имеет запрошенной записи. Этот негативный кэш регулируется правилами DNS и информацией о зоне, а не TTL записи, добавленной позже. Не допускайте, чтобы это выяснилось при запуске: проверяйте новое имя хоста только после того, как оно намеренно опубликовано и учтено в плане. TTL — это не обратный отсчёт до одновременного переключения по всему миру. Клиенты, рекурсивные резолверы и существующие подключения приложений обновляются не одновременно. Держите прежнюю конечную точку под контролем на протяжении периода перекрытия. Если приложение принимает записи, план миграции должен определить единственный источник данных, пока трафик ещё может поступать на несколько адресов. ## Проверьте ответ DNS, затем сервис за ним - Зафиксируйте прежнее значение и точную предполагаемую замену. - Запросите затронутое имя и тип записи на каждом авторитетном сервере имён. - Сравните ответы от нескольких рекурсивных резолверов и отметьте оставшиеся TTL. - Проверьте каждое публичное имя хоста и оба семейства IP-адресов, которые действительно опубликованы. - Проверьте HTTPS и типичное поведение приложения, используя реальное имя хоста. - Наблюдайте остаточный трафик, прежде чем повышать TTL или выводить из эксплуатации прежнюю конечную точку. Отличайте ошибку в авторитетных данных от закэшированного старого ответа. Если авторитетные серверы расходятся, исследуйте публикацию зоны или делегирование. Если авторитетные данные верны, но один резолвер всё ещё отдаёт старый ответ, сравните оставшийся срок его жизни, прежде чем вносить ещё одну несвязанную правку. Повторяющиеся изменения значений затрудняют интерпретацию окна наблюдения. Правильный ответ с адресом не доказывает действительность сертификата или работоспособность виртуального хоста. HTTPS использует запрошенное имя хоста, и приложение должно его распознавать. Если в архитектуре есть прокси или CDN, понимайте, какой возвращённый адрес представляет этот посредник и какой параметр источника управляет его бэкендом. Держите результат DNS и проверку сервиса-источника как отдельные проверки. ## Защитите валидацию DNSSEC и сохраняйте реалистичный откат Если DNSSEC включён, миграция сервера имён или поставщика подписи должна учитывать родительскую запись DS и новые ключи подписи. Несоответствие может привести к тому, что валидирующие резолверы будут отклонять ответы. Следуйте документированной процедуре миграции как для обоих поставщиков, так и для регистратора, включая применимые сроки жизни кэша. Не удаляйте записи доверия и не отключайте валидацию как импровизированную первую реакцию на необъяснимую веб-ошибку. Сохраняйте прежние значения DNS вместе с записью об изменении, но помните, что они могут отменить. Восстановление старого адреса меняет, куда ведут будущие разрешения; оно не возвращает данные клиентов, принятые новым приложением. Используйте отдельный план миграции, чтобы решить, когда откат трафика безопасен и когда требуется сверка данных. Завершайте только после проверки приложения, почтовых зависимостей и резервных копий для восстановления. Примеры продуктов используют опубликованный каталог HM Bastion. Доступность, цены и доступные опции отображаются при настройке заказа. ## Выберите следующий фундамент. [Скоординируйте полную миграцию хостинга](https://hmbastion.com/ru/blog/hosting-migration-cutover-rollback/) [Выберите Швейцарию или Германию](https://hmbastion.com/ru/blog/switzerland-or-germany-hosting/) [Подтвердите требования к хостингу и сети](https://hmbastion.com/ru/support/) ## Источники и дополнительное чтение - [Документация Cloudflare DNS: типы записей](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/) - [Документация Cloudflare DNS: TTL](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) - [IETF RFC 2308: негативное кэширование DNS](https://www.rfc-editor.org/rfc/rfc2308) - [Документация Cloudflare DNS: DNSSEC и миграции](https://developers.cloudflare.com/dns/dnssec/) ## Продолжить изучение [ Планирование 3 мин чтения ## VPS, выделенный сервер или веб-хостинг: выберите нужный уровень ответственности Соотнесите ваше приложение, операционные обязанности и потребности в ресурсах с тремя семействами хостинга HM Bastion. ](https://hmbastion.com/ru/blog/vps-dedicated-or-web-hosting/) [ Инфраструктура 4 мин чтения ## Швейцария или Германия: выберите регион хостинга с помощью практического чек-листа Сравните маршруты аудитории, зависимости приложения, региональные цены и требования к развёртыванию, прежде чем выбирать Швейцарию или Германию. ](https://hmbastion.com/ru/blog/switzerland-or-germany-hosting/)