SiteGuard4 ноября 202617 мин чтения

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

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

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

Где находятся действующие DNS-записи домена

Начните с NS-серверов. Регистратор, у которого оплачен домен, хостинг сайта и держатель DNS-зоны могут быть разными компаниями. Редактировать записи нужно там, чьи авторитетные серверы обслуживают зону. Это правило прямо отмечено в инструкции Timeweb по настройке DNS.

Откройте карточку домена у регистратора и найдите раздел «DNS-серверы», «NS» или «Делегирование».
Сверьте указанные имена с опубликованными NS: выполните nslookup -type=NS example.com. либо используйте DNS-проверку с выбором типа NS.
Найдите панель организации, обслуживающей эти серверы, и откройте DNS-зону именно нужного домена.
Уточните доступ у администратора, если серверы принадлежат агентству, инфраструктурному подрядчику или компании с собственными NS.

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

Если NS недавно меняли, ответ обычного резолвера может содержать кэш. Для проверки опубликованного делегирования полезен dig +trace example.com. NS: смотрят, какие серверы указала родительская зона, а затем обращаются к ним напрямую. Метод описан в инструкции Cloudflare по проверке делегирования. Ошибка трассировки сама по себе не доказывает поломку домена: ваша сеть может ограничивать прямые DNS-запросы.

Как читать поля DNS-записи: имя, тип, значение и TTL

В разных панелях одни и те же поля называются «Имя», «Хост» или «Поддомен», «Значение», «Содержимое» или «Указатель». Перед сохранением прочитайте запись как предложение: «Для такого имени публикую такой тип с таким значением».

Поле	Что означает	Пример и проверка
Имя / Host	Имя, к которому относится запись	`www` в зоне `example.com` обычно означает `www.example.com`
`@` или пустое имя	Вершина зоны	Само `example.com`; допустимое обозначение зависит от панели
FQDN	Полное доменное имя	`www.example.com.`; последняя точка в файле зоны делает имя абсолютным
Тип	Формат данных	A, AAAA, CNAME, MX, TXT и другие
Значение	Данные выбранного типа	Для A — IPv4, для CNAME — имя, для TXT — текст
TTL	Срок кэширования	`3600` секунд — час; уточняйте единицы и значение Auto
Приоритет	Очередность выбора	У MX меньшее число предпочтительнее; у A приоритета нет

Форматы записей и абсолютных имен определены в RFC 1035. В панели доменный суффикс и точка могут добавляться автоматически. Проверьте итоговое имя: из полного имени в поле, ожидающем короткое, при неправильной обработке может получиться www.example.com.example.com.

Дополнительные переключатели зависят от сервиса. Например, в Cloudflare есть проксирование: оно влияет на трафик и публичный ответ, поэтому не меняйте его случайно вместе с адресом. Поля разобраны в официальной инструкции Cloudflare.

Основные типы DNS-записей и их назначение

У каждой строки есть конкретная задача. Для обычного сайта чаще всего нужны A или AAAA и настройка имени с www; для почты и внешних сервисов появляются другие записи. Создавать сразу все типы из справочника не требуется.

Тип	Что хранит	Когда нужен
A	IPv4-адрес	Связать имя с сервером, например `192.0.2.10`
AAAA	IPv6-адрес	Предоставить адрес по IPv6, например `2001:db8::10`
CNAME	Другое доменное имя	Создать DNS-псевдоним, например для `www`
MX	Имя почтового сервера и приоритет	Направлять входящие письма домена
TXT	Текстовые данные	Подтверждать владение, публиковать SPF и другие параметры
NS	Имена авторитетных серверов	Обозначать серверы зоны и делегировать подзоны
SOA	Служебные параметры зоны	Хранить серийный номер, таймеры и административные сведения
CAA	Разрешения центрам сертификации	Определять, кто вправе выпускать сертификаты для имени
SRV	Узел, порт, приоритет и вес	Помогать совместимым клиентам находить определенный сервис

Назначение распространенных типов разобрано в справочниках Timeweb и Cloudflare. Далее — ограничения, которые важно учитывать при настройке.

Все домены, IP-адреса и строки ниже — учебные примеры. Адреса из диапазонов 192.0.2.0/24 и 2001:db8::/32 не подставляют в рабочую зону вместо данных хостинга. Значения для реальной настройки берут у своего провайдера.

