Как настроить домен: привязка к хостингу, DNS и почта

Коротко. Настройка домена — это четыре независимых шага. Первый: делегировать домен, то есть прописать у регистратора NS-серверы того, кто будет держать DNS-зону. Второй: добавить в зону A-запись на IP сайта или CNAME на чужое имя. Третий: описать домен на сервере — виртуальный хост и сертификат. Четвёртый: поднять почту записями MX и SPF. Каждый шаг проверяется отдельно.

Сразу разведём две темы, которые часто путают. Если вы искали «контроллер домена» или «доменную сеть» — это Active Directory, служба каталогов Windows внутри локальной сети предприятия. К доменным именам в интернете она отношения не имеет. Эта статья про публичные домены вида example.com: про DNS, привязку к хостингу и почту.

Что происходит после покупки домена

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

Слои независимы и ломаются по отдельности — это главное, что стоит понять до того, как открывать панель управления:

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

Порядок именно такой. Пока домен не делегирован, любые A-записи и MX бесполезны: их просто никто не спросит.

Как настроить доменное имя: делегирование и NS-серверы

Делегирование — это ответ на вопрос «кто вообще уполномочен отвечать про этот домен». В панели регистратора вы указываете два и более сервера имён (NS), а регистратор передаёт их в реестр зоны верхнего уровня. С этого момента любой резолвер в мире, спросив про ваш домен корневые серверы, получит направление на них.

Откуда взять адреса NS-серверов: их выдаёт тот, кто будет держать зону. Обычно это хостинг, где лежит сайт, но не обязательно — зону можно держать у регистратора, у хостинга, у отдельного DNS-провайдера или на своём сервере. Выглядят они как имена вида ns1.provider.example и ns2.provider.example.

Чем NS отличается от A-записи

Это самая частая путаница у новичков, и она стоит нескольких дней простоя. Разница простая:

• NS отвечает на вопрос «кто хранит записи домена». Живёт в родительской зоне (в реестре) и дублируется внутри самой зоны.
• A отвечает на вопрос «какой IP-адрес у этого имени». Живёт внутри зоны — на тех серверах, которые названы в NS.

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

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

Glue-записи: когда NS находятся внутри своего же домена

Отдельный случай — когда серверы имён домена называются его же поддоменами: ns1.example.com для домена example.com. Получается замкнутый круг: чтобы узнать адрес ns1.example.com, надо спросить ns1.example.com. Разрывается он glue-записями — адресами серверов имён, которые регистратор кладёт прямо в родительскую зону. Регистрируются они у регистратора отдельным пунктом («частные серверы имён», «регистрация NS»). Если вы используете чужие NS в чужом домене, glue вам не нужен.

Как проверить делегирование

# какие NS реально отдаёт родительская зона
dig +trace example.com | tail -n 20

# короткий ответ: серверы имён домена
dig +short NS example.com

# что о делегировании думает реестр и регистратор
whois example.com

# спросить публичный резолвер напрямую
dig NS example.com @1.1.1.1 +short

Если dig +short NS молчит или показывает старые серверы — делегирование ещё не применилось либо не сохранилось. Кому делегирован домен и когда он истекает, удобно смотреть через WHOIS-проверку: там же видны срок регистрации и статусы блокировки.

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

Как настроить домен на сайте: A-запись, CNAME, www и без www

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

Тип	Что задаёт	Пример значения	Ограничения и подводные камни
NS	Серверы имён, отвечающие за зону	ns1.provider.example	Правится у регистратора; TTL в родительской зоне задаёт реестр, а не вы
A	IPv4-адрес имени	203.0.113.10	Только адрес, без порта и без пути
AAAA	IPv6-адрес имени	2001:db8::10	Добавляйте, только если сервер реально слушает IPv6
CNAME	Псевдоним: имя ссылается на другое имя	example.com.	Не может соседствовать с другими записями на том же имени, поэтому не ставится на корень домена
MX	Куда доставлять почту домена	10 mx1.mailhost.example.	Значение — имя хоста, не IP; на CNAME указывать нельзя
TXT	Произвольный текст: SPF, DKIM, DMARC, подтверждения владения	v=spf1 include:_spf.mailhost.example -all	SPF-запись на домене должна быть одна
CAA	Какие удостоверяющие центры вправе выпускать сертификат	0 issue "letsencrypt.org"	Ошибка в значении заблокирует выпуск сертификата

