dns

DNS-записи: полный гид для веб-мастера

Опубликовано: 14.04.2026 · 10 мин чтения · 21 просмотр

Что такое DNS и зачем веб-мастеру знать типы записей

DNS (Domain Name System) — это распределённая база данных, которая связывает человекочитаемые доменные имена с IP геолокацию и другими техническими данными. Когда пользователь вводит example.com в браузере, DNS-резолвер последовательно обходит серверы имён, чтобы найти IP-адрес сервера, к которому нужно подключиться. Весь этот процесс занимает миллисекунды, но от его корректной настройки зависит доступность сайта, работа почты и уровень защиты домена.

Типы DNS Lookup определяют, какую именно информацию хранит запись: адрес сервера, имя почтового узла, верификационный токен или параметры делегирования. Понимание каждого типа позволяет не только устранять инциденты, но и выстраивать правильную архитектуру с нуля: разносить сервисы по серверам, настраивать защиту почты через SPF и DKIM, управлять TTL перед миграцией. Для системного администратора DNS — это первый слой диагностики при любом сбое доступности.

В этом руководстве разбираются все основные типы DNS-записей с примерами синтаксиса, типичными кейсами использования и практическими рекомендациями. Материал ориентирован на веб-разработчиков и администраторов, которые уже работали с DNS, но хотят систематизировать знания или разобраться в нюансах конкретного типа.

Что такое DNS-запись: базовые понятия

DNS-запись — это строка данных в зонном файле или базе данных DNS-сервера. Каждая запись описывает один атрибут домена или субдомена. Записи хранятся в DNS-зонах — логических единицах, объединяющих все записи одного домена. Зоной управляет авторитативный сервер имён (authoritative nameserver), адрес которого делегируется через NS-записи у регистратора.

Ключевые поля любой DNS-записи:

Name — имя домена или субдомена, к которому относится запись (example.com., www.example.com., @ для apex).
TTL (Time To Live) — время жизни в секундах. Определяет, сколько времени кеширующие резолверы могут хранить запись без повторного запроса к авторитативному серверу.
Class — класс записи. Практически всегда IN (Internet).
Type — тип записи (A, AAAA, CNAME, MX и так далее).
RDATA — данные записи, формат которых зависит от типа.

TTL — критический параметр при управлении DNS. Чем он выше, тем меньше нагрузка на DNS-серверы, но тем дольше распространяются изменения. Перед плановой миграцией рекомендуется заблаговременно снизить TTL до 300–600 секунд, а после завершения — вернуть к рабочему значению (3600–86400 секунд).

Типы DNS-записей

A-запись

A-запись (Address) — самый базовый тип. Она сопоставляет имя домена с IPv4-адресом. Любой сайт с прямым доменом имеет как минимум одну A-запись.

Синтаксис:

example.com.    3600    IN    A    93.184.216.34

Здесь 3600 — TTL в секундах, IN — класс Internet, A — тип, 93.184.216.34 — IPv4-адрес сервера.

Типичные сценарии использования:

Указание IP-адреса основного веб-сервера для apex-домена (example.com).
Настройка субдоменов (api.example.com, mail.example.com).
Round-robin DNS: несколько A-записей с одинаковым именем, но разными IP — простой способ распределить нагрузку без балансировщика.

AAAA-запись

AAAA-запись (Quad-A) — аналог A-записи для IPv6-адресов. Длина IPv6-адреса — 128 бит против 32 бит у IPv4, отсюда и название «четыре A».

example.com.    3600    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

На практике AAAA-запись добавляется параллельно с A-записью: если клиент поддерживает IPv6, он предпочтёт AAAA (это регулируется алгоритмом Happy Eyeballs в современных браузерах). Отсутствие AAAA-записи не ломает сайт, но постепенно IPv6 становится обязательным требованием для современной инфраструктуры.

CNAME-запись

CNAME (Canonical Name) — псевдоним, который указывает на другое доменное имя, а не на IP-адрес напрямую. Резолвер, встретив CNAME, переходит к разрешению канонического имени.

www.example.com.    3600    IN    CNAME    example.com.

Это наиболее распространённый способ сделать www синонимом корневого домена.

Критическое ограничение: CNAME нельзя использовать для apex-домена (example.com. без субдомена). Стандарт RFC 1034 запрещает это, поскольку CNAME не может сосуществовать с другими типами записей (MX, NS, SOA), а они обязательно присутствуют на apex-уровне. Если нужен CNAME-подобный эффект для корневого домена, используют проприетарные расширения: ANAME или ALIAS у некоторых провайдеров (Cloudflare CNAME Flattening, AWS Route 53 Alias).

