Каждый раз, когда вы вводите адрес сайта в браузер, за кулисами разворачивается цепочка запросов длиной в несколько миллисекунд. DNS — это инфраструктура, которая делает её возможной. Без неё интернет состоял бы из одних IP-адресов, которые никто не стал бы запоминать. Ниже — как устроена эта система и какие типы записей нужно знать при привязке домена к хостингу.
Что такое DNS и зачем он нужен
Компьютеры в сети общаются через IP-адреса — числовые идентификаторы вроде 185.199.108.153. Людям такие адреса неудобны: их сложно запоминать, они меняются при смене хостинга. DNS (Domain Name System) решает эту проблему: хранит таблицу соответствия между именами доменов и IP-адресами и переводит одно в другое по запросу.
Аналогия рабочая, хотя и немного затёртая: DNS — это телефонная книга интернета. Вы набираете имя, система возвращает номер. Разница в том, что DNS-книга распределена между тысячами серверов по всему миру и обновляется постоянно.
Когда вы выбираете хостинг для сайта и привязываете к нему домен, вы работаете именно с DNS — редактируете записи в зоне домена, меняете NS-серверы у регистратора. Типы записей проще, чем кажется.
Как происходит резолвинг: от браузера до сервера

Процесс перевода доменного имени в IP называется резолвингом. Он занимает от нескольких миллисекунд до нескольких секунд — в зависимости от кеша и удалённости серверов.
- Браузер проверяет локальный кеш — не запрашивали ли этот домен недавно.
- Если нет — обращается к рекурсивному резолверу (как правило, сервер провайдера или публичный, например
8.8.8.8от Google). - Резолвер спрашивает корневой DNS-сервер (их 13 кластеров, от
a.root-servers.netдоm.root-servers.net), где найти NS для нужной зоны. - Корневой сервер отвечает адресом TLD-сервера — того, кто отвечает за зону
.ru,.comили любую другую. - TLD-сервер возвращает адрес авторитетного NS-сервера конкретного домена.
- Резолвер запрашивает авторитетный NS и получает финальный IP-адрес.
- Ответ кешируется, и браузер устанавливает соединение с нужным сервером.
Кто за что отвечает — резолвер, NS, TLD
Рекурсивный резолвер — посредник, который берёт на себя всю работу по обходу серверов. Провайдерский резолвер чаще всего кешируется агрессивно, поэтому изменения DNS иногда «не видны» у части пользователей ещё сутки после обновления.
Корневые серверы знают только, где находятся TLD-серверы. Они не хранят адреса конкретных сайтов. Всего корневых кластеров 13, но физических узлов — больше тысячи, они распределены по anycast-сети.
Авторитетный NS-сервер — тот, кто реально хранит DNS-зону вашего домена. Обычно это NS-серверы вашего хостера (ns1.timeweb.ru) или стороннего DNS-хостинга (Cloudflare, Яндекс DNS).
TTL — время жизни записи
TTL (Time to Live) — число секунд, которое резолверы и браузеры вправе кешировать запись. Значение 3600 означает: можно кешировать час. Значение 86400 — сутки.
Практическое правило: если планируете переносить сайт на другой хостинг или менять IP-адрес, снизьте TTL до 300 за сутки до переноса. Тогда после смены записей новый адрес разойдётся по всему интернету за 5–10 минут, а не за 24 часа. После переноса TTL можно вернуть к стандартному значению.
Типы DNS-записей: сравнительная таблица
DNS-зона может содержать записи разных типов — каждый тип решает свою задачу. Вот основные из них.
| Тип | Для чего | Пример значения | Типичное TTL |
|---|---|---|---|
| A | Привязка домена к IPv4 | 185.199.108.153 |
3600 |
| AAAA | Привязка к IPv6 | 2606:4700::6812:1 |
3600 |
| CNAME | Псевдоним для другого имени | mysite.netlify.app |
300 |
| MX | Почтовый сервер | mail.example.com (priority 10) |
3600 |
| TXT | Произвольный текст (SPF, DKIM, верификация) | v=spf1 include:_spf.google.com ~all |
3600 |
| NS | Делегирование зоны | ns1.timeweb.ru |
86400 |
| PTR | Обратная запись (IP → имя) | server1.example.com |
86400 |
| SRV | Сервис-записи (SIP, Jabber) | _sip._tcp.example.com |
3600 |
Запись A — базовая привязка домена
Запись A связывает доменное имя с IPv4-адресом. Это самая фундаментальная запись: именно она говорит браузеру, на какой сервер слать запросы.
В панели хостинга добавляют две A-записи:
@→ IP-адрес сервера (корневой домен,example.com)www→ IP-адрес сервера (поддоменwww.example.com)
Символ @ обозначает корневой домен. Если добавить только запись для @, сайт не откроется по адресу с www — и наоборот. Добавляйте обе, если хотите обрабатывать оба варианта. Перед этим полезно разобраться, как настроить VPS с нуля, чтобы понимать, куда именно указываете.
CNAME — псевдоним, а не адрес
CNAME (Canonical Name) не указывает на IP — он указывает на другое доменное имя. Это удобно, когда нужно привязать поддомен к внешнему сервису: CDN, почтовому провайдеру, конструктору сайтов.
Пример: если вы подключаете Mailchimp для рассылок, сервис попросит создать запись CNAME k2._domainkey → dkim.mcsv.net. Знать IP-адрес их сервера не нужно.
Важное ограничение: CNAME нельзя ставить на корневой домен (@). Корень обязан иметь A-запись, а не псевдоним — иначе сломаются NS и MX. Cloudflare обходит это через механизм CNAME Flattening: он прозрачно разворачивает CNAME в A-запись на уровне своего резолвера, но это особенность конкретного DNS-хостинга.
MX — почта на своём домене
MX-запись указывает, на какой сервер доставлять письма для домена. Без неё почта просто не будет доходить.
Настройка зависит от почтового провайдера:
- Google Workspace:
ASPMX.L.GOOGLE.COMс приоритетом 1 - Яндекс 360:
mx.yandex.netс приоритетом 10 - Mail.ru для бизнеса:
emx.mail.ruс приоритетом 10
Чем меньше число приоритета, тем выше приоритет сервера. Приоритет 0 — самый высокий. Если у домена несколько MX-записей с разными приоритетами, почтовые серверы попробуют сначала тот, у которого число меньше. Это резервирование: если основной сервер недоступен, почта уйдёт на запасной.
Важно: MX должен указывать на имя хоста, а не на IP-адрес. Запись MX 10 185.10.0.5 — ошибка. Правильно: MX 10 mail.example.com, а уже mail.example.com резолвится через A-запись.
TXT — верификация и защита от спама
TXT-записи хранят произвольный текст — как правило, инструкции для других серверов. Три главных применения: SPF, DKIM и DMARC.
SPF (Sender Policy Framework) говорит почтовым серверам, с каких IP-адресов разрешено отправлять почту от имени домена. Пример записи для Google Workspace:
v=spf1 +a +mx include:_spf.google.com ~all
~all означает «мягкий» режим: письма с других адресов принять, но пометить как потенциально подозрительные. -all — жёсткий: отклонять.
DKIM — криптографическая подпись: письма подписываются ключом, публичная часть которого хранится в TXT-записи вида selector._domainkey.example.com. Получатель проверяет подпись и убеждается, что письмо не подменено в пути.
DMARC объединяет SPF и DKIM: говорит почтовым серверам, что делать, если проверки не прошли — отклонять письма, отправлять в спам или только уведомлять владельца домена.
TXT-записи также используются для верификации домена в Google Search Console, Яндекс.Вебмастере и других сервисах — в таких случаях сервис даёт уникальную строку, которую нужно добавить в зону.
NS-записи и делегирование домена

