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

Они связаны, но решаются отдельно. Сначала DNS, потом SSL — порядок важен. Разберём по шагам: сначала универсальная часть, применимая к любому хостингу, потом конкретный сценарий для платформ с авто-HTTPS.

Часть 1. DNS: как домен указывает на ваш сервер

Что происходит, когда пользователь набирает адрес сайта

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

  1. Браузер видит адрес yourdomain.com и спрашивает у DNS-серверов: «где это?»
  2. DNS-серверы возвращают IP-адрес или имя другого домена.
  3. Браузер идёт по этому адресу.
  4. Если адрес правильный — открывается ваш сайт.
  5. Если домен указывает не туда (или никуда) — пользователь не попадает на сайт.

Задача DNS-настройки — сделать так, чтобы шаг 2 возвращал правильный адрес.

Какие DNS-записи нужны

В DNS существует много типов записей, но для запуска сайта в большинстве случаев достаточно знать четыре.

A-запись. Связывает домен с IPv4-адресом. Самый частый случай: yourdomain.com → 203.0.113.42. Если хостинг даёт вам IP-адрес — нужна A-запись.

AAAA-запись. То же самое, но для IPv6. Если сервер поддерживает IPv6 — добавляйте, лишним не будет.

CNAME. Алиас одного домена на другой. Используется, когда платформа выдала вам не IP-адрес, а доменное имя — например, myapp.tatnet.ru. Тогда вы прописываете: www.yourdomain.com → myapp.tatnet.ru. CNAME нельзя использовать на корневой домен — для этого есть отдельные типы записей.

ALIAS / ANAME. Аналог CNAME, но работает на корневом домене. Поддерживается не всеми регистраторами и DNS-провайдерами — если у вашего такого типа записи нет, корневой домен подключается через A-запись на конкретный IP.

Дополнительно могут встретиться:

  • TXT — текстовые записи. Используются для верификации владения доменом (Let’s Encrypt при DNS-challenge), для SPF и DKIM в почте.
  • MX — записи для почтового сервера. К запуску сайта отношения не имеют, но часто оказываются на той же странице у регистратора, и их случайно трогают.

Где прописываются DNS-записи

Здесь часто возникает путаница. Записи могут жить в двух местах:

В панели регистратора домена. Reg.ru, Рег.ру, Namecheap, GoDaddy и подобные. Самый частый случай: вы купили домен, и записи редактируются в той же панели, где и оплата.

У отдельного DNS-провайдера. Если NS-записи домена делегированы куда-то ещё — например, на Cloudflare или Yandex DNS — записи нужно редактировать там, а не у регистратора. У регистратора в этом случае только NS-записи, и больше ничего.

Как понять, где у вас редактируются записи. Откройте dig NS yourdomain.com в терминале или сервис whois.com в браузере. Посмотрите на NS-серверы. Если они вида ns1.reg.ru — записи у регистратора. Если ns1.cloudflare.com — у Cloudflare. Идти нужно туда, куда указывают NS.

Пошаговая настройка DNS

Типичный сценарий: купили домен, есть IP-адрес сервера, нужно их связать.

  1. Узнайте, какой адрес дал вам хостинг или платформа. Это либо IPv4 (например, 203.0.113.42), либо доменное имя (myapp.tatnet.ru).
  2. Откройте панель регистратора или DNS-провайдера (см. предыдущий пункт).
  3. Найдите раздел DNS-записей. У разных провайдеров он называется по-разному: «Управление DNS», «DNS-записи», «Zone editor».
  4. Удалите старые записи, если они есть и указывают не туда. Это частая причина того, что после настройки сайт не открывается — старые записи остались и конфликтуют с новыми.
  5. Создайте A-запись для корневого домена. В поле «имя» обычно указывают @ или оставляют пустым (зависит от провайдера), в поле «значение» — IP-адрес.
  6. Создайте запись для www. Если хостинг даёт IP — это A-запись www → 203.0.113.42. Если хостинг даёт домен — это CNAME www → myapp.tatnet.ru.
  7. Сохраните и дождитесь propagation.

Если корневой домен нужно подключить к платформе, которая выдаёт CNAME-имя, а ALIAS/ANAME у регистратора нет — придётся либо использовать только www, либо перенести DNS на провайдера, который ALIAS поддерживает (Cloudflare, например), либо использовать редирект с корневого на www.

