DNS кажется магией: вводите domain.com в браузер, и вы оказываетесь на нужном сайте. Никакого IP-адреса, никакой возни с цифрами. Всё потому что где-то в интернете миллионы DNS-серверов на доли секунды переводят "example.com" в "192.0.2.1" и ведут вас туда. DNS-рекорды — это язык, на котором эти серверы говорят друг с другом.
Но "ввести A-рекорд и забыть" — это как водить машину, не понимая, что такое масло в двигателе. Рано или поздно что-то сломается. Письма будут теряться, потому что забыли про MX. Сайт будет на одном IP, а CDN ждёт на другом — и трафик течёт неправильно. TXT-рекорды останутся пустыми, и ваш домен будут спамить от имени хакеров.
Как работает DNS разрешение
Когда вы набираете example.com в браузер, запускается цепочка событий, которая на разных этапах обращается к разным DNS-серверам. Это не мгновенно и не где-то "в интернете" — это конкретный протокол, конкретные серверы, конкретный порядок.
Шаг 1: Recursive resolver — твой ISP (или Cloudflare 1.1.1.1, Google 8.8.8.8) ловит запрос от браузера и говорит: "я помогу тебе найти IP адрес для example.com".
Шаг 2: Root nameserver — resolver спрашивает у root-сервера (их 13 по миру), где найти информацию о .com доменах. Root отвечает: "спроси TLD-сервер вот тот".
Шаг 3: TLD nameserver — resolver спрашивает у TLD-сервера (который знает про все .com домены), где найти example.com. TLD отвечает: "спроси authoritative nameserver вот там".
Шаг 4: Authoritative nameserver — resolver спрашивает авторитетный сервер (тот, что вы настроили у регистратора). Тот отвечает: "А-рекорд для example.com — это 192.0.2.1". Resolver возвращает этот ответ браузеру, и браузер подключается к IP-адресу.
Весь этот процесс занимает 50-200 миллисекунд, потому что результаты кэшируются на каждом шаге. Если resolver уже спрашивал example.com 5 минут назад (за время жизни TTL), он не повторяет весь процесс — просто возвращает кэшированный ответ.
A-рекорд: основа веб-адресации
A-рекорд — это самый базовый тип. Он ставит в соответствие доменное имя IPv4-адресу. Когда вы создаёте сайт и хостинг даёт вам IP-адрес (например, 192.0.2.1), вы добавляете A-рекорд:
example.com A 192.0.2.1
Это означает: "когда кто-то пытается подключиться к example.com, дай им IP-адрес 192.0.2.1". Браузер получает этот IP и подключается на порт 80 или 443.
Когда использовать: Когда ваш сайт находится на конкретном сервере, хостинге или VPS с фиксированным IP. Это прямое указание на один IP адрес.
Ошибка #1: неверный IP. Вы скопировали IP хостинга неправильно. Вроде простое, но проверьте дважды. Браузер не скажет "у вас неправильный IP" — он просто не подключится.
Ошибка #2: забывчивость про www. example.com и www.example.com — это разные доменные имена. Если у вас есть A-рекорд для example.com, но не для www.example.com, то www.example.com не будет работать. Добавьте второй A-рекорд или используйте CNAME (см. ниже).
AAAA-рекорд: IPv6 адресация
AAAA-рекорд — это то же самое, что A-рекорд, но для IPv6-адресов (которые длинные, из букв и цифр: 2001:db8::1). По мере исчезновения IPv4-адресов, IPv6 становится всё более важным. Многие регионы уже переходят на IPv6-only.
example.com AAAA 2001:db8::1
Браузер попробует подключиться по IPv6 в первую очередь, а если не получится, вернётся к IPv4 (A-рекорд). Хороший практика — добавить обе записи, если ваш хостинг поддерживает IPv6.
Когда использовать: Если хостинг предоставляет IPv6, обязательно добавьте AAAA-рекорд. Это улучшает совместимость, особенно в сетях, где IPv4 истощён. На 2026 год это не просто nice-to-have, это становится обязательным для новых проектов.
CNAME-рекорд: альтернативные имена
CNAME (Canonical Name) — это как ссылка на другое доменное имя. Вместо того чтобы указывать IP-адрес, вы говорите "используй записи для другого домена":
www.example.com CNAME example.com blog.example.com CNAME myblog.wordpress.com
Это полезно для поддоменов. Вы хотите, чтобы www.example.com разрешалась в тот же IP, что и example.com? Создайте CNAME. Хотите, чтобы blog.example.com указывал на WordPress хостинг? CNAME на WordPress блоги.
Когда использовать: Для поддоменов (www, blog, api, cdn). Когда ваш поддомен указывает на внешний сервис (CDN, конструктор сайтов, облачный хостинг). Когда вы хотите централизованно управлять IP-адресом и изменять его в одном месте.
Критическое ограничение: CNAME не работает на apex (root). Вы НЕ можете сказать "example.com CNAME example.com". Это зациклится. На root вы должны использовать A-рекорд, а затем CNAME для www и других поддоменов.
Ошибка #1: CNAME с другими рекордами. Если вы добавите CNAME на www.example.com, вы не можете одновременно добавить TXT или MX на www.example.com. Когда DNS видит CNAME, он забывает обо всех остальных рекордах для этого имени.
Ошибка #2: забытая точка в конце. CNAME target должен быть "example.com." (с точкой в конце), не "example.com". Без точки DNS интерпретирует это как "example.com.example.com" — рекурсивное имя, которое не существует.
MX-рекорды: маршрутизация почты
MX-рекорд (Mail eXchange) отвечает за то, куда идёт электронная почта для вашего домена. Когда кто-то отправляет письмо на example@example.com, почтовый сервер отправителя смотрит MX-рекорды для example.com и направляет письмо туда.
example.com MX 10 mail1.example.com example.com MX 20 mail2.example.com example.com MX 30 mail3.example.com
Число в начале (10, 20, 30) — это приоритет. Ниже = выше приоритет. Сервер отправителя сначала попробует связаться с mail1 (приоритет 10). Если mail1 не отвечает, пробует mail2. Если и mail2 не отвечает, пробует mail3. Это резервирование обеспечивает, что письма не потеряются, если один mail-сервер временно недоступен.
Когда использовать: Всегда, если вы принимаете письма на адреса вашего домена. Даже если используете Google Workspace, Microsoft 365 или другую облачную почту — они дают вам конкретные MX-рекорды для добавления.
Ошибка #1: неверный mail server. Вы скопировали MX-хост неправильно. Проверьте документацию вашего почтового провайдера дважды. MX должен указывать на существующий сервер.
Ошибка #2: отсутствие MX-рекорда. Если у вас вообще нет MX-рекорда, почту всё равно будут отправлять, но DNS сервер может попробовать подключиться к A-рекорду домена (старое поведение). Это ненадёжно. Добавьте MX-рекорды явно.
Ошибка #3: проблема с приоритетом. Если все MX-рекорды имеют одинаковый приоритет, сервер отправителя выбирает случайный. Если один из них неправильный, половина писем будет потеряна. Убедитесь, что приоритеты разные и в правильном порядке.
TXT-рекорды: безопасность и верификация
TXT-рекорд хранит произвольный текст. Это самый универсальный тип рекорда, и его используют для множества целей: проверка владения доменом, боротьба со спамом, шифрование писем, безопасность сайта.
example.com TXT "v=spf1 include:_spf.google.com ~all" example.com TXT "google-site-verification=ABC123XYZ" default._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0..."
Есть три основных типа TXT-рекордов в контексте безопасности:
SPF (Sender Policy Framework). Это TXT-рекорд, который говорит: "письма от example.com могут отправляться только с этих IP-адресов или серверов". Когда приёмный сервер получает письмо от example.com, он проверяет SPF-рекорд и смотрит, пришло ли письмо с авторизованного IP. Если нет — письмо помечается как спам или отклоняется.
DKIM (DomainKeys Identified Mail). Это криптографическое подписание писем. DKIM-рекорд содержит публичный ключ, который приёмный сервер использует для проверки подписи письма. Если письмо было отправлено с авторизованного сервера, подпись верна. Если кто-то подделал письмо — подпись не совпадёт.
DMARC (Domain-based Message Authentication, Reporting, and Conformance). Это политика, которая говорит: "если SPF или DKIM не пройдёт, делай то-то". Может быть three режима: none (отслеживай, но не блокируй), quarantine (помещай в спам), reject (отклоняй письмо полностью).
TXT-рекорды также используются для верификации владения доменом. Когда вы подключаете домен к Google Search Console, Cloudflare, Let's Encrypt или другому сервису, они просят добавить TXT-рекорд с уникальным значением. Это доказывает, что вы контролируете DNS этого домена.
Ошибка #1: неправильный формат SPF. SPF должен быть в кавычках и начинаться с "v=spf1". Если забудете кавычки или напишете "v=spf2", SPF не будет работать. Приёмные серверы его просто проигнорируют.
NS-рекорды: делегирование авторитета
NS-рекорды (NameServer) указывают, какие nameservers отвечают за ваш домен. Эти рекорды находятся у регистратора домена (GoDaddy, Namecheap, Google Domains). Когда TLD-сервер смотрит NS-рекорды для example.com, он узнаёт, какие nameservers знают про все записи для example.com.
example.com NS ns1.example.com example.com NS ns2.example.com example.com NS ns3.example.com
Вы редко редактируете NS-рекорды вручную. Они устанавливаются при регистрации домена и указывают на nameservers вашего хостинга или DNS-провайдера (например, Cloudflare, Route53, Linode DNS). Если вы переходите на другой DNS-провайдер, вы меняете NS-рекорды у регистратора.
SOA-рекорд: авторитет зоны
SOA-рекорд (Start of Authority) описывает, кто отвечает за DNS-зону вашего домена. Он содержит:
example.com SOA ns1.example.com postmaster.example.com ( 2026032801 ; serial (дата+версия) 3600 ; refresh (проверять каждые 60 минут) 1800 ; retry (если авторитетный сервер не отвечает, повторить через 30 минут) 604800 ; expire (если авторитетный сервер долго не отвечает, забыть зону через 7 дней) 86400 ; minimum TTL (минимальное время кэширования для всех рекордов) )
SOA-рекорд устанавливается автоматически, и вам редко нужно его менять. Но его параметры важны для DNSSEC (цифровая подпись DNS-зоны) и для secondary nameservers (серверы, которые реплицируют вашу зону).
SRV-рекорд: обнаружение сервисов
SRV-рекорд указывает на конкретный сервис на конкретном хосте с конкретным портом. Это используется редко, но критично для некоторых протоколов (SIP, XMPP, Kerberos).
_sip._tcp.example.com SRV 10 60 5060 sip.example.com _xmpp._tcp.example.com SRV 5 0 5222 xmpp.example.com
Формат: _service._protocol.domain SRV priority weight port target
- service — имя сервиса (sip, xmpp, ldap)
- protocol — tcp или udp
- priority — ниже = выше приоритет (как в MX)
- weight — для балансировки между серверами с одинаковым приоритетом
- port — порт, на котором слушает сервис
- target — хост, на котором работает сервис
CAA-рекорд: контроль выдачи сертификатов
CAA (Certification Authority Authorization) рекорд ограничивает, какие Certificate Authorities (CA) могут выдавать сертификаты для вашего домена. Без CAA любой CA может потенциально выдать фальшивый сертификат для вашего домена (если вы забудете про проверку при регистрации).
example.com CAA 0 issue "letsencrypt.org" example.com CAA 0 issuewild "letsencrypt.org" example.com CAA 0 iodef "mailto:security@example.com"
Это говорит: "только Let's Encrypt может выдавать сертификаты для example.com. Если кто-то ещё попытается, пошлите отчёт на security@example.com". Это мощная защита от компрометации домена и выдачи вредоносных сертификатов.
PTR-рекорд: обратный DNS
PTR-рекорд (Pointer) — это обратный поиск: вместо "какой IP у example.com?" он отвечает на "какое доменное имя у IP-адреса 192.0.2.1?". Используется в основном для проверки подлинности почты и для диагностики.
1.2.0.192.in-addr.arpa PTR mail.example.com
Для установки PTR-рекорда вам нужен контроль над IP-адресом (обычно у хостинга). Когда почтовый сервер получает письмо с IP 192.0.2.1, он смотрит PTR-рекорд и видит "это mail.example.com". Если PTR не совпадает с доменом отправителя, письмо может быть помечено как спам.
Сравнение: A-рекорд vs CNAME-рекорд
| Параметр | A-рекорд | CNAME-рекорд |
|---|---|---|
| Указывает на | IPv4-адрес | Доменное имя |
| На apex (root) | Можно | Нельзя |
| На поддомене | Можно | Можно (обычно выбирают CNAME) |
| Запросы DNS | 1 запрос (A-рекорд → IP) | 2+ запроса (CNAME → доменное имя → IP) |
| Скорость | Немного быстрее | Немного медленнее (из-за дополнительного запроса) |
| Может сосуществовать с MX/TXT | Да | Нет |
| Переносимость | Если меняется IP — нужно менять рекорд | IP может меняться на target, рекорд не трогаем |
Практическое правило: используйте A-рекорд для корневого домена (example.com), CNAME для поддоменов (www.example.com, api.example.com).
TTL: управление кэшированием
TTL (Time To Live) — это число в секундах, которое говорит DNS-резолверам, как долго кэшировать ответ. TTL 3600 означает "помни этот ответ 1 час, потом спроси ещё раз".
Низкий TTL (300–1800 секунд): Изменения распространяются быстро (за 5–30 минут). Нужен перед миграцией домена или IP-адреса. Минус: больше нагрузка на authoritative nameservers, потому что резолверы часто спрашивают.
Стандартный TTL (3600–7200 секунд): 1–2 часа кэширования. Это золотая середина для большинства сайтов. Достаточно эффективно, но изменения видны относительно быстро.
Высокий TTL (86400 секунд и выше): 1+ день кэширования. Минимальная нагрузка на nameservers, максимальная экономия ресурсов. Но если нужна миграция, изменение видно не сразу. Используется, если вы уверены, что IP не будет меняться месяцами.
Правильный workflow: Планируете миграцию? За день до этого понизьте TTL до 300 секунд. После успешной миграции подождите 24 часа, потом вернитесь к нормальному TTL. Это гарантирует быстрое распространение изменения без параллельного трафика между старым и новым IP.
Как проверить свои DNS-рекорды
Нельзя вслепую верить, что всё правильно настроено. DNS-рекорды нужно проверять:
Использование dig (Linux/Mac):
dig example.com A dig example.com MX dig example.com TXT dig example.com AAAA
Использование nslookup (Windows/Linux/Mac):
nslookup example.com nslookup -type=MX example.com
Онлайн DNS-проверка: AtomPing DNS Lookup — бесплатный инструмент для проверки всех рекордов домена в одном месте. Вводите домен, и видите A, AAAA, MX, TXT, NS, SOA, CAA — всё сразу.
Что смотреть в выводе:
- A-рекорд указывает на правильный IP вашего хостинга
- MX-рекорды в правильном порядке приоритета
- TXT-рекорды содержат SPF, DKIM, DMARC (если вы отправляете письма)
- NS-рекорды указывают на ваш DNS-провайдер
- Нет мусорных рекордов, которые вы не добавляли
Типичные ошибки в DNS и как их избежать
Ошибка 1: Неправильный IP в A-рекорде. Вы скопировали IP с опечатками или это IP старого хостинга. Результат: сайт недоступен. Решение: трижды проверьте IP перед добавлением рекорда.
Ошибка 2: CNAME на apex домена. Вы добавили CNAME на example.com вместо www.example.com. Результат: домен полностью сломан, никакие рекорды не работают. Решение: всегда используйте A-рекорд на apex, CNAME на поддоменах.
Ошибка 3: Отсутствие MX-рекордов. Вы добавили только A-рекорд, забыли про MX. Результат: письма не приходят. Решение: добавьте MX-рекорды в соответствии с документацией почтового провайдера.
Ошибка 4: Неправильный SPF-рекорд. Вы забыли квадратные скобки или неправильно указали IP. Результат: письма отмечены как спам. Решение: используйте SPF-генератор (например, dmarcian.com) для создания правильного рекорда.
Ошибка 5: Очень высокий TTL при миграции. TTL 86400 (1 день), и вы срочно меняете IP. Результат: часть трафика идёт на старый IP неделю. Решение: планируйте миграцию заранее, понизьте TTL за день до этого.
Ошибка 6: Забытая точка в CNAME target. Вы написали "example.com" вместо "example.com." (с точкой). Результат: CNAME разрешается в "example.com.example.com", что не существует. Решение: всегда добавляйте точку в конце target CNAME.
Ошибка 7: www и non-www указывают на разные IP. www.example.com на один сервер, example.com на другой. Результат: перенаправления, двойное содержимое, проблемы с SEO. Решение: используйте CNAME для www.example.com, указывающий на example.com, и поддерживайте одну "canonical" версию.
Мониторинг DNS в production
DNS — критичный компонент вашей инфраструктуры. Если DNS сломан, ваш сайт недостижим, письма не доходят, API не работает. Поэтому DNS нужно мониторить так же, как вы мониторите основной сайт.
DNS Lookup check. Периодически запрашивайте ваш домен (например, каждые 60 секунд) и проверяйте, что резолвер возвращает правильный IP. Если IP меняется неожиданно — это признак компрометации или ошибки конфигурации.
Quorum DNS checks. Проверяйте DNS разрешение из разных регионов и от разных резолверов. Если DNS работает из Europe но не из Asia — это проблема BGP или локального резолвера. AtomPing мониторит DNS разрешение из 11 регионов, поэтому вы видите проблемы раньше пользователей.
Полный чек-лист для настройки DNS
Перед запуском:
- Добавьте A-рекорд для example.com
- Добавьте CNAME для www.example.com (или второй A-рекорд, если на другом IP)
- Добавьте AAAA-рекорд (если хостинг поддерживает IPv6)
- Добавьте MX-рекорды (если принимаете письма)
- Добавьте SPF-рекорд TXT (если отправляете письма)
- Добавьте CAA-рекорд (ограничение выдачи сертификатов)
После добавления:
- Проверьте все рекорды через dig/nslookup/онлайн-инструмент
- Убедитесь, что NS-рекорды указывают на правильный DNS-провайдер
- Попробуйте подключиться к сайту с разных устройств
- Отправьте тестовое письмо на external адрес (если используете собственный домен для почты)
На production:
- Настройте мониторинг DNS разрешения (используйте DNS Lookup check)
- Получайте алерты, если DNS перестаёт работать
- Проверяйте DNS с разных регионов (multi-region monitoring)
Заключение
DNS — это не магия. Это конкретный протокол с конкретными рекордами, каждый из которых имеет назначение. A-рекорды маршрутизируют трафик, MX-рекорды маршрутизируют письма, TXT-рекорды хранят безопасность.
Понимание типов рекордов критично для управления доменом, миграции хостинга, настройки почты, защиты от спама, и верификации владения. Ошибки в DNS — это часто первая причина недоступности сайта, потерянных писем, и скомпрометированных доменов.
Не полагайтесь на "наверное работает". Проверяйте DNS рекорды через dig или DNS Lookup инструмент. Мониторьте DNS разрешение из разных регионов (AtomPing проверяет DNS из 11 европейских регионов). Если DNS сломан — это проблема номер 1 в production. Относитесь к нему соответственно.
Связанные материалы
FAQ
What is a DNS record and why do I need them?
A DNS record is a piece of information stored in your domain's DNS zone that tells the internet how to route traffic and services. Without DNS records, people couldn't find your website by typing its domain name — they'd need to remember your IP address. DNS records also direct email to the right servers, verify domain ownership, and secure communications. You need DNS records because they're the foundation of how your domain works on the internet.
What is the difference between A records and CNAME records?
An A record maps a domain name directly to an IPv4 address (e.g., example.com → 192.0.2.1). A CNAME record is an alias that points to another domain name (e.g., www.example.com → example.com). Key difference: A records point to IPs, CNAME records point to domain names. You cannot use a CNAME at your domain apex (root), but you can use A records. CNAME records are useful for pointing subdomains to CDNs or load balancers.
What are MX records and how do they work?
MX (Mail eXchange) records tell email servers where to send mail for your domain. They contain a priority number (lower = higher priority) and a mail server address. When someone sends mail to user@example.com, the sender's server looks up the MX records for example.com and delivers the mail to the highest-priority (lowest number) mail server listed. If that server is down, the sender retries with the next priority MX record. This redundancy ensures email doesn't bounce if one mail server is temporarily offline.
What does a TXT record do and why is it important?
TXT records store text-based information associated with your domain. Common uses: SPF records prevent email spoofing by specifying which servers are authorized to send mail from your domain, DKIM records cryptographically sign outgoing emails, DMARC records define what to do with unsigned emails. TXT records also verify domain ownership (required for Let's Encrypt, Google Search Console, etc.). Without proper TXT records, your emails may be rejected as spam, and your domain security is weaker.
What is the TTL (Time To Live) and why does it matter?
TTL is a number (in seconds) that tells DNS resolvers how long they can cache a DNS record before checking the authoritative nameserver again. Low TTL (e.g., 300 seconds = 5 minutes) means changes propagate quickly but increases load on nameservers. High TTL (e.g., 3600 seconds = 1 hour) reduces nameserver load but delays propagation of changes. During planned migrations, lower the TTL before making changes, then increase it again after migration completes. Default TTL is usually 3600 seconds.
How do I check my DNS records and verify they're correct?
Use the `dig`, `nslookup`, or `host` command-line tools, or use an online DNS checker (AtomPing has a free DNS Lookup tool at atomping.com/tools/dns-lookup). Look for A records pointing to your IP, MX records with correct priorities, TXT records with SPF/DKIM/DMARC, and NS records pointing to your nameservers. Common mistakes: missing MX records (mail bounces), wrong TTL (changes don't propagate), CNAME at apex (domain breaks), forgot a trailing dot in CNAME target (resolution fails).