A-запись или CNAME

Выбор зависит от того, что вам дал хостинг. Если дали IP-адрес — ставьте A-запись. Если дали имя вида site-123.platform.example — ставьте CNAME. Смешивать не надо: CNAME на имя, у которого адрес меняется, как раз и нужен для того, чтобы не переписывать A-запись при каждой смене адреса на стороне платформы.

CNAME нельзя поставить на корень домена (на «голый» example.com). Стандарт запрещает соседство CNAME с любыми другими записями на том же имени, а на корне обязательно есть NS и SOA. Некоторые DNS-провайдеры предлагают нестандартные обходы под названиями ALIAS, ANAME или «CNAME flattening» — они решают задачу на своей стороне, но при переезде к другому провайдеру такую запись придётся переделывать. См. RFC 1034 и RFC 2181.

www и без www: выберите один вариант

Технически example.com и www.example.com — два разных имени, и оба должны разрешаться. Но открываться у пользователя должен один: второй отдаёт постоянный редирект. Какой выбрать основным — вопрос вкуса; важно, чтобы выбор был один и не менялся.

# вариант «основной — без www»
example.com.        3600  IN  A      203.0.113.10
example.com.        3600  IN  AAAA   2001:db8::10
www.example.com.    3600  IN  CNAME  example.com.

# вариант «основной — www», когда корень отдаёт платформа
example.com.        3600  IN  A      203.0.113.10
www.example.com.    3600  IN  A      203.0.113.10

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

Как настроить домен на сервере и на конкретный IP

Указать домен на IP — это и есть A-запись из предыдущего раздела. Но одной записи мало: сервер по этому адресу должен понимать, что домен относится к нему. Иначе вы попадёте на сайт по умолчанию — чужой или пустой.

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

nginx

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    root /var/www/example.com/public;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

После правки — проверка синтаксиса и перезагрузка без обрыва соединений: nginx -t && nginx -s reload. Правила подбора виртуального хоста описаны в документации nginx.

Apache

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Проверка конфигурации — apachectl configtest, применение — apachectl graceful.

Сертификат выпускается после DNS, а не до

Автоматический выпуск сертификата по HTTP-проверке требует, чтобы домен уже вёл на этот сервер: удостоверяющий центр сам сходит по имени и должен попасть именно к вам. Поэтому порядок такой: сначала A-запись и виртуальный хост на 80-м порту, потом выпуск сертификата, потом включение HTTPS и редиректа. Если вы добавили запись CAA, убедитесь, что нужный центр в ней разрешён — иначе выпуск отклонят.

Не переносите сайт «в один клик»: домен, DNS и сервер переключаются в разные моменты. Пока новый сервер не отдаёт корректный ответ по имени домена — не меняйте A-запись. Проверить сервер до переключения DNS можно, подставив заголовок вручную: curl -sI -H 'Host: example.com' http://203.0.113.10/

Как настроить доменную почту: MX, SPF и подписи

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

Минимум состоит из четырёх частей:

• MX — куда доставлять входящие письма. Значение — имя хоста и число-приоритет: чем число меньше, тем выше приоритет.
• SPF — TXT-запись на корне домена, перечисляющая, кому разрешено отправлять письма от вашего имени.
• DKIM — TXT-запись с публичным ключом на имени вида селектор._domainkey.example.com. Ключ и селектор выдаёт почтовый сервис.
• DMARC — TXT-запись на _dmarc.example.com, задающая политику для писем, не прошедших проверку, и адрес для отчётов.