Как проверить, что DNS обновился

Не нужно гадать — есть быстрые способы проверки.

Через терминал. dig yourdomain.com — покажет, какой адрес видят DNS-серверы прямо сейчас. Если в ответе ваш IP — порядок. Если старый — кэш ещё не обновился. Если ничего — записи не настроены или не сохранились.

Через сервис. dnschecker.org показывает, какой адрес видят DNS-серверы в разных регионах мира. Полезно, чтобы убедиться, что обновление прошло везде, а не только у вашего провайдера.

Через браузер. Самый ненадёжный способ. Браузер кэширует DNS, и вы можете видеть старую версию ещё долго после фактического обновления. Если проверяете через браузер — открывайте инкогнито и желательно с другой сети (например, через мобильный интернет).

Подводные камни DNS

Propagation не мгновенная. Стандартный ответ — «от 5 минут до 48 часов». На практике обычно занимает 10–60 минут, но иногда задерживается. Это нормально, не повод паниковать и не повод считать, что что-то сломано.

TTL. Time To Live — сколько секунд DNS-серверы хранят запись в кэше. Если планируете в скором времени менять записи — заранее снизьте TTL до 300 секунд (5 минут). Тогда будущее переключение пройдёт быстрее.

Кэш браузера и локальной сети. Иногда сайт упорно открывает старую версию. Проверяйте через dig, а не через браузер.

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

Часть 2. SSL: чтобы сайт открывался по HTTPS

DNS настроен — домен указывает на сервер. Теперь нужно сделать так, чтобы он открывался по HTTPS, а не только по HTTP.

Зачем вообще HTTPS

Несколько причин, любой из которых хватит:

  • браузеры показывают предупреждение «Не защищено» для HTTP-сайтов, и пользователи уходят;
  • поисковики занижают HTTP-сайты в выдаче;
  • многие веб-API не работают по HTTP вообще — геолокация, push-уведомления, service workers, доступ к камере;
  • любые формы с вводом данных по HTTP — это утечка по дороге.

HTTPS сейчас не опциональная фича, а обязательный минимум.

Откуда берутся сертификаты

Let’s Encrypt. Бесплатные сертификаты, выдаются автоматически, действуют 90 дней, обновляются автоматически. Покрывают потребности подавляющего большинства проектов.

Платные сертификаты. Нужны в специфических случаях: EV-сертификаты (с зелёной полосой и названием организации в адресной строке) для финансовых организаций, wildcard-сертификаты на множество поддоменов в условиях, где нужна длительная валидность, корпоративные требования к конкретным CA.

Для типового веб-проекта берите Let’s Encrypt. Дальше речь именно о нём.

Как Let’s Encrypt проверяет, что домен ваш

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

Когда вы запрашиваете сертификат, Let’s Encrypt должен убедиться, что вы действительно владеете доменом. Способов проверки несколько.

HTTP-challenge. Самый частый. Let’s Encrypt просит положить файл с определённым содержимым по адресу http://yourdomain.com/.well-known/acme-challenge/... Вы (или certbot за вас) кладёте файл, Let’s Encrypt запрашивает его и проверяет содержимое. Если совпадает — выпускает сертификат. Это работает только если DNS уже указывает на ваш сервер — иначе Let’s Encrypt просто не дойдёт до файла.

DNS-challenge. Let’s Encrypt просит создать TXT-запись с определённым значением. Удобно, когда сервер ещё не запущен, или для wildcard-сертификатов (которые HTTP-challenge выпустить не позволяет).

TLS-ALPN. Технический способ через расширение TLS, обычно автоматизируется и явно настраивать его не нужно.

В типичной ситуации работает HTTP-challenge, и для него обязательно условие: DNS уже указывает на ваш сервер.

Базовая настройка SSL на VPS через certbot

