Реестр доменов и сертификатов: кто платит, когда истекает, кому придёт письмо

MAATRIX

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

Как это обычно происходит: анатомия типичного отказа

Проблема почти никогда не в технике. Let's Encrypt и коммерческие CA умеют напоминать о сертификатах, регистраторы шлют письма о доменах за 30-60 дней — уведомления действительно уходят. Отказ происходит на организационном уровне, и сценариев на практике немного, но они повторяются из компании в компанию:

• Уведомление уходит на личную почту сотрудника, который регистрировал домен «на скорую руку» три года назад и давно сменил работу. Почта либо не проверяется, либо вовсе удалена.
• Карта, привязанная к автосписанию, истекла или перевыпущена — банк молча меняет номер, а у регистратора остаются старые реквизиты. Автоплатёж не проходит, и об этом узнают из письма «не удалось списать», которое опять же уходит не туда.
• Ответственного за домен никто не назначал явно — он «достался» тому, кто первым его настроил, и нигде не зафиксирован. Когда человек уходит, домен просто перестаёт кому-либо принадлежать.
• Домен третьестепенный, под лендинг старой акции или тестовый стенд, но на нём всё ещё висит редирект или API, о котором все забыли, кроме одного скрипта в проде.

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

Отдельно стоит развеять иллюзию: «у нас настроено автопродление» не означает, что домен или сертификат гарантированно продлятся. Автопродление — это попытка списать деньги с конкретной карты в конкретный момент, и она может не сработать по десятку причин, не связанных с инфраструктурой. Реестр не заменяет автопродление — он служит второй, независимой линией защиты, которая заметит сбой автоматики до того, как сайт ляжет.

Что обязательно должно быть в реестре: поля

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

Минимальный набор колонок:

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

«Куда приходит уведомление» должно быть групповым адресом, а не личной почтой сотрудника — domains@company.ru, на который у нескольких человек есть доступ, а не ivan.petrov@gmail.com. Личная почта уходит вместе с человеком, групповой алиас — нет. Настроить такой алиас один раз намного дешевле, чем потом восстанавливать доступ к домену, зарегистрированному на давно нерабочий email.

«Ответственный» — это роль, а не имя. «Иван отвечает за домены» работает ровно до дня, когда Иван увольняется, уходит в длинный отпуск или меняет отдел. «Дежурный DevOps-инженер» — работает всегда, потому что должность передаётся, а конкретный человек в ней меняется. Если ответственный всё же назначается по имени (так часто удобнее для реальной работы), держите рядом резервный контакт и обновляйте запись при любой кадровой смене, а не раз в год при случайной ревизии.

Где вести реестр: от таблицы до полноценного инструмента

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

• Google Таблица или Excel с общим доступом — минимальный порог входа, подходит для 5-30 доменов. Можно сразу поставить условное форматирование, которое подсвечивает красным строки с датой истечения ближе 30 дней — наглядный сигнал при каждом открытии файла.
• Notion / Airtable с базой данных — удобнее при росте числа записей, позволяет фильтровать по критичности и ответственному, строить представления «что истекает в этом квартале», есть встроенные напоминания по дате.
• Файл в git-репозитории инфраструктуры (domains.yaml или domains.csv) — подходит командам, которые и так держат конфигурацию как код. Плюс — история изменений через git log. Минус — неудобно смотреть без специальных инструментов человеку не из DevOps, например бухгалтеру, отвечающему за оплату.
• Специализированный инструмент учёта доменного портфеля (DNS-провайдеры вроде Cloudflare Registrar или коммерческие сервисы вроде DomainTools) — оправдано при сотнях доменов, когда ручной реестр не поспевает за изменениями. Для большинства компаний это избыточно.

Практический совет: не гонитесь за идеальным инструментом до того, как заведёте хотя бы простую таблицу. Реестр в Google Sheets, который реально ведётся, полезнее идеально спроектированной базы данных, которую никто не заполнил. Начните с CSV или таблицы, а инструмент меняйте, когда конкретно упрётесь в его ограничения — не раньше.

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

Единая точка ответственности: почему «домен ведёт тот, кто его завёл» не работает

Самая частая организационная ошибка — не отсутствие реестра, а отсутствие единого владельца процесса поверх него. Даже идеально заполненная таблица не спасает, если каждый домен фактически «принадлежит» тому, кто его когда-то настроил, и никто не смотрит на реестр целиком.

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