A, AAAA и CNAME: как настроить адреса сайта

Составьте список имен проекта: example.com, www.example.com, другие поддомены. Проверяйте каждое: изменение корня не меняет самостоятельную A-запись у www.

A и AAAA: только IP-адрес нужной версии

В A указывают IPv4, в AAAA — IPv6. Замена A не исправляет старую AAAA. Форматы и порядок редактирования показаны в инструкции Timeweb.

example.com. 3600 IN A    192.0.2.10
example.com. 3600 IN AAAA 2001:db8::10

Публикуйте AAAA, когда на указанном IPv6 настроен нужный сайт. Если часть посетителей видит другой проект, проверьте обе версии адреса. При отсутствии рабочего IPv6 согласуйте удаление устаревшей AAAA с администратором.

В A нельзя вписать https://192.0.2.10, путь /catalog/ или порт :8080: она содержит только адрес. Несколько A одного имени допустимы, но второй адрес сам по себе не создает резерв с проверкой доступности.

CNAME: псевдоним имени, а не редирект страницы

www.example.com. CNAME example.com. продолжает DNS-разрешение через целевое имя. Она не меняет адресную строку браузера и не возвращает HTTP-код 301. Переход с www на корень настраивают на уровне веб-сервера, сайта или сервиса перенаправлений.

Обычный CNAME нельзя совмещать с A, AAAA, MX, TXT и другими обычными данными того же имени. Служебные данные DNSSEC — отдельный технический случай. Ищите конфликт по полному имени, не удаляйте всю зону. Ограничение объяснено в документации Cloudflare.

Вершина зоны уже содержит SOA и NS, поэтому совет «поставьте CNAME на @» не универсален. У некоторых провайдеров есть ALIAS, ANAME или CNAME flattening со своей логикой. Например, Cloudflare при flattening возвращает итоговый IP вместо CNAME. Проверьте поддержку у своего DNS-провайдера и требования подключаемой платформы.

Проверяйте и цель псевдонима: для сайта она должна разрешаться в рабочий адрес. Если внешнему сервису нужна именно видимая CNAME для подтверждения владения, flattening может изменить ожидаемый ответ.

MX и TXT: почта, подтверждение домена и служебные настройки

Переезд сайта и смена почтового обслуживания — разные задачи. Если почта остается у прежнего провайдера, изменение адреса веб-сервера обычно не требует пересоздания MX, SPF, DKIM и DMARC.

MX указывает на имя почтового сервера

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

В примере предпочтителен сервер с числом 10, затем — с 20. Значение MX — имя узла, а не IP или адрес ящика. Эти правила заданы в RFC 1035. Цель MX должна иметь адресные записи и не быть CNAME — см. RFC 2181.

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

TXT: точное имя и содержимое

Для подтверждения владения проверяйте и токен, и имя: TXT на example.com не заменяет TXT на _verify.example.com. Разные TXT могут сосуществовать на одном имени, если их назначение этого не запрещает. Кавычки часть панелей добавляет самостоятельно.

Одна длинная TXT может отображаться несколькими строковыми фрагментами в кавычках. Не превращайте их автоматически в отдельные записи. Для SPF их объединение определено в RFC 7208; ключи и токены вводите в формате, выданном сервисом.

SPF, DKIM и DMARC: что сохранить при редактировании

SPF — TXT с началом v=spf1. Для одного проверяемого имени должна выбираться одна SPF-запись. При добавлении источника отправки корректируют общую политику, а не создают второй SPF. Это требование RFC 7208.
DKIM связывает подпись письма с открытым ключом. Имя содержит селектор, например selector1._domainkey.example.com. Разные селекторы могут обслуживать разные ключи.
DMARC публикуют как TXT на _dmarc.example.com. Политика связана с проверками SPF/DKIM и доменом отправителя, но не заменяет их настройку.

Параметры берите у своего почтового сервиса; пример полей есть в справке Timeweb. Для DKIM сервис может дать CNAME вместо TXT. Не меняйте тип или селектор самостоятельно и не копируйте ограничивающую политику, не проверив все легитимные источники отправки.

NS, SOA, CAA и SRV: служебные записи без лишних изменений

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