NS-записи указывают, какие серверы хранят DNS-зону домена. Это и есть делегирование: регистратор говорит всему интернету «за этот домен отвечает вот этот сервер».
NS-записи меняют не у хостера, а у регистратора домена. Типичная ошибка — зайти в панель хостинга, добавить там записи и ждать, пока сайт заработает. Но если NS-серверы в настройках регистратора указывают на другой хостинг, все правки бесполезны.
Чтобы перенести DNS-зону на Cloudflare:
- Добавить домен в Cloudflare, импортировать существующие записи.
- Cloudflare выдаст два NS-сервера (
xxx.ns.cloudflare.com). - Прописать эти NS у регистратора домена.
- Дождаться распространения изменений.
Сколько ждать? Официально до 72 часов, на практике изменения расходятся за 1–4 часа. Это называется propagation — распространение обновлённых данных по кешам резолверов по всему миру. Скорость зависит от TTL предыдущих NS-записей.
После смены NS и настройки зоны смотрите, как продвигается перенос сайта пошагово — там расписаны все этапы, включая проверку DNS.
Частые ошибки при настройке DNS
Большинство проблем с «сайт не работает» или «почта не доходит» вызваны одной из следующих ошибок.
- Добавили A-запись у хостера, не сменили NS у регистратора. Записи в панели хостинга работают только тогда, когда NS домена указывают на этот хостинг.
- CNAME на корневой домен.
@ CNAME mysite.netlify.app— некорректная запись. Нужна A-запись с IP-адресом, который выдаёт Netlify (или используйте CNAME Flattening у Cloudflare). - MX указывает на IP-адрес. MX должен указывать на имя хоста. Запись
@ MX 10 185.0.0.1— ошибка. - Перепутан приоритет MX. Меньшее число = больший приоритет. MX с приоритетом 1 важнее, чем с приоритетом 10.
- Забыли про www. A-запись для
@не распространяется наwwwавтоматически. Нужна отдельная запись или CNAMEwww → @. - Ждут мгновенного эффекта при высоком TTL. Если у записи TTL 86400, изменение «дойдёт» максимум через сутки. Снижайте TTL заранее.
Как проверить DNS-записи онлайн
Для диагностики есть несколько инструментов.
Командная строка — самый быстрый способ, если работаете на Linux или macOS:
dig A example.com +short
dig MX example.com
nslookup -type=TXT example.com
Команда dig A example.com +short вернёт только IP-адрес — для быстрой проверки. Без флага +short покажет полный ответ с TTL и именем авторитетного сервера.
Онлайн-инструменты подходят, когда под рукой нет терминала или нужно проверить распространение по всему миру:
- MXToolbox (mxtoolbox.com) — диагностика MX, SPF, DKIM, DMARC
- DNSChecker (dnschecker.org) — propagation по 100+ серверам в разных странах
- Cloudflare DNS Checker — встроен в панель Cloudflare при добавлении домена
При переносе сайта смотрите сразу несколько параметров: IP в A-записи, MX для почты, TTL текущих записей. Если что-то пошло не так с производительностью сервера после переноса — смотрите, чем отличается NVMe от SSD для сервера, это влияет на скорость отдельно от DNS. Для технических деталей DNS — спецификация DNS RFC 1035, настройки безопасности — в документации Cloudflare DNS.
Настройки, гайды и отдельные разборы конкретных хостеров собраны в блоге: гайд по настройке VPS с нуля, обзор Selectel и облачный DNS.
Ну и в заключение
DNS — не магия, а конкретная иерархия серверов и набор записей с чёткими правилами. Запись A говорит «этот домен — вот этот IP». MX говорит «почту для этого домена принимает вот этот сервер». CNAME создаёт псевдоним. TXT хранит инструкции для внешних сервисов.
Понимание этих типов снимает большинство вопросов при привязке домена к хостингу, настройке почты или подключении CDN. Следующий шаг — выбрать надёжный хостинг: смотрите лучшие VPS-хостинги 2026 или сравните 45 VPS в большом обзоре с отзывами.
Настроили DNS — теперь нужен надёжный хостинг. Сравните тарифы виртуального хостинга на free-hosting.ru и выберите оптимальный вариант под свой проект.