Без единой точки ответственности реестр быстро расползается: часть доменов регистрируется через личный кабинет одного сотрудника, часть — через другого, оплата размазана по нескольким картам «так исторически сложилось», а сверки не происходит, потому что формально это «не моя зона ответственности, у нас же есть таблица». Таблица без владельца деградирует за несколько месяцев — устаревают контакты, забывают вносить новые домены, никто не замечает пустое поле «ответственный».

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

Напоминания заранее: как не превратить это в ручную ежемесячную проверку

Главная ошибка при построении процесса — решить, что «раз в месяц кто-то откроет таблицу и посмотрит на даты». Это работает первые два-три месяца, а дальше человеческая память подводит именно с редкими, некритичными на первый взгляд задачами.

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

• 60 дней — информационное напоминание, без необходимости действовать: домен X истекает через 2 месяца, автопродление настроено на карту Y.
• 30 дней — контрольная точка: убедиться, что карта актуальна, автопродление реально включено, уведомление приходит на живой адрес.
• 14 дней — эскалация ответственному напрямую, не просто в общий канал, если предыдущие пороги не подтвердили, что всё в порядке.
• 7 дней и меньше — нештатная ситуация, а не плановая проверка: нужно ручное вмешательство прямо сейчас.

Технически это легко снять со скрипта, который читает сам реестр, а не лезет каждый раз в whois или к каждому CA отдельно — реестр уже содержит дату истечения, и достаточно сравнивать её с текущей датой:

#!/bin/bash
# check-registry-expiry.sh — читает CSV-реестр и шлёт алерты по порогам
REGISTRY="domains.csv"  # domain,type,expiry,owner_role,notify_email
THRESHOLDS=(60 30 14 7)

TODAY_EPOCH=$(date +%s)

tail -n +2 "$REGISTRY" | while IFS=, read -r DOMAIN TYPE EXPIRY OWNER NOTIFY; do
  EXP_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null)
  [ -z "$EXP_EPOCH" ] && continue

  DAYS_LEFT=$(( (EXP_EPOCH - TODAY_EPOCH) / 86400 ))

  for T in "${THRESHOLDS[@]}"; do
    if [ "$DAYS_LEFT" -eq "$T" ]; then
      MSG="⚠️ $DOMAIN ($TYPE) истекает через $DAYS_LEFT дней. Ответственный: $OWNER"
      curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
        -d chat_id="${TG_CHAT_ID}" -d text="$MSG"
    fi
  done
done

Такой скрипт запускается раз в сутки через cron и сверяется с реестром, а не с реальным состоянием сертификата или домена — это осознанное разделение задач. Отдельно от него имеет смысл держать независимую техническую проверку: реально ли сертификат ещё действителен прямо сейчас и отвечает ли whois тем же сроком, что записан в таблице. Такая проверка ловит расхождение — например, если кто-то продлил домен, но забыл обновить дату в реестре, или наоборот, реестр говорит «всё хорошо», а автопродление не прошло. Подробный разбор независимой проверки сертификата через openssl и домена через whois есть в статье мониторинг сертификатов и доменов — реестр и техническая проверка дополняют друг друга, а не заменяют одна другую.

Для самих уведомлений в Telegram, если бот ещё не настроен, шаги описаны в статье как установить и настроить алерты в Telegram на VPS — тот же бот и канал можно переиспользовать и для алертов по реестру.

Что делать при увольнении сотрудника, смене карты и передаче ответственности

Реестр без процедуры на случай изменений так же уязвим, как и его отсутствие — деградация просто происходит медленнее и незаметнее. Три события должны триггерить обязательное обновление записей, а не «когда-нибудь потом».

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

Смена или истечение карты, привязанной к автопродлению. Банки обычно уведомляют держателя карты о перевыпуске, но не уведомляют регистратора или CA — эту связь должен восстановить кто-то вручную. Если карта корпоративная, закрепите за одним человеком (обычно из финансового отдела) обязанность сверять список сервисов с автосписанием при каждом перевыпуске — иначе разрыв обнаружится только письмом «не удалось списать оплату», которое снова может уйти не туда. Если с оплатой зарубежных сервисов у вас и так случаются сложности, см. статью карта не проходит за зарубежный сервис: что делать — это тот же класс проблем, что регулярно ломает автопродление у зарубежных регистраторов и CA.

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

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