example.com.                   3600 IN MX  10 mx1.mailhost.example.
example.com.                   3600 IN MX  20 mx2.mailhost.example.
example.com.                   3600 IN TXT "v=spf1 include:_spf.mailhost.example -all"
sel1._domainkey.example.com.   3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.            3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Две ошибки, которые ломают доставку тише всего. Первая: несколько SPF-записей на одном домене — по RFC 7208 это ошибка обработки, и проверка не проходит вообще; всё нужно объединять в одну строку. Вторая: MX, указывающий на CNAME, — RFC 2181 требует, чтобы значение MX было именем с адресной записью.

Если домен вообще не предназначен для почты, честнее объявить это явно «нулевой» записью MX по RFC 7505: example.com. IN MX 0 . Тогда отправители сразу увидят, что писать сюда некуда, и не будут копить очередь.

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

Сколько ждать применения настроек и почему

Точного срока не существует, и любой, кто называет его в часах, угадывает. Скорость определяется не «обновлением интернета», а тремя вещами: TTL старых записей, поведением конкретных резолверов и кэшами на вашей стороне.

TTL — это число секунд, которое резолверу разрешено хранить ответ. Пока оно не истекло, резолвер отвечает из кэша и на ваши изменения не смотрит. Поэтому TTL надо снижать заранее — за срок, превышающий текущее значение TTL, а не в момент переезда.

# посмотреть текущий TTL записи (второе поле ответа)
dig +noall +answer example.com A

# TTL делегирующих NS в родительской зоне обычно заметно больше.
# Сервер родительской зоны СВОЙ у каждого TLD: для .com и .net это
# a.gtld-servers.net, для .ru и .рф — a.dns.ripn.net. Спросив не тот
# сервер, вы получите список корневых серверов, а не NS своего домена.
dig +noall +authority example.com NS @a.gtld-servers.net
dig +noall +authority example.ru NS @a.dns.ripn.net

# спросить авторитативный сервер напрямую — там кэша нет,
# и виден результат сразу после сохранения зоны
dig A example.com @ns1.provider.example +short

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

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

Отдельная категория задержек — кэш, до которого DNS-провайдер не дотягивается: резолвер интернет-провайдера, кэш операционной системы, кэш браузера. Отрицательные ответы тоже кэшируются: если вы успели зайти на домен до того, как он заработал, ответ «такого имени нет» осядет в кэше на время, заданное параметром в SOA-записи зоны (RFC 2308). Поэтому «у меня не открывается, а у коллеги открывается» — нормальная промежуточная картина, а не признак ошибки.

# сбросить кэш DNS на своей машине
resolvectl flush-caches          # Linux с systemd-resolved
sudo dscacheutil -flushcache     # macOS
ipconfig /flushdns               # Windows

# проверить, что видит именно ваша система, а не браузер
getent hosts example.com

Как правильно настроить домен: типовые ошибки

Сайт не открылся вообще

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

«Висит» старый сайт

Почти всегда это кэш, а не ошибка в записях. Проверьте по порядку: что отдаёт авторитативный сервер (там правда видна сразу), что отдаёт публичный резолвер, что видит ваша операционная система. Если авторитативный сервер отдаёт новый адрес, а вы видите старый — ждите истечения TTL и чистите локальный кэш. Если новый адрес видят все, но контент старый — дело уже не в DNS, а в кэше самого сайта или CDN.

Второй сценарий: адрес новый, но открывается чужой сайт. Значит, запрос дошёл до сервера, а виртуального хоста под ваш домен там нет — вернитесь к разделу про server_name и ServerName.

Почта не приходит

Проверьте, что MX вообще опубликованы и ведут на имена, у которых есть адресные записи. Затем — что почтовые ящики созданы на стороне сервиса: DNS может быть настроен идеально, но если ящик не заведён, сервер получателя откажет. Дальше — SPF: одна запись, без опечаток в механизме include, с осмысленным финальным правилом. Если письма уходят, но попадают в спам, ищите не в MX, а в DKIM и DMARC: подпись должна быть опубликована под тем селектором, который реально использует отправляющий сервер.