NS и SOA: обслуживание зоны

NS обозначает авторитетные серверы. Но NS в редакторе зоны и настройка делегирования домена у регистратора — разные места в иерархии DNS. Чтобы передать весь домен другому DNS-провайдеру, недостаточно добавить его NS как обычные строки в старой панели. Для поддомена, напротив, делегирование можно создать NS-записями в родительской зоне.

SOA содержит административные параметры, серийный номер и таймеры зоны. В управляемом DNS ее обычно обслуживает провайдер; например, Cloudflare создает SOA автоматически. Не редактируйте serial или служебные таймеры в надежде ускорить обновление A: это другие механизмы. Для проверки публикации полезнее сравнить фактические ответы всех авторитетных NS.

При смене NS отдельно проверьте DNSSEC. DS в родительской зоне должен соответствовать ключам действующего DNS-провайдера. Старый DS после переезда способен привести к ошибкам проверки и SERVFAIL. Согласуйте последовательность переноса и сроки кэширования с провайдерами; не переносите прежний DS механически. Связь ключей и DS разобрана в документации Cloudflare.

CAA: кто может выпускать сертификаты

CAA задает ограничения для центров сертификации. Она не устанавливает сертификат и не включает HTTPS на сервере. Если выпуск или продление сертификата неожиданно не проходит, проверьте CAA у нужного имени и применимые записи выше по иерархии. Порядок проверки описывает Let's Encrypt. Значения согласуйте с фактическим центром сертификации и платформой, которая выпускает сертификат.

SRV: сервис, узел и порт

_sip._tcp.example.com. 3600 IN SRV 10 5 5060 sip.example.com.

Здесь имя указывает сервис и транспорт, а значение содержит приоритет 10, вес 5, порт 5060 и целевой узел. При равном приоритете вес участвует в выборе сервера. Формат и необходимость поддержки со стороны клиента определены в RFC 2782.

SRV применяют по инструкции конкретного приложения. Добавление такой записи не заставит обычный браузер открывать сайт на произвольном порту. Для веб-приложения на внутреннем порту обычно настраивают прием HTTP/HTTPS и передачу запросов на стороне сервера или платформы.

Как изменить DNS-записи: безопасный алгоритм

Зафиксируйте домен, полное имя и тип записи, старое и новое значение, TTL, время правки и ожидаемый результат. Такая карточка упрощает проверку и возврат конфигурации.

Определите границы изменения. Например: поменять A сайта, сохранив почту. Отдельно уточните судьбу www и AAAA.
Сохраните зону. Сделайте экспорт или список строк с TTL, скриншоты нестандартных переключателей. Запишите NS и состояние DNSSEC.
Получите значения у нужного сервиса. IP — у хостинга, MX — у почтового провайдера, токен TXT — в подключаемой системе.
Проверьте зависимости. Найдите конфликтующие CNAME, старые AAAA и записи интеграций на том же имени.
При необходимости заранее уменьшите TTL. До переключения учитывайте срок хранения старых ответов.
Отредактируйте нужные строки. Не сбрасывайте настройки и не заменяйте всю зону неполным шаблоном ради одного адреса.
Проверьте публикацию на всех авторитетных NS. Сверьте имя, тип и значение, затем ответы обычных резолверов.
Проверьте сайт и затронутые сервисы. Откройте HTTPS, нужные страницы и формы; для почтовых изменений проверьте почту.

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

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

Как проверить DNS-записи домена через nslookup и dig

Проверяйте конкретную пару «имя + тип». Ответ на A не подтверждает правильность MX, а TXT в корне не подтверждает наличие DKIM у селектора. Онлайн-проверка тоже полезна, если показывает выбранный тип, сервер запроса и содержимое ответа, а не только цветной статус.

Все команды ниже только запрашивают DNS и не изменяют записи. Замените example.com своим доменом, а ns1.example.com — реальным авторитетным сервером из результатов проверки NS. Это условные имена, не готовые настройки для вашего проекта.

Windows: запросы nslookup

nslookup -type=NS example.com.
nslookup -type=A example.com.
nslookup -type=AAAA example.com.
nslookup -type=CNAME www.example.com.
nslookup -type=MX example.com.
nslookup -type=TXT example.com.
nslookup -type=TXT _dmarc.example.com.
nslookup -type=TXT selector1._domainkey.example.com.