MX-запись

MX (Mail Exchanger) — запись, указывающая на почтовые серверы, принимающие входящую почту для домена. Поле приоритета (preference) определяет порядок обращения: меньшее значение = более высокий приоритет.

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

Отправляющий почтовый сервер сначала попробует mail1.example.com (приоритет 10), и только при недоступности обратится к mail2.example.com (приоритет 20). Если у нескольких записей одинаковый приоритет, выбор между ними случайный — это используется для балансировки нагрузки.

MX-запись должна указывать на имя хоста (A или AAAA-запись), а не на IP-адрес напрямую и не на CNAME. Это явное требование RFC 5321.

TXT-запись

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

SPF (Sender Policy Framework) — перечисляет IP-адреса и серверы, которым разрешено отправлять почту от имени домена:

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.0/24 ~all"

Директива ~all означает мягкую политику (softfail), -all — жёсткую (fail). На домен должна быть ровно одна SPF-запись.

DKIM (DomainKeys Identified Mail) публикует публичный ключ для верификации подписи письма:

default._domainkey.example.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DMARC задаёт политику обработки писем, не прошедших SPF или DKIM:

_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Помимо почтовой безопасности, TXT-записи используются для верификации прав на домен в сервисах Google Search Console, Yandex Webmaster, SSL-провайдерах и многих других платформах.

NS-запись

NS (Name Server) — запись, указывающая на авторитативные серверы имён для домена или зоны. Именно NS-записи определяют, у каких DNS-серверов нужно запрашивать записи домена.

example.com.    86400    IN    NS    ns1.nameserver.com.
example.com.    86400    IN    NS    ns2.nameserver.com.

NS-записи устанавливаются у регистратора при делегировании домена хостинг-провайдеру или DNS-сервису (Cloudflare, NS1, Route 53). Для надёжности рекомендуется иметь минимум два NS-сервера в разных AS (автономных системах). Изменение NS-записей — это смена DNS-провайдера. Такие изменения распространяются медленно (TTL у NS обычно 24–48 часов) и требуют тщательного планирования.

SOA-запись

SOA (Start of Authority) — обязательная запись в каждой DNS-зоне. Она описывает метаданные зоны и параметры синхронизации между первичным и вторичными серверами имён.

example.com.    86400    IN    SOA    ns1.nameserver.com.    hostmaster.example.com. (
                                        2024010101    ; Serial
                                        3600          ; Refresh
                                        900           ; Retry
                                        604800        ; Expire
                                        3600          ; Minimum TTL
                                        )

Поля SOA-записи:

MNAME — первичный сервер имён зоны.
RNAME — email администратора зоны в нотации DNS.
Serial — серийный номер версии зоны. Традиционный формат — YYYYMMDDNN.
Refresh — как часто вторичный сервер проверяет обновления у первичного.
Retry — интервал повторной попытки при неудаче Refresh.
Expire — через сколько секунд вторичный сервер перестаёт отвечать на запросы, если не смог связаться с первичным.
Minimum TTL — минимальный TTL для negative caching (ответы NXDOMAIN).

PTR-запись

PTR (Pointer) — запись обратного DNS (rDNS). Она сопоставляет IP-адрес с именем домена — обратная операция по отношению к A/AAAA.

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

PTR-запись контролируется не владельцем домена, а владельцем IP-адреса — то есть хостинг-провайдером или интернет-провайдером. Чтобы установить PTR, нужно обращаться к провайдеру через панель управления или техподдержку.

Почему это важно для почтовых серверов: большинство современных почтовых фильтров (в том числе у Google, Microsoft) проверяют, совпадает ли PTR IP-адреса отправителя с hostname в SMTP-сессии. Если PTR отсутствует или не совпадает — письмо с высокой вероятностью попадёт в спам.

SRV-запись

SRV (Service) — запись, публикующая информацию о сервисе: хост, проверку портов, приоритет и вес. Используется для автоматического обнаружения сервисов приложениями.

_sip._tcp.example.com.    3600    IN    SRV    10    20    5060    sipserver.example.com.

SRV применяется в VoIP (SIP), мессенджерах (XMPP/Jabber), Kubernetes, службах обнаружения сервисов (service discovery). Для большинства стандартных веб-сайтов SRV-записи не нужны.

CAA-запись

CAA (Certification Authority Authorization) — запись, ограничивающая список удостоверяющих центров, которым разрешено выдавать SSL/TLS-сертификаты для домена.

example.com.    3600    IN    CAA    0    issue    "letsencrypt.org"
example.com.    3600    IN    CAA    0    issuewild    "comodoca.com"