Если вы делаете всё вручную на собственном сервере, схема такая:

  1. Установите certbot. На Ubuntu это sudo apt install certbot python3-certbot-nginx.
  2. Запустите выпуск: sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com. Certbot сам пройдёт HTTP-challenge, выпустит сертификат и пропишет пути в конфиге nginx.
  3. Если используете не nginx, а что-то другое — certbot certonly --standalone -d yourdomain.com выпустит сертификат без правок конфига, и вы пропишете пути сами.
  4. Сертификаты появятся в /etc/letsencrypt/live/yourdomain.com/. Внутри — fullchain.pem (полная цепочка) и privkey.pem (приватный ключ). Их и нужно прописать в конфиге веб-сервера.
  5. Настройте автообновление. На современных Ubuntu certbot ставит systemd-таймер автоматически — проверьте через systemctl list-timers | grep certbot. Если таймера нет, добавьте задачу в cron.
  6. Настройте перезапуск веб-сервера после обновления. В /etc/letsencrypt/renewal/yourdomain.com.conf пропишите renew_hook = systemctl reload nginx (или ваш веб-сервер). Без этого новый сертификат лежит на диске, но веб-сервер продолжает отдавать старый.

Подводные камни SSL

Rate limit Let’s Encrypt. На регистрационный домен — 50 успешных выпусков в неделю. Если вы тестируете и часто перевыпускаете — можете упереться и не сможете выпустить сертификат несколько часов или дней. Для тестов есть staging-окружение Let’s Encrypt — оно с теми же правилами, но без rate limit.

DNS должен быть настроен до выпуска. Если HTTP-challenge не проходит — обычно из-за того, что DNS ещё не обновился. Дождитесь propagation и попробуйте снова.

Автообновление работает, но веб-сервер не рестартует. Самая частая причина «упал HTTPS» — сертификат обновился, а nginx это не заметил. Проверьте renew_hook и убедитесь, что после certbot renew --dry-run в логах nginx есть reload.

Сертификат на корневой домен ≠ сертификат на www. Если вы выпустили сертификат только на yourdomain.com, попытка открыть www.yourdomain.com покажет ошибку. Либо включайте оба имени в один сертификат (-d yourdomain.com -d www.yourdomain.com), либо настраивайте редирект с одного на другое.

Wildcard требует DNS-challenge. Если нужен сертификат на *.yourdomain.com, HTTP-challenge не подойдёт — только DNS-challenge.

Как проверить, что SSL работает

Открыть сайт по HTTPS в инкогнито. Замок в адресной строке — значит, сертификат принят. Предупреждение — значит, что-то не так.

Через openssl. openssl s_client -connect yourdomain.com:443 -servername yourdomain.com покажет цепочку сертификатов и срок действия.

Через ssllabs.com/ssltest. Глубокая проверка конфигурации: версии TLS, шифры, цепочка сертификатов, типичные уязвимости. Полезно для проверки качества настройки, а не только факта работы HTTPS.

Как это работает в TatNet

Вся последовательность из двух частей выше сводится к двум действиям, если деплой идёт через TatNet.

Шаг 1. Подключить домен в кабинете. Открываете проект, добавляете свой домен. Платформа показывает, какие DNS-записи нужно создать у регистратора — обычно это CNAME для поддомена или A-запись для корневого, в зависимости от типа ресурса.

Шаг 2. Прописать эти записи у регистратора. Это единственное действие, которое остаётся на стороне разработчика — потому что доменом владеете вы, а не платформа, и доступ к панели регистратора есть только у вас.

Дальше платформа всё делает сама:

  • проверяет, что DNS-записи появились и указывают куда нужно;
  • запрашивает сертификат у Let’s Encrypt;
  • проходит challenge без вашего участия;
  • обновляет сертификат до истечения срока;
  • подсовывает обновлённый сертификат веб-серверу — без ручных рестартов;
  • показывает понятную ошибку в кабинете, если что-то пошло не так, а не молчит до момента, когда сайт упал.

Никаких certbot, renew_hook и cron-задач — это работа платформы.

Подключить домен в TatNet →

Что нужно помнить

Короткий чек-лист по итогам.

  • DNS-записи живут у регистратора домена или у DNS-провайдера, на которого делегированы NS. Это разные места.
  • Базовый минимум для сайта — A-запись для корневого домена и A-запись или CNAME для www.
  • DNS должен быть настроен до выпуска SSL-сертификата.
  • Propagation занимает время. Это нормально.
  • Для большинства проектов хватит Let’s Encrypt — бесплатно, с автообновлением.
  • На VPS автообновление работает, но обязательно проверьте, что веб-сервер перезапускается с новым сертификатом.
  • На платформе с авто-HTTPS оба шага сводятся к настройке записей у регистратора. Сертификат — забота платформы.

Подключить домен в TatNet →