Без последнего аргумента программа использует DNS-сервер по умолчанию. Для обращения к конкретному серверу добавьте его имя после домена:

nslookup -type=A example.com. ns1.example.com.
nslookup -type=MX example.com. ns1.example.com.
nslookup -debug -type=TXT example.com. ns1.example.com.

Синтаксис выбора типа и сервера приведен в документации Microsoft. Параметр -debug добавляет подробности ответа. Строка Server в начале вывода показывает опрошенный DNS-сервер, а не обязательно сервер сайта. Сообщение о неавторитетном ответе обычно означает ответ резолвера и само по себе не является ошибкой.

dig: тип, авторитетный сервер и детали ответа

dig example.com. A
dig www.example.com. CNAME
dig example.com. MX
dig example.com. TXT
dig example.com. CAA
dig _sip._tcp.example.com. SRV
dig @ns1.example.com. example.com. A +norecurse
dig @ns1.example.com. example.com. SOA +norecurse

В dig сервер задают через @, а +norecurse снимает запрос рекурсивного поиска. Это удобно при прямой проверке авторитетного источника. Для короткого результата есть +short, но при диагностике лучше сохранить заголовок и секции: пустой краткий вывод не объясняет причину. Возможности команды описаны в руководстве ISC BIND.

Повторите прямой запрос для каждого действующего NS. Если один показывает новый адрес, а другой старый, сохраните оба ответа и время проверки для поддержки DNS-провайдера. Одного успешного ответа недостаточно, чтобы объявить публикацию согласованной.

Не рассчитывайте получить полный список зоны запросом ANY. Для рабочего контроля составьте перечень нужных имен и опросите их по отдельным типам. Экспорт из панели и ваш реестр записей решают задачу инвентаризации лучше, чем попытка угадать все существующие поддомены.

Как читать ответ: значение, TTL, статус и авторитетность

Пример строки в ответе dig:

example.com.  300  IN  A  192.0.2.10

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

Что видно	Что означает и куда смотреть
Нужные данные в Answer	Сверьте имя, тип, значение и источник ответа с планом изменения
Флаг `aa`	Ответ помечен как авторитетный; отдельно убедитесь, что сервер входит в действующее делегирование
`NOERROR` без нужного типа	Ошибки протокольного ответа нет, но запись не обязательно найдена: возможны CNAME, NODATA или referral
Пустой Answer, SOA в Authority	Частый вид ответа об отсутствии данных; проверьте статус, имя, тип и отрицательный кэш
Referral с NS в Authority	Сервер направляет к другой зоне; это еще не окончательный ответ о целевой записи
`NXDOMAIN`	Сообщается об отсутствии имени; проверьте опечатку, зону, публикацию и прежний кэш
`SERVFAIL` или тайм-аут	Корректного ответа нет; проверяйте DNS, делегирование, DNSSEC и сетевые ограничения

Термины и различия ответов определены в RFC 9499. Правило «NOERROR — все готово» неверно: после изменения MX нужен правильный набор MX с приоритетами.

Авторитетный запрос показывает источник, запрос резолверу — данные конкретной точки доступа, браузер — работу приложения по найденному адресу. Успех на одном уровне не заменяет остальные проверки.

Сколько обновляются DNS: TTL, публикация и отрицательный кэш

Единого срока «всегда 24 часа» или «ровно 48 часов» для DNS нет. Важно разделять публикацию у провайдера, истечение кэшей рекурсивных серверов и поведение конкретного устройства. Одна и та же запись может быть уже новой на авторитетном NS и еще старой у части пользователей.

TTL относится к ранее полученному ответу

Если резолвер сохранил старую A с TTL 3600, он может продолжать использовать ее в пределах оставшегося срока. Установка нового TTL 300 не меняет таймер у уже сохраненной старой копии. Поэтому при плановом переезде TTL уменьшают заранее и учитывают прежний интервал до самого переключения.

Небольшой TTL облегчает последующие изменения, но означает более частые обращения за данными. Разрешенные значения и режим Auto определяет провайдер. Связь TTL и кэша объясняет документация Cloudflare; локальные кэши могут добавлять свои задержки.

Отсутствие записи тоже может кэшироваться