Мелочи, которые стоят часов

• Точка в конце значения. В классическом формате зоны example.com. с точкой — полное имя, а example.com без точки — относительное, к которому припишется имя зоны. В веб-панелях правила свои, поэтому сверяйте результат запросом, а не глазами.
• Лишние пробелы и переносы в длинных TXT-записях DKIM.
• Запись на @ и на пустое поле имени — в разных панелях это обозначается по-разному, а ошибка даёт запись на имени @.example.com.
• Забытая AAAA-запись, ведущая на старый сервер: браузеры с IPv6 пойдут по ней и увидят старый сайт, а вы с IPv4 — новый.

Как проверить, что домен настроен

Проверять нужно каждый слой отдельно и желательно снаружи — со своей машины вы видите ответ своего резолвера, а не картину целиком.

• WHOIS — кому принадлежит домен, до какой даты оплачен, какие NS указаны в реестре и нет ли статусов, снимающих делегирование.
• Проверка DNS-записей — что реально опубликовано в зоне: A, AAAA, CNAME, MX, TXT, NS и их TTL.
• Проверка распространения DNS — что видят резолверы в разных точках. Именно этот отчёт отвечает на вопрос «уже применилось или ещё нет».
• Проверка почтовых записей — MX, SPF, DKIM и DMARC вместе, с указанием противоречий между ними.
• Проверка SSL-сертификата — выпущен ли сертификат на оба имени, с www и без, и не истекает ли он.
• Проверка HTTP-заголовков — какой ответ сервер отдаёт по имени домена и куда ведут редиректы.

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

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

Чем настройка домена отличается от настройки контроллера домена?

Это разные технологии с похожим словом. Контроллер домена и доменная сеть — про Active Directory: службу каталогов, которая управляет учётными записями и правами внутри локальной сети организации. Настройка доменного имени — про DNS и публичный интернет. Общего у них только термин «домен».

Можно ли держать домен у одного провайдера, сайт у второго, а почту у третьего?

Да, это нормальная и распространённая конфигурация. Домен зарегистрирован у регистратора, зона делегирована туда, где вам удобнее ей управлять, A-запись ведёт на сервер сайта, MX — на почтовый сервис. Все три части связаны только записями в одной зоне и меняются независимо.

Обязательно ли настраивать www, если сайт работает без него?

Технически нет, но лучше настроить. Часть пользователей и почтовых клиентов подставляет www автоматически, и без записи они увидят ошибку разрешения имени. Правильный вариант — завести запись на www и настроить постоянный редирект на основной вариант.

Почему домен открывается у меня, но не открывается у клиента?

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

Что делать, если домен куплен, а панели управления зоной нет?

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

Как перенести домен к другому регистратору, не уронив сайт?

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

Чеклист настройки домена

• Домен зарегистрирован, данные владельца подтверждены, срок оплаты известен.
• NS-серверы указаны у регистратора и совпадают с тем, что реально отдаёт родительская зона.
• Записи правятся именно на тех серверах, куда домен делегирован.
• A-запись (и AAAA, если IPv6 нужен) ведёт на актуальный адрес сервера.
• Имя с www разрешается, и один из вариантов постоянным редиректом ведёт на другой.
• На веб-сервере есть виртуальный хост с обоими именами домена.
• Сертификат выпущен на оба имени, HTTPS включён, редирект с http настроен.
• Запись CAA, если она есть, разрешает нужный удостоверяющий центр.
• MX ведут на имена с адресными записями, а не на CNAME и не на IP.
• SPF-запись одна, DKIM опубликован под рабочим селектором, DMARC задан.
• Старые записи от прежнего хостинга удалены — особенно AAAA и лишние A.
• TTL возвращён к обычному значению после переезда.
• Домен, сертификат и доступность поставлены на мониторинг.