Продление домена кажется простой задачей — пока однажды домен не «залипает» в неожиданном статусе, автопродление не срабатывает, а сайт и почта оказываются на паузе. Ниже — практичный разбор для админов/DevOps: как устроены auto renew, EPP-статусы, защита registry lock, и что реально происходит в grace period и redemption period.
Как на самом деле происходит продление домена
У домена есть несколько участников: регистратор (панель, биллинг, ваши настройки) и реестр (registry), который ведёт «истинное» состояние зоны верхнего уровня. Продление — это операция, которая в конечном итоге фиксируется в реестре: меняется дата expiry и связанные флаги/статусы.
Нюанс, из-за которого возникают сюрпризы: «в панели всё включено» не означает, что команда продления реально дошла до реестра и была применена. Автопродление и ручное продление могут идти разными путями, с разными условиями (баланс, лимиты, блокировки, регламенты подтверждения).
Частые причины проблем с продлением:
- включён auto renew, но не проходит оплата/списание;
- у домена статусы, запрещающие операции (domain statuses);
- включён registry lock, и для действий требуется отдельное подтверждение;
- домен уже вышел за срок и находится в послесрочных периодах: grace period или redemption period;
- неверные ожидания по таймингам: дата окончания регистрации не равна дате фактического «падения» делегирования.
Auto renew: почему «включено» не означает «продлено»
Auto renew — это настройка у регистратора, которая говорит: «попробовать продлить домен автоматически». Обычно автопродление запускается за N дней до даты окончания (или в саму дату), но конкретное окно зависит от регистратора и правил TLD.
Что проверить, чтобы auto renew работал предсказуемо:
- Источник оплаты: актуальная карта/баланс, разрешены ли рекуррентные списания, нет ли лимитов.
- Уведомления: письма о неуспешной оплате часто приходят заранее — важно, чтобы их не резал антиспам и они уходили в независимый ящик.
- Ограничения зоны: минимальный/максимальный срок регистрации, особенности по восстановлению/продлению.
- Время обработки: даже после успешного списания применение в реестре может быть не мгновенным.
Практическое правило: не полагайтесь на auto renew как на единственный механизм. Мониторьте дату expiry и статусы так же дисциплинированно, как сроки у SSL.
Отдельная «серая зона» — биллинг: недостаточно средств, отклонение 3-D Secure, корпоративные лимиты, валютные/налоговые нюансы. Поэтому доменный мониторинг не должен зависеть от почты на этом же домене.
Если вы только выбираете провайдера для портфеля доменов, полезно заранее оценить качество биллинга/уведомлений и скорость поддержки. Для задач регистрации и управления зонами пригодится регистрация доменов с прозрачными статусами и понятными правилами продления.
Domain statuses: какие статусы ломают продление и операции
Domain statuses — это набор флагов (обычно EPP-статусы), которые описывают, что разрешено делать с доменом: обновлять контакты, менять NS, переносить к другому регистратору, удалять и т.д. Один домен может иметь несколько статусов одновременно.
Важно: часть статусов выставляет регистратор (client*), часть — реестр (server*). Если блокировка на стороне реестра, снять её «в панели» может быть невозможно без процедуры через поддержку.
Статусы, которые чаще всего мешают эксплуатации
- clientTransferProhibited / serverTransferProhibited — запрет трансфера. На продление обычно не влияет, но критично, если вы планировали перенос регистратора «в последний момент».
- clientUpdateProhibited / serverUpdateProhibited — запрет обновлений. Может блокировать смену NS/контактов/DNSSEC и усложнить восстановление после инцидента.
- clientDeleteProhibited / serverDeleteProhibited — запрет удаления. Обычно защитный флаг, но иногда идёт «пакетом» с другими запретами.
- serverHold / clientHold — домен «на удержании», часто не делегируется в DNS (резолв может перестать работать). Для продакшена это самый болезненный статус.
- pendingDelete — финальная стадия удаления. На этом этапе стандартное продление, как правило, уже недоступно.
Если видите hold — реагируйте как на инцидент: сайт/почта могут быть недоступны даже при «ещё не наступившем» expiry. Причины бывают разные: проверки контактных данных, претензии, неоплаченные услуги, задержки в процессинге.
Быстрая диагностика: мини-runbook
- Сверьте дату окончания регистрации в панели регистратора и в WHOIS/RDAP (зафиксируйте, какой источник считаете «истиной»).
- Проверьте statuses: есть ли hold, pending*, serverUpdateProhibited и другие блокирующие флаги.
- Если видите server* — сразу планируйте эскалацию к регистратору: снятие может требовать времени и ручной обработки.
Для более широкой модели защиты портфеля доменов (роли, процедуры, контроль изменений) пригодится материал про защиту домена как актива.
Registry lock: когда обычного «domain lock» недостаточно
Многие знают про «лок» в панели регистратора (часто это clientTransferProhibited). Но registry lock — более жёсткая защита на уровне реестра: любые критичные изменения (NS, контакты, трансфер, иногда DNSSEC) требуют отдельного подтверждения по регламенту.
Зачем это нужно:
- защита от захвата домена при компрометации аккаунта у регистратора;
- защита от социального инжиниринга на стороне поддержки;
- снижение риска несанкционированной смены NS (а значит — угона трафика/почты).
Цена registry lock — операционная «вязкость»: любые плановые работы с доменом требуют времени. Закладывайте окно на подтверждения и учитывайте SLA поддержки.
Как использовать registry lock без боли
- Держите короткий чек-лист: как снять/вернуть lock, кто подтверждает, через какие каналы.
- Не планируйте миграции NS/регистратора «на флажке» перед expiry.
- Имейте резервный канал связи с поддержкой (не на домене, который может упасть).
Grace period и redemption period: что можно успеть после expiry
После даты окончания регистрации домен не всегда «умирает» мгновенно. Большинство зон имеют послесрочные окна, но их длительность и правила зависят от конкретного TLD и политики реестра.
Grace period
Grace period — период после expiry, когда домен часто ещё можно продлить относительно стандартно. При этом делегирование может быть уже ограничено: регистратор/реестр может поставить hold или подменить DNS на парковку.
- Сайт и почта могут «мигать»: часть резолверов держит старый кеш, часть — уже видит новые ответы.
- Если NS менялись перед expiry, кеши могут сыграть против вас.
- Тактика: сначала вернуть домен в нормальное состояние продлением, затем аккуратно менять NS/DNSSEC и прочие параметры.
Redemption period
Redemption period — «карантин», когда домен уже удалён из активного состояния, но ещё может быть восстановлен через процедуру restore. Это обычно дороже и требует больше времени, чем обычное продление. Часто домен в этот момент не делегируется.
- Высокий риск простоя сайта и почты.
- Восстановление может занимать дни, а не минуты.
- После выхода из redemption домен может уйти в pendingDelete, где стандартно «откатить назад» уже нельзя.
Если домен дошёл до redemption period, думайте не «как продлить», а «как восстановить сервис»: временный домен, статус-страница, альтернативные каналы связи, временная почта.
Чек-лист админа: как не доводить до аварии
1) Мониторинг домена как продакшен-ресурса
- Отслеживайте дату expiry и статусы автоматически.
- Оповещения отправляйте в независимые каналы: мессенджер, тикеты, резервная почта не на этом домене.
- Ставьте несколько порогов: 60/30/14/7/3 дня.
2) Планирование изменений вокруг даты продления
- Не делайте перенос регистратора, смену NS и включение DNSSEC «на флажке».
- Если нужен registry lock — заранее заложите время на снятие/возврат.
- Перед крупными миграциями уменьшайте TTL заранее и фиксируйте текущие значения.
3) Разделяйте доступы и ответственность
- Аккаунт у регистратора — под MFA, с ограниченным кругом админов.
- Контакты домена и контакты оповещений — актуальные и регулярно проверяемые.
- Документируйте «кто принимает решение», особенно для восстановления в redemption period.
Типовые сценарии и что делать
Сценарий A: auto renew включён, но домен не продлился
- Проверьте биллинг: прошла ли транзакция, не требуется ли подтверждение.
- Сверьте дату expiry в WHOIS/RDAP и в панели регистратора.
- Проверьте statuses на наличие hold и pending*.
- Если близко к expiry или уже grace period — продлевайте вручную и параллельно открывайте тикет в поддержку.
Сценарий B: домен продлён, но сайт/почта «не ожили»
Чаще всего виноваты кеши DNS и/или статус hold.
- Убедитесь, что делегирование восстановлено и нет serverHold/clientHold.
- Проверьте NS: совпадают ли с ожидаемыми.
- Проверьте DNSSEC (если включён): неверная DS-запись после изменений часто даёт SERVFAIL у валидирующих резолверов.
- Выждите TTL там, где это неизбежно, но параллельно проверяйте резолв из разных сетей/резолверов.
Если параллельно делали переезд и меняли TLS-политику, держите под рукой план отката и сверяйтесь с гайдом про миграцию домена с 301 и HSTS.
Сценарий C: домен уже в redemption period
- Сразу инициируйте восстановление (restore) у регистратора — это главный путь.
- Поднимите временную заглушку/лендинг на альтернативном домене и дайте пользователям канал связи.
- Если завязана почта — используйте заранее подготовленную резервную стратегию (в идеале она продумана до инцидента).
Итог: домен — это инфраструктура
Домены — это не «бухгалтерия раз в год», а инфраструктурный компонент уровня сертификатов и резервных копий. Настройте auto renew, но держите мониторинг и человеческий контроль. Разбирайтесь в statuses, потому что именно они объясняют «почему нельзя». Для критичных доменов рассмотрите registry lock. И главное — не допускайте перехода в redemption period: восстановление там почти всегда дороже, дольше и стрессовее, чем профилактика.