Тег issue разрешает выдачу обычных сертификатов, issuewild — wildcard, iodef задаёт адрес для отчётов о нарушениях. CAA — важный элемент защиты от несанкционированного получения сертификатов мошенниками.

Как проверить DNS-записи

Диагностика DNS-конфигурации — ежедневная задача при работе с сайтами. Ниже приведены основные инструменты.

dig

dig (Domain Information Groper) — стандартный инструмент для DNS-запросов в Linux и macOS.

Запрос A-записи:

dig example.com A

Запрос MX-записей:

dig example.com MX

Запрос TXT-записей с коротким выводом:

dig example.com TXT +short

Запрос к конкретному DNS-серверу:

dig @8.8.8.8 example.com A

Трассировка делегирования от корневых серверов:

dig example.com +trace

nslookup

nslookup доступен в Windows, Linux и macOS. Синтаксис проще, что делает его удобным для быстрой проверки.

nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8

Онлайн-инструменты

Для быстрой проверки без командной строки, а также для просмотра DNS из разных точек мира удобно использовать DNS Lookup от Enterno.io. Инструмент поддерживает все типы записей (A, AAAA, CNAME, MX, TXT, NS, SOA, PTR, SRV, CAA), позволяет выбирать DNS-сервер для запроса, сохраняет историю проверок и предоставляет доступ через REST API документацию.

TTL: что это и как выставлять

TTL (Time To Live) непосредственно влияет на скорость распространения DNS-изменений. Когда вы меняете запись, кеширующие резолверы по всему миру продолжают возвращать старое значение, пока не истечёт TTL.

Рекомендации по TTL:

Рабочий режим: 3600–86400 секунд (1–24 часа). Снижает нагрузку на DNS-серверы.
Перед плановой миграцией (за 24–48 часов): снизить до 300–600 секунд. После завершения миграции — вернуть к нормальному значению.
Критичные сервисы с failover: 60–120 секунд, чтобы быстро переключить трафик при отказе.
MX и NS: обычно 3600–86400 секунд. Эти записи меняются редко, высокий TTL оправдан.

Для отслеживания скорости распространения DNS-изменений по регионам удобен DNS Lookup Enterno.io — он показывает текущие значения записей с разных резолверов.

Типичные ошибки при настройке DNS

CNAME на apex-домене

Установка CNAME для корневого домена (example.com. IN CNAME something.cdn.com.) технически запрещена стандартом и ломает MX, NS и SOA-записи. Правильное решение для apex-домена — всегда A или AAAA, либо ALIAS если провайдер поддерживает.

Отсутствие PTR у почтового сервера

Запуск собственного SMTP-сервера без настроенной PTR-записи — прямой путь в папку спам. Получающие серверы Google, Microsoft и Яндекс проверяют наличие PTR и соответствие hostname. Настройка PTR делается через панель управления VPS или по запросу в поддержку хостинга.

Слишком высокий TTL при миграции

Переезд сайта или почты с высоким TTL (например, 86400) без предварительного снижения означает, что часть пользователей будет попадать на старый сервер до 24 часов после смены A-записи. Стандартная практика: за 2 суток снизить TTL до 300–600, провести миграцию, убедиться в корректной работе, через несколько часов вернуть TTL к рабочему значению.

Конфликт записей при переезде хостинга

При смене хостинга нередко возникает ситуация, когда NS-серверы уже переключены на нового провайдера, но на новом хостинге не перенесены все нужные записи. Часто забывают MX-записи (почта перестаёт работать), TXT-записи SPF/DKIM или PTR. Перед переключением NS необходимо полностью воспроизвести DNS-зону на новом провайдере.

Дублирование SPF-записей

На домене может быть ровно одна SPF TXT-запись. Если добавить вторую, почтовые серверы получат ошибку permerror при валидации SPF, что равнозначно отсутствию SPF. Если используется несколько почтовых провайдеров, их нужно объединить в одну SPF-запись через механизм include:.

Заключение

Грамотная настройка DNS-записей — это не разовая задача, а постоянная часть технической эксплуатации любого проекта. A и AAAA определяют доступность сервера, MX — доставку почты, TXT — безопасность и верификацию, CNAME — гибкость архитектуры, PTR — репутацию почтового сервера. Регулярно проверяйте актуальность своих DNS-записей — особенно после смены хостинга, настройки новой почтовой инфраструктуры или подключения CDN. Сделать это быстро и наглядно поможет DNS Lookup Enterno.io: проверьте все типы записей своего домена прямо сейчас и убедитесь, что конфигурация соответствует вашим ожиданиям.

Проверьте ваш сайт прямо сейчас

Проверить →