DNS-записи: все типы, примеры и как они работают

DNS (Domain Name System, система доменных имён) переводит человекочитаемые доменные имена в IP-адреса и конечные точки сервисов. Ежедневно в мире обрабатывается более 1,1 триллиона DNS-запросов — и каждый раз за этим стоит конкретная запись в файле зоны. Понимание каждого типа записей, от повсеместного A-рекорда до специализированных CAA и SRV, — это основа для развёртывания, защиты и диагностики любого интернет-сервиса. В этом справочнике я собрал все основные типы записей с примерами из реальной практики.

Как работает DNS

DNS-запрос следует иерархическому пути разрешения: stub-резолвер вашего устройства обращается к рекурсивному резолверу (например, 1.1.1.1 или 8.8.8.8), который запрашивает корневые серверы, затем TLD-неймсервер (.com, .org) и, наконец, авторитативный неймсервер домена, чтобы вернуть ответ. Ответы кэшируются на каждом уровне в соответствии со значением TTL записи.

📖 Определение — DNS-запись (Resource Record) — это запись в файле зоны, которая сопоставляет доменное имя с конкретным значением: IP-адресом, почтовым сервером, текстовой строкой или другим доменным именем.

Записи A и AAAA

Наиболее фундаментальные типы записей. Записи A сопоставляют домен с IPv4-адресом; записи AAAA — с IPv6-адресом.

; A Record — IPv4
example.com.  300  IN  A     93.184.216.34
; AAAA Record — IPv6
example.com.  300  IN  AAAA  2606:2800:220:1:248:1893:25c8:1946

🎯 Всегда публикуйте как A-, так и AAAA-записи для совместимости с двойным стеком. В 2024 году глобальное распространение IPv6 превысило 40% — игнорировать это уже нельзя.

Запись CNAME: что это и как работает

Запись CNAME (Canonical Name, каноническое имя) создаёт псевдоним одного домена для другого. DNS-резолвер следует по цепочке до тех пор, пока не достигнет записи A/AAAA.

www.example.com.   3600  IN  CNAME  example.com.
blog.example.com.  3600  IN  CNAME  myhost.github.io.

Записи MX

Записи MX (Mail Exchanger, почтовый обменник) направляют электронную почту на правильные почтовые серверы. Значение приоритета определяет порядок переключения при отказе — сначала пробуются меньшие числа. Если два сервера имеют одинаковый приоритет, трафик распределяется между ними случайным образом.

Пример типичной конфигурации с основным и резервным сервером:

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Здесь mail1 будет использоваться в первую очередь; mail2 подключится только при недоступности первого.

Записи TXT: как проверить и настроить

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

; SPF — авторизация отправителей почты
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"
; DKIM — верификация подписи электронной почты
selector._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."
; DMARC — политика электронной почты
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
; Верификация домена
example.com.  3600  IN  TXT  "google-site-verification=abc123..."

💡 Один домен может иметь несколько TXT-записей. Однако для домена допускается только одна SPF-запись — несколько SPF-записей приводят к сбоям аутентификации (RFC 7208 §3.2). Это одна из самых частых ошибок при переносе домена между провайдерами.

Записи NS и SOA

Записи NS (Name Server, неймсервер) делегируют зону конкретным неймсерверам. Именно они указывают, какие серверы являются авторитативными для данного домена.

Записи SOA (Start of Authority, начало зоны полномочий) определяют основной неймсервер зоны, адрес электронной почты администратора, а также таймеры serial/refresh/retry/expire. Без корректной SOA-записи зона считается некорректной.

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
                              2024010101  ; serial
                              3600        ; refresh
                              900         ; retry
                              604800      ; expire
                              300 )       ; minimum TTL

Используйте как минимум два географически разнесённых NS-сервера — это базовое требование отказоустойчивости.

Записи SRV

Записи SRV (Service, сервис) указывают хост и порт для конкретных сервисов — например, SIP, XMPP, LDAP. Формат записи включает приоритет, вес, порт и целевой хост.

; _service._protocol.name  TTL  class  SRV  priority  weight  port  target
_sip._tcp.example.com.  3600  IN  SRV  10  60  5060  sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10  40  5060  sip2.example.com.

💡 Поле weight обеспечивает балансировку нагрузки между серверами с одинаковым приоритетом. Чем выше вес — тем большая доля трафика направляется на сервер. В примере выше sip1 получит 60% запросов, sip2 — 40%.

Записи CAA

Записи CAA (Certificate Authority Authorization, авторизация удостоверяющего центра, RFC 8659) указывают, каким удостоверяющим центрам разрешено выпускать сертификаты для домена. Это критически важный механизм контроля безопасности, который часто остаётся ненастроенным.

example.com.  3600  IN  CAA  0  issue     "letsencrypt.org"
example.com.  3600  IN  CAA  0  issuewild ";"
example.com.  3600  IN  CAA  0  iodef     "mailto:security@example.com"

🎯 Используйте issuewild ";", чтобы явно заблокировать выпуск wildcard-сертификатов, если они вам не нужны. Тег iodef уведомляет вас о нарушениях политики — это ваш первый сигнал о попытке несанкционированного выпуска сертификата.

Записи PTR

Записи PTR (Pointer, указатель) обеспечивают обратный DNS — сопоставление IP-адреса с доменным именем. Они необходимы для репутации почтового сервера и диагностики сети. Многие почтовые серверы отклоняют письма с IP-адресов, для которых не настроен PTR.

34.216.184.93.in-addr.arpa.  3600  IN  PTR  mail.example.com.

Обратите внимание: октеты IPv4-адреса записываются в обратном порядке. Управление PTR-записями, как правило, осуществляется через провайдера хостинга или интернет-провайдера, а не через панель управления DNS домена.

TTL в DNS: что это и как влияет на кэш

TTL (Time to Live, время жизни) определяет, сколько секунд резолверы и браузеры кэшируют запись. Высокое TTL снижает нагрузку на DNS-серверы, но замедляет распространение изменений. Низкое TTL ускоряет обновления, но увеличивает количество запросов.

⚡ Совет профессионала: перед запланированным изменением DNS снизьте TTL до 60–300 секунд как минимум за 48 часов — чтобы старое высокое значение TTL истекло из кэшей по всему миру. После того как изменения распространились, верните TTL к нормальному значению (обычно 3600–86400 секунд).

Типичные значения TTL по типам записей:

Лучшие практики

• Публикуйте как A-, так и AAAA-записи для каждого публичного имени хоста
• Настройте записи CAA, чтобы ограничить выпуск сертификатов выбранным удостоверяющим центром
• Настройте TXT-записи SPF + DKIM + DMARC для каждого домена, с которого отправляется электронная почта
• Используйте как минимум два географически разнесённых NS-сервера
• Настройте PTR-записи для всех IP-адресов почтовых серверов
• Снижайте TTL перед миграциями, восстанавливайте после

Частые ошибки при настройке DNS-записей

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

Инструменты для проверки DNS-конфигурации

Проверяйте и верифицируйте вашу DNS-конфигурацию с помощью специализированных инструментов:

🔧 DNS Lookup — запрашивайте записи типов A, AAAA, MX, NS, SOA, SRV и другие.

🔧 TXT Record Lookup — проверяйте записи SPF, DKIM, DMARC и верификационные записи.

🔧 CNAME Lookup — отслеживайте цепочки CNAME до их канонической цели.

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

Ссылки

🎯 Главный вывод: DNS — невидимая основа каждого интернет-сервиса. Освойте типы записей: A/AAAA для адресов, CNAME для псевдонимов, MX для почты, TXT для аутентификации, CAA для контроля сертификатов и SRV для обнаружения сервисов. Сочетайте правильное управление TTL с аутентификацией электронной почты (SPF/DKIM/DMARC), чтобы построить безопасную и отказоустойчивую DNS-конфигурацию.

Ответы на эти вопросы могут быть для вас полезными

Можно ли использовать CNAME для корневого домена (apex domain)?

Нет. CNAME на вершине зоны конфликтует с обязательными записями NS и SOA согласно RFC 1034. Вместо этого используйте ALIAS или ANAME — функциональный эквивалент, который поддерживают многие DNS-провайдеры (Cloudflare, Route 53, DNSimple).

Почему письма попадают в спам, если SPF настроен правильно?

Одной SPF-записи недостаточно. Полноценная защита требует трёх записей: SPF авторизует отправителей, DKIM подписывает письма криптографически, DMARC задаёт политику обработки писем, не прошедших проверку. Без DMARC почтовые серверы получателя сами решают, что делать с подозрительными письмами.

Как быстро распространяются изменения DNS?

Скорость распространения зависит от TTL записи. Если TTL был 86400 секунд (24 часа), то именно столько времени потребуется, чтобы старое значение вышло из кэшей. Поэтому TTL нужно снижать заблаговременно — минимум за 48 часов до планируемого изменения.

Зачем нужны PTR-записи, если есть A-записи?

PTR-записи обеспечивают обратное разрешение: от IP-адреса к доменному имени. Почтовые серверы используют их для проверки репутации отправителя — если PTR не настроен или не совпадает с A-записью, письма с высокой вероятностью будут отклонены или помечены как спам.

Что произойдёт, если не настроить записи CAA?

Любой удостоверяющий центр сможет выпустить SSL/TLS-сертификат для вашего домена без вашего ведома. CAA-записи ограничивают этот список конкретными УЦ и позволяют получать уведомления о попытках нарушения политики через тег iodef.