Если новое имя проверяли до его создания, резолвер мог запомнить NXDOMAIN или отсутствие нужного типа. Даже после появления записи на авторитетных серверах некоторое время будет возвращаться прежний отрицательный ответ. Его срок связан с SOA; правила определяет RFC 2308. TTL только что созданной A не обнуляет такой кэш.

Когда ждать, а когда искать ошибку

На всех авторитетных NS новые данные, на резолвере старые: сравните TTL и повторите проверку после разумного интервала.
Авторитетные NS продолжают отдавать старое значение: проверьте панель, имя зоны, сохранение правки и публикацию у провайдера.
Авторитетные NS отвечают по-разному: уточните состояние синхронизации зоны; зафиксируйте ответы каждого сервера.
DNS везде правильный, а сайт не открывается: переходите к HTTPS, конфигурации сайта, приложению и сети.

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

Типичные ошибки DNS-записей и порядок диагностики

Начинайте с наблюдаемого симптома и самого короткого проверяемого предположения. Сначала уточните имя, тип и источник ответа, затем оценивайте кэш. Это сокращает время поиска и помогает не вносить лишние изменения во время инцидента.

Симптом	Возможная причина	Первое действие
Изменения в панели не видны ни у кого	Редактируется неавторитетная зона	Сверить действующие NS и напрямую запросить нужный тип у них
Корень работает, `www` — нет	У `www` отдельная старая запись или нет нужного ответа	Проверить A, AAAA и CNAME именно для `www.example.com`
Панель не принимает CNAME	На том же имени есть несовместимые записи либо это вершина зоны	Проверить все записи этого имени и поддержку flattening/ALIAS
Часть посетителей видит другой сайт	Кэш, старый AAAA, лишний адрес или неверная конфигурация сервера	Сопоставить A и AAAA, затем проверить обслуживание домена на каждом адресе
Подтверждение домена не проходит	Неверное имя TXT/CNAME, измененный токен или особенность flattening	Запросить точное имя и тип, указанные сервисом, у авторитетного NS
После настройки сайта перестала приходить почта	Удалены или заменены MX, повреждена зона	Сравнить MX и связанные записи с резервной копией
После добавления рассылки возникли ошибки SPF	Созданы два независимых SPF или неверно объединены отправители	Посмотреть TXT на проверяемом имени и согласовать общую политику
После смены NS появляется `SERVFAIL`	Возможна несогласованность DNSSEC/DS	Проверить делегирование и цепочку DNSSEC с провайдером
DNS правильный, но сертификат не выпускается	CAA, проверка владения или настройки платформы	Изучить ошибку выпуска и применимые CAA

Для обращения в поддержку подготовьте конкретику: домен, полное имя записи, тип, ожидаемое значение, время изменения с часовым поясом и ответы двух проверок — авторитетного сервера и используемого резолвера. Формулировка «DNS не обновляется» без этих данных оставляет слишком много вариантов.

Как понять, что настройка завершена

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

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

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

Частые вопросы о DNS-записях

Можно ли поменять A, не меняя NS?

Да, отредактируйте A в действующей зоне. Смена NS нужна при переносе обслуживания DNS. Дополнительно проверьте www и AAAA.

Нужно ли удалять старые TXT при добавлении новой?

Нет, выясните их назначение. TXT разных сервисов могут сосуществовать. Ограничение SPF относится к нескольким независимым SPF-политикам одного имени.

Почему CNAME в панели есть, а проверка показывает A?

Запрос A может разрешать цепочку псевдонимов до адреса. Также возможны flattening или проксирование. Запросите отдельно CNAME и проверьте настройки провайдера.

Можно ли узнать все DNS-записи домена?

Обычный запрос проверяет заданные имя и тип, но не гарантирует полный перечень зоны. Для своего домена используйте экспорт и список из действующей панели.

Что делать, если через двое суток все еще старый адрес?

Запросите A и AAAA у всех авторитетных NS и сравните с резолверами. Если источник правильный, исследуйте кэш и подключение; если старый — место редактирования и публикацию. Простое ожидание не исправит ошибку настройки.

Источники и справочные материалы

Значения для рабочей зоны берите у своих провайдеров. Дополнительные ссылки приведены рядом с соответствующими правилами.