DNS-записи домена: как добавить, проверить и починить

Коротко. DNS-запись — это строка в зоне домена вида «имя — TTL — класс — тип — значение». Чтобы добавить запись, откройте зону у того провайдера, чьи NS-серверы указаны у регистратора, выберите тип, заполните имя (@ — корень домена, www — поддомен) и значение. Результат проверяйте командой dig, а не браузером: браузер, операционная система и резолвер провайдера кэшируют ответы и показывают старую картину.

Это практическое руководство по работе с DNS-записями: как устроена зона, как добавить и изменить запись в любой панели, как разобраться с TXT (SPF, DKIM, DMARC, верификация, ACME), как проверить результат из командной строки и почему правка «не применяется». Подробный разбор синтаксиса каждого типа записи вынесен в отдельный справочник — типы DNS-записей: A, AAAA, MX, CNAME, TXT и другие.

Как устроена DNS-зона и что такое ресурсная запись

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

Какой сервер является авторитативным, определяется делегированием: у регистратора домена прописаны NS-серверы, и именно эти серверы считаются источником истины. Отсюда следует правило, которое экономит часы диагностики: править нужно ту зону, куда домен делегирован. Если у регистратора указаны NS Cloudflare, а вы меняете записи в панели старого хостинга — не изменится ничего.

Первое действие при любой проблеме с DNS — выяснить, куда делегирован домен: dig +short NS example.com. Панель, в которой вы правите записи, обязана совпадать с тем, что вернула эта команда.

Из каких полей состоит ресурсная запись

Ресурсная запись (Resource Record, RR) описана в RFC 1035 и состоит из пяти полей. В классическом зонном файле они идут слева направо:

• Name (owner) — имя, к которому относится запись: example.com., www.example.com., _dmarc.example.com.. В веб-панелях это поле часто относительное — вы пишете www, а зона дописывается автоматически.
• TTL — время жизни в секундах: сколько кэширующий резолвер имеет право хранить ответ, не переспрашивая авторитативный сервер.
• Class — класс записи. На практике всегда IN (Internet); остальные классы (CH, HS) в вебе не встречаются, и в панелях это поле обычно скрыто.
• Type — тип записи: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV, CAA, PTR и другие.
• RDATA — собственно значение, формат которого зависит от типа: IP-адрес, доменное имя, текстовая строка, набор из приоритета, веса и порта.

Записи одного имени и одного типа образуют RRset — набор, который резолвер получает и кэширует целиком. Это важная деталь: нельзя дать двум A-записям одного имени разные TTL, и нельзя «частично» обновить набор — резолвер видит его как единое целое.

; фрагмент зоны example.com в формате BIND
; адреса взяты из диапазонов, зарезервированных для документации
; (RFC 5737 для IPv4 и RFC 3849 для IPv6)
$ORIGIN example.com.
$TTL 3600

@         3600  IN  SOA   ns1.example.net. hostmaster.example.com. (
                          2026080601   ; Serial
                          7200         ; Refresh
                          900          ; Retry
                          1209600      ; Expire
                          300 )        ; Negative TTL

@         86400 IN  NS    ns1.example.net.
@         86400 IN  NS    ns2.example.net.

@         3600  IN  A     192.0.2.10
@         3600  IN  AAAA  2001:db8::10
www       3600  IN  CNAME example.com.
api       300   IN  A     192.0.2.11

@         3600  IN  MX    10 mx1.example.net.
@         3600  IN  MX    20 mx2.example.net.

@         3600  IN  TXT   "v=spf1 include:_spf.example.net -all"
_dmarc    3600  IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

@         3600  IN  CAA   0 issue "letsencrypt.org"

Обратите внимание на точку в конце ns1.example.net. и example.com. — она означает полностью определённое имя (FQDN). Имя без точки в зонном файле дополняется значением $ORIGIN. Это источник одной из самых частых ошибок, разобранной ниже.

Типы DNS-записей: сводная таблица

Таблица ниже — рабочая шпаргалка: зачем нужен тип, что лежит в значении и на чём чаще всего спотыкаются. Полный разбор синтаксиса, форматов и сценариев по каждому типу — в справочнике «Типы DNS записей».

Тип	Зачем нужен	Что в значении	Частая ошибка
A	Указать IPv4-адрес хоста	IPv4-адрес	Забытая вторая A-запись со старым IP: половина трафика уходит на мёртвый сервер
AAAA	Указать IPv6-адрес хоста	IPv6-адрес	AAAA есть, но сервер не слушает IPv6 — часть клиентов получает таймаут
CNAME	Сделать имя псевдонимом другого имени	Доменное имя (каноническое)	CNAME на корне домена или рядом с другими записями того же имени
ALIAS / ANAME	Псевдоним на корне домена. Не стандарт, а функция провайдера	Доменное имя, которое провайдер разворачивает в A/AAAA	Перенос зоны к провайдеру без такой функции — запись просто исчезает
MX	Куда доставлять входящую почту домена	Приоритет + имя почтового хоста	MX указывает на IP-адрес или на CNAME; меньшее число = более высокий приоритет, а не наоборот
TXT	Произвольный текст: SPF, DKIM, DMARC, верификация владения, ACME	Одна или несколько строк по 255 символов	Две SPF-записи на домене, пробел внутри значения, обрезанный DKIM-ключ
NS	Кто авторитативен для зоны	Имена серверов имён	NS в зоне не совпадают с NS у регистратора — правки уходят «в никуда»
SOA	Метаданные зоны и параметры репликации	Первичный NS, почта администратора, serial, таймеры	Serial не увеличен — вторичные серверы не забирают обновление
SRV	Автообнаружение сервиса: где он и на каком порту	Приоритет, вес, порт, имя хоста	Забытые подчёркивания в имени вида _sip._tcp
CAA	Ограничить список УЦ, которым можно выпускать сертификаты домена	Флаг, тег (issue, issuewild, iodef), значение	CAA разрешает один УЦ, а сертификат заказывают у другого — выпуск отклоняется
PTR	Обратное разрешение IP → имя (rDNS)	Доменное имя	Пытаются настроить у регистратора домена; на деле PTR управляет владелец IP-адреса

Отдельные разборы: CNAME или A-запись, MX-записи и настройка почты, TXT-запись, NS-запись, SOA-запись, SRV-запись, CAA-запись, wildcard-записи.

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

Интерфейсы у провайдеров разные, но последовательность действий одинаковая. Она же годится для изменения существующей записи — с той разницей, что перед правкой нужно снизить TTL (см. раздел про кэш).

1. Определите, где живёт зона. dig +short NS example.com покажет реальных авторитативных серверов. Если ответ пустой — домен не делегирован или снят с обслуживания; проверьте состояние домена через WHOIS.
2. Откройте раздел управления DNS у того провайдера, чьи NS вернула команда. Это может быть регистратор, хостинг, CDN или отдельный DNS-сервис.
3. Выберите тип записи. Ошибка на этом шаге необратима по последствиям: A вместо CNAME работает, но перестаёт следовать за сменой IP у целевого сервиса.
4. Заполните поле «Имя» (Host, Name, Subdomain). Самое неочевидное поле — разбор ниже.
5. Впишите значение. Для A — IP-адрес, для CNAME/MX/NS — доменное имя, для TXT — строка целиком, вместе со служебными префиксами вроде v=spf1.
6. Задайте TTL. На время правок — 300 секунд, в спокойном режиме — 3600 и выше.
7. Сохраните и проверьте у авторитативного сервера, а не через браузер: dig @ns1.example.net example.com A +short. Если запись видна там — вы всё сделали правильно, дальше это вопрос времени и кэша.

Что писать в поле «Имя»: пусто, @, www и *

Почти все панели подставляют имя зоны автоматически, поэтому поле «Имя» относительное. Значения читаются так:

• Пустое поле или @ — корень домена (apex): example.com. Это одно и то же, панели просто по-разному называют.
• www — поддомен www.example.com.
• api.staging — вложенный поддомен api.staging.example.com. Уровень вложенности не ограничен.
• * — wildcard: отвечает на любое имя, для которого нет собственных записей. Подробности и подводные камни — в статье о wildcard-записях.
• _dmarc, _acme-challenge, _sip._tcp — служебные имена с подчёркиванием. Подчёркивание обязательно, панель его не добавит.

Если в поле «Имя» написать www.example.com в панели, которая дописывает зону сама, получится www.example.com.example.com. Запись создастся без ошибок и будет молча не работать. Всегда проверяйте результат командой dig, а не глазами по панели.

Почему нельзя ставить CNAME на корень домена и что вместо него

Ограничение вытекает из RFC 1034 (раздел 3.6.2) и уточнения в RFC 2181 (раздел 10.1): если у имени есть CNAME, у этого имени не должно быть данных других типов. Исключение сделано только для служебных записей DNSSEC — RRSIG, NSEC и NSEC3.

А у корня домена другие типы обязаны быть: SOA и NS присутствуют на apex всегда, обычно там же живут MX и SPF. Поэтому CNAME на example.com либо отклоняется панелью, либо принимается и ломает почту и делегирование.

Что использовать вместо:

• A и AAAA с реальными адресами — если целевой сервис даёт стабильные IP.
• ALIAS / ANAME / CNAME flattening — функция DNS-провайдера: он сам разрешает целевое имя и отдаёт клиентам обычный ответ A/AAAA. Наружу это выглядит как A-запись, стандарт не нарушается. Название функции у каждого провайдера своё, и при переносе зоны к другому провайдеру она не переезжает.
• Редирект с корня на www на уровне HTTP — если сервис умеет только CNAME. Тогда на apex остаётся A-запись фронтенда, который делает 301.

Разбор различий и сценариев выбора — в статье CNAME или A-запись.

Точка в конце имени и другие тихие опечатки

В панелях, которые под капотом пишут зонный файл BIND, значение mail.example.com без завершающей точки превращается в mail.example.com.example.com. Ошибка не выдаёт себя при сохранении и обнаруживается только когда почта или CDN перестают работать.

Правило простое: в полях «значение» для CNAME, MX, NS и SRV указывайте FQDN и ставьте точку, если панель её показывает в других записях. Если панель точку не использует нигде — не ставьте и вы. И в любом случае сверяйтесь через dig: он покажет итоговое имя ровно так, как его хранит сервер.

TXT-запись в DNS: SPF, DKIM, DMARC и верификация домена

TXT — самый нагруженный смыслом тип. Формально это просто текст, но на нём держатся почтовая аутентификация, подтверждение прав на домен и автоматический выпуск сертификатов. Здесь же случается больше всего ошибок, потому что содержимое записи проверяет не DNS, а потребитель — почтовый сервер, УЦ или сервис верификации.

Ключевая особенность: на одном имени может быть несколько TXT-записей, и это нормально. Ограничение «одна запись» — не свойство DNS, а требование конкретных протоколов: одна SPF-политика на домен, одна DMARC-политика на имя _dmarc.

Верификация владения доменом

Google Search Console, Яндекс Вебмастер, почтовые сервисы, платёжные и рекламные платформы подтверждают права на домен через TXT с уникальным токеном. Обычно токен вешается на корень домена (@), иногда — на служебное имя.

@   3600  IN  TXT  "google-site-verification=aBcD...xyz"
@   3600  IN  TXT  "yandex-verification: aBcD1234efgh"
@   3600  IN  TXT  "v=spf1 include:_spf.example.net -all"

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

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

SPF: кто имеет право отправлять почту от имени домена

SPF (RFC 7208) перечисляет источники, которым разрешено отправлять письма с адресами вашего домена. Запись живёт в TXT на том имени, от которого отправляется почта.

@   3600  IN  TXT  "v=spf1 ip4:192.0.2.0/24 include:_spf.example.net mx -all"

Разбор механизмов:

• ip4: / ip6: — конкретные адреса и подсети отправителей.
• include: — подключить политику стороннего сервиса (почтовый провайдер, рассылочная платформа, CRM).
• a, mx — разрешить адреса из A-записей домена или из хостов MX.
• -all — жёсткий отказ для всех остальных (hardfail), ~all — мягкий (softfail), ?all — нейтрально. Начинать безопаснее с ~all, а после наблюдения по DMARC-отчётам переходить на -all.

Три ограничения, о которые спотыкаются чаще всего:

• Одна SPF-запись на имя. Две TXT-записи, начинающиеся с v=spf1, дают permerror — результат такой же, как если бы SPF не было вовсе. Нескольких провайдеров объединяют через несколько include: в одной строке.
• Не более 10 DNS-запросов при вычислении политики (RFC 7208, раздел 4.6.4). Каждый include:, a, mx, ptr, exists и redirect расходует лимит, причём вложенные include: считаются тоже. Превышение — снова permerror.
• SPF не наследуется поддоменами. Политика на example.com ничего не говорит о mail.example.com. Для поддоменов, с которых уходит почта, нужна своя запись.

DKIM и селектор

DKIM (RFC 6376) публикует открытый ключ, которым получатель проверяет криптографическую подпись письма. Ключ лежит в TXT по имени вида <селектор>._domainkey.example.com. Селектор придумывает отправляющая система: он позволяет держать несколько ключей одновременно и ротировать их без простоя.

mail2026._domainkey   3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Селектор — это не украшение: если почтовый сервис подписывает письма селектором s1, а запись опубликована под именем default._domainkey, проверка не пройдёт. Селектор берётся строго из инструкции отправляющей системы или из заголовка DKIM-Signature уже отправленного письма (параметр s=).

DMARC: что делать с письмами, не прошедшими проверку

DMARC связывает SPF и DKIM с адресом в поле «От» и говорит получателю, как поступать с письмами, не прошедшими проверку. Запись всегда живёт на имени _dmarc.

_dmarc   3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100; sp=none; adkim=r; aspf=r"

• p= — политика для домена: none (только наблюдать), quarantine (в спам), reject (отклонять на этапе SMTP).
• sp= — отдельная политика для поддоменов. Если не указана, поддомены наследуют p=.
• rua= — куда слать агрегированные отчёты. Без них переход на reject — стрельба вслепую.
• pct= — доля писем, к которым применяется политика; удобно для плавного ужесточения.
• adkim / aspf — строгость сопоставления домена: r (relaxed, разрешает поддомены) или s (strict).

Рабочая последовательность: сначала p=none с rua, затем несколько недель чтения отчётов, затем quarantine, и только потом reject. Подробный разбор всех трёх механизмов — в руководстве SPF, DKIM и DMARC.

ACME и _acme-challenge: TXT для выпуска сертификата

Проверка DNS-01 в протоколе ACME доказывает удостоверяющему центру контроль над доменом через временную TXT-запись:

_acme-challenge          3600  IN  TXT  "1qA...token..."
_acme-challenge.staging  3600  IN  TXT  "9zB...token..."

Три практических момента:

• Wildcard-сертификат выдаётся только через DNS-01. HTTP-проверка для *.example.com не подходит в принципе.
• Параллельный выпуск требует нескольких TXT на одном имени. Когда в одном заказе есть и example.com, и *.example.com, оба токена публикуются на _acme-challenge.example.com одновременно. Клиент, который затирает предыдущее значение вместо добавления, ломает выпуск.
• Делегирование через CNAME. Если основной DNS-провайдер не даёт API, имя _acme-challenge можно один раз завести как CNAME на отдельную зону, где автоматизация разрешена. Это распространённый приём для доменов с ручным управлением.

Лимит 255 символов и склейка длинных значений

В DNS текст хранится не как одна произвольная строка, а как набор character-string, каждая из которых не длиннее 255 октетов (RFC 1035, раздел 3.3.14). Общий размер TXT-записи при этом может быть больше — за счёт нескольких строк подряд.

Именно здесь ломается DKIM: открытый ключ RSA на 2048 бит в base64 занимает около 390 символов и в одну строку не помещается. Правильное решение — разбить значение на части в кавычках; потребитель склеит их без разделителей (для DKIM это прописано в RFC 6376, раздел 3.6.2.2, для SPF — в RFC 7208, раздел 3.3).

; НЕПРАВИЛЬНО: одна строка длиннее 255 символов
; авторитативный сервер откажется загрузить зону,
; а панель молча обрежет хвост ключа

; ПРАВИЛЬНО: несколько строк в одной записи
mail2026._domainkey  3600  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1x"
                                      "7Qz3vK9pR2mN4tY6uI8oP0aS1dF3gH5jK7lZ9xC2vB4nM6qW8eR0tY2uI4oP"
                                      "6aS8dF0gH2jK4lZ6xC8vB0nM2qW4eR6tY8uI0oP2aS4dF6gH8jK0lZ2xC4vB"
                                      "IDAQAB" )

Обратный шаг — собрать значение из кусков при проверке. dig +short отдаёт строки в кавычках через пробел, и склеивать их нужно вручную:

# посмотреть, как запись реально разбита на строки
dig +short TXT mail2026._domainkey.example.com

# собрать значение в одну строку без пробелов и кавычек
dig +short TXT mail2026._domainkey.example.com \
  | tr -d '"' | tr -d ' \n' ; echo

# длина собранного ключа — если она меньше ожидаемой,
# значение обрезано при вводе в панель
dig +short TXT mail2026._domainkey.example.com \
  | tr -d '"' | tr -d ' \n' | wc -c

Если DKIM-подпись не проходит проверку, а запись «вроде есть» — первым делом измерьте длину значения. Обрезанный на 255 символах ключ выглядит в панели правдоподобно и не даёт никакой ошибки.

Кавычки, пробелы и экранирование

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

• Всегда берите значение TXT в кавычки там, где панель их принимает.
• Лишний пробел в SPF ломает механизм: include: _spf.example.net с пробелом после двоеточия — это уже не механизм include, а мусор, и вся политика становится невалидной.
• Кавычка внутри значения экранируется обратным слэшем: \". На практике внутри SPF, DKIM и DMARC кавычки не нужны — если они появились, значение скопировано вместе с оформлением из документации.
• Точка с запятой без кавычек в зонном файле начинает комментарий и «съедает» остаток DMARC-записи. В веб-панелях это обычно обработано, в конфигах BIND — нет.

Проверка DNS-записей домена: dig, nslookup и запрос к авторитативному серверу

Проверка через браузер бесполезна: он показывает не состояние DNS, а сумму нескольких кэшей. Достоверный ответ даёт только запрос к авторитативному серверу.

Все основные типы одной командой

# сводка по домену: все типы, которые обычно интересны
for t in NS SOA A AAAA MX TXT CAA; do
  printf '%-5s ' "$t"
  dig +short "$t" example.com | paste -sd' | ' -
  echo
done

# то же самое одной строкой для быстрой копипасты
dig +noall +answer example.com NS SOA A AAAA MX TXT CAA

# служебные имена, которые не видны в общем списке
dig +short TXT _dmarc.example.com
dig +short TXT default._domainkey.example.com
dig +short SRV _sip._tcp.example.com

Флаг +short оставляет только значения — удобно для скриптов. Для разбора проблем полезнее +noall +answer: он показывает имя, TTL, класс и тип, то есть всё, что нужно, чтобы заметить лишнюю запись или неожиданный TTL.

Запрос напрямую к авторитативному серверу, мимо кэша

Это главный приём диагностики. Резолвер может отдавать старое значение ещё сутки, а авторитативный сервер отвечает текущим состоянием зоны всегда.

# 1. узнать авторитативные серверы зоны
dig +short NS example.com

# 2. спросить один из них напрямую
dig @ns1.example.net example.com A +noall +answer

# 3. убедиться, что ответ авторитативный:
#    в секции flags должен быть aa (authoritative answer)
dig @ns1.example.net example.com A | grep -E 'flags|ANSWER SECTION' -A2

# 4. сравнить все авторитативные серверы между собой —
#    расхождение означает незавершённую репликацию зоны
for ns in $(dig +short NS example.com); do
  printf '%-24s %s\n' "$ns" "$(dig +short @"$ns" example.com A | paste -sd, -)"
done

# 5. сравнить ответ авторитативного сервера с публичными резолверами
for r in 8.8.8.8 1.1.1.1 77.88.8.8; do
  printf '%-12s %s\n' "$r" "$(dig +short @"$r" example.com A | paste -sd, -)"
done

Разница между двумя ответами читается так:

• Авторитативный сервер отдаёт новое значение, резолвер — старое. Изменение внесено верно, идёт ожидание TTL. Делать ничего не нужно.
• Авторитативный сервер отдаёт старое значение. Правка не сохранилась или сделана не в той зоне. Возвращайтесь к шагу «куда делегирован домен».
• Разные авторитативные серверы отвечают по-разному. Зона не синхронизирована между первичным и вторичными; чаще всего забыли увеличить Serial в SOA.

Трассировка делегирования: +trace

# пройти цепочку от корневых серверов до зоны домена
dig +trace example.com

# только этап делегирования, без ответов по данным
dig +trace +nodnssec example.com NS

# проверить, что делегирование в зоне TLD совпадает
# с NS-записями внутри самой зоны
dig +short NS example.com                      # что говорит сама зона
dig @a.gtld-servers.net example.com NS +noall +authority   # что говорит TLD

+trace отвечает на вопрос «на каком уровне ломается»: если цепочка обрывается на TLD, проблема в делегировании у регистратора; если доходит до авторитативных серверов и там пусто — проблема в самой зоне.

Проверка SPF, DKIM и DMARC

# SPF: должна найтись ровно одна строка с v=spf1
dig +short TXT example.com | grep -c 'v=spf1'

# DMARC
dig +short TXT _dmarc.example.com

# DKIM по конкретному селектору
dig +short TXT selector1._domainkey.example.com

# MX и адреса почтовых хостов
dig +short MX example.com
for h in $(dig +short MX example.com | awk '{print $2}'); do
  printf '%-28s %s\n' "$h" "$(dig +short A "$h" | paste -sd, -)"
done

# обратная зона: PTR для IP почтового сервера
dig +short -x 192.0.2.25

Селектор DKIM заранее неизвестен и не перечисляется в DNS — его нельзя «найти перебором». Берите его из документации почтового сервиса или из заголовка DKIM-Signature реального письма.

nslookup на Windows

На Windows dig из коробки нет, зато есть nslookup. Синтаксис беднее, но для проверки записи достаточно.

nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com

REM запрос к конкретному серверу — последний аргумент
nslookup -type=NS example.com 8.8.8.8
nslookup -type=A example.com ns1.example.net

REM интерактивный режим
nslookup
> set type=TXT
> example.com
> exit

Полноценная альтернатива в PowerShell — Resolve-DnsName example.com -Type MX -Server 8.8.8.8: вывод структурированный и его удобно фильтровать.

Почему изменения DNS-записей не видны: TTL, кэш и отрицательное кэширование

«Я поменял запись час назад, а сайт открывается старый» — самая частая жалоба по DNS. В подавляющем большинстве случаев запись изменена корректно, а видите вы кэш. Разберём, где именно он живёт.

Где кэшируется ответ

• Рекурсивный резолвер провайдера или публичный (8.8.8.8, 1.1.1.1) — хранит ответ ровно TTL секунд с момента, когда он его получил. Это главный слой.
• Кэш операционной системы: systemd-resolved в Linux, mDNSResponder в macOS, служба DNS Client в Windows.
• Кэш браузера. Chrome и производные держат собственный DNS-кэш, который живёт своей жизнью и не сбрасывается очисткой истории.
• Кэш приложения. JVM по умолчанию кэширует положительные ответы агрессивно, некоторые HTTP-клиенты и пулы соединений резолвят имя один раз при старте и потом не перепроверяют. Отсюда классика: сервис продолжает ходить на старый IP после успешной миграции, пока его не перезапустят.
• Долгоживущие соединения. Уже установленный TCP-коннект не «переедет» на новый IP, даже когда DNS обновился.

# Linux (systemd-resolved)
sudo resolvectl flush-caches
resolvectl statistics

# Linux (dnsmasq / nscd — если используется)
sudo systemctl restart dnsmasq
sudo systemctl restart nscd

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns
ipconfig /displaydns | findstr example.com

# Chrome: открыть в адресной строке служебную страницу
# net-internals с разделом dns и нажать Clear host cache

Отрицательное кэширование: запись, которой ещё нет

Самая непонятная задержка возникает, когда вы сначала спросили имя, а потом создали запись. Отрицательный ответ (NXDOMAIN — имени нет, или NODATA — имя есть, но записей такого типа нет) тоже кэшируется. Механизм описан в RFC 2308: срок хранения берётся как минимум из поля MINIMUM в SOA-записи зоны и TTL самой SOA-записи.

# посмотреть параметры отрицательного кэширования зоны
dig +noall +answer SOA example.com

; вывод: ns1.example.net. hostmaster.example.com.
;        2026080601 7200 900 1209600 300
;                                    ^^^ negative TTL, секунды

# отрицательный ответ виден по статусу и по отсутствию ANSWER
dig new.example.com +noall +comments +authority

Практический вывод: не проверяйте имя до того, как создали запись. Один любопытный dig «а что там сейчас» на публичном резолвере — и этот резолвер будет отдавать «нет такого имени» ещё столько секунд, сколько указано в negative TTL. Именно поэтому у одного сотрудника новый поддомен открывается сразу, а у другого — только через полчаса.

Отрицательный TTL — единственный параметр в SOA, который влияет на клиентов напрямую. Остальные таймеры (Refresh, Retry, Expire) касаются только синхронизации между первичным и вторичными серверами. Если вы часто заводите новые поддомены, держите negative TTL небольшим — 300 секунд достаточно.

Правильная последовательность смены записи

1. За сутки-двое до правки снизьте TTL нужной записи до 300 секунд. Уменьшение TTL само по себе распространяется по старому, большому TTL — поэтому «заранее» здесь не формальность.
2. Дождитесь истечения старого TTL. Если было 86400, ждать нужно до 24 часов, иначе смысл в снижении теряется.
3. Внесите изменение и сразу проверьте у авторитативного сервера: dig @ns1.example.net example.com A.
4. Убедитесь в распространении по разным резолверам — вручную через dig @8.8.8.8 или через проверку распространения DNS.
5. Держите старый сервер живым ещё как минимум один полный старый TTL, а лучше сутки: часть клиентов и приложений держит кэш дольше положенного.
6. Верните TTL к рабочему значению (3600 и выше), когда всё стабилизировалось.

Подробнее о выборе значений — в статье TTL DNS-записи, о механике распространения — в распространении DNS. Смена самих NS-серверов — отдельный сценарий, он разобран в статье как сменить DNS-сервер.

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

Две A-записи на одном имени по недосмотру

Классика при миграции: новую A-запись добавили, старую забыли удалить. DNS честно отдаёт обе, клиенты распределяются между ними примерно поровну — и половина пользователей попадает на выключенный сервер. Симптом обманчивый: «сайт работает через раз», при этом с вашего компьютера всё в порядке.

# сколько A-записей у имени на самом деле
dig +short A example.com | wc -l
dig +noall +answer A example.com

Несколько A-записей — это осознанный приём (round-robin), но только когда все адреса живые. Отказ одного из них DNS не заметит: балансировки с проверкой доступности здесь нет.

CNAME рядом с другими записями на том же имени

Если на имени shop.example.com есть CNAME, у него не должно быть ни A, ни TXT, ни MX. Часть DNS-серверов такую зону просто не загрузит, часть загрузит и будет отвечать непредсказуемо — а резолверы получат противоречивые данные. Особенно легко нарваться, добавив TXT для верификации на имя, где уже стоит CNAME на CDN.

MX указывает на CNAME или на IP-адрес

Значение MX обязано быть именем хоста, у которого есть A или AAAA-запись. RFC 2181 (раздел 10.3) прямо запрещает ссылаться MX на псевдоним, а RFC 5321 требует того же от почтовых серверов. IP-адрес в поле MX — тем более ошибка: часть отправителей воспримет его как имя хоста и не сможет разрешить.

# цель MX должна резолвиться в адрес напрямую, без CNAME
for h in $(dig +short MX example.com | awk '{print $2}'); do
  echo "$h -> $(dig +short "$h" | paste -sd, -)"
  dig +short CNAME "$h" | grep . && echo "  ВНИМАНИЕ: цель MX это CNAME"
done

Забытая точка в конце FQDN

В BIND-подобных панелях mx1.example.net без точки становится mx1.example.net.example.com. Почта перестаёт приходить, при этом в интерфейсе всё выглядит правильно. Проверка — dig +short MX example.com: она покажет имя целиком, вместе с ошибочным хвостом.

Пробел в SPF и две SPF-записи

Два независимых дефекта с одинаковым исходом — permerror, то есть SPF считается отсутствующим:

• лишний пробел после include: или ip4: разрывает механизм на два токена;
• две TXT-записи с v=spf1 на одном имени — например, старая от прежнего провайдера и новая. Объединяйте в одну строку через несколько include:.

Быстрая проверка: dig +short TXT example.com | grep -c 'v=spf1' должно вернуть ровно 1.

Wildcard перекрывает не то, что ожидали

Правила * контринтуитивны:

• явная запись всегда побеждает wildcard — если у api.example.com есть своя A-запись, wildcard для этого имени не сработает;
• wildcard не отвечает на имя, у которого есть любая другая запись — даже если она другого типа. Заведённая TXT-запись на test.example.com «выключает» wildcard для A-запросов к этому же имени;
• wildcard не покрывает имена ниже существующих узлов: *.example.com отвечает за a.example.com, но не за b.a.example.com, если a уже существует как узел зоны;
• wildcard, поставленный «на всякий случай», маскирует опечатки: неверно набранный поддомен резолвится вместо того, чтобы честно вернуть NXDOMAIN.

DNSSEC ломается после смены DNS-провайдера

Самая тяжёлая по последствиям ошибка. Если у домена включён DNSSEC, у регистратора хранится DS-запись — отпечаток ключа зоны. При переносе зоны к другому провайдеру ключи меняются, а DS у регистратора остаётся старым. Валидирующие резолверы (а это почти все крупные) начинают отвечать SERVFAIL, и домен исчезает целиком: сайт, почта, API. Причём выборочно — только для тех клиентов, чей резолвер проверяет подписи.

# есть ли DS у регистратора
dig +short DS example.com

# проходит ли валидация: во flags должен быть ad (authenticated data)
dig +dnssec example.com A | grep -E '^;; flags'

# явная проверка цепочки доверия
dig +sigchase +trusted-key=/etc/trusted-key.key example.com A 2>/dev/null \
  || delv example.com A

Правильный порядок переезда: снять DS у регистратора → дождаться истечения TTL DS → перенести зону → включить DNSSEC у нового провайдера → опубликовать новый DS. Механика подписей разобрана в статье DNSSEC.

Правки вносятся не в ту зону

Домен делегирован на CDN, а записи меняют в панели хостинга; или у домена две зоны у разных провайдеров, оставшиеся с прошлого переезда. Внешне выглядит как «DNS не обновляется неделю». Лечится одной командой: dig +short NS example.com — и правкой там, где реально живёт зона.

Диагностика по симптому: какую запись смотреть

Симптом	Какую запись смотреть	Команда	Типовая причина
Входящая почта не доходит	MX и A-записи хостов, на которые он указывает	dig +short MX example.com	MX отсутствует, указывает на CNAME или на имя без A-записи; забытая точка в FQDN
Исходящая почта уходит в спам	TXT (SPF, DKIM, DMARC) и PTR IP-адреса отправителя	dig +short TXT example.com, dig +short -x 192.0.2.25	Нет SPF или их две; неверный селектор DKIM; PTR не настроен у владельца IP
Сайт открывается старый	A, AAAA и их TTL	dig @ns1.example.net example.com A против dig @8.8.8.8 example.com A	Не истёк TTL; забыта старая A-запись; правка внесена не в ту зону
Сертификат не выпускается	CAA и TXT на _acme-challenge	dig +short CAA example.com, dig +short TXT _acme-challenge.example.com	CAA разрешает другой УЦ; токен не опубликован или затёрт вторым заказом; проверка запущена раньше распространения
Домен не резолвится вообще	NS, делегирование в TLD, DS	dig +trace example.com, dig +short DS example.com	Домен не продлён или снят с делегирования; DS не соответствует ключам зоны — SERVFAIL
Поддомен не работает, корень работает	A/CNAME поддомена и wildcard	dig +noall +answer sub.example.com ANY	Имя записано как FQDN в относительном поле; wildcard отключён явной записью другого типа
Корень не открывается, www работает	A/AAAA на apex	dig +short A example.com	На apex поставили CNAME, и он отброшен; ALIAS не перенесён вместе с зоной
Верификация в сервисе не проходит	TXT на нужном имени	dig +short TXT example.com	Токен склеили с другим значением; запись создана на www вместо корня; отрицательный ответ закэширован до создания записи
Работает у одних, не работает у других	Расхождение авторитативных серверов, DNSSEC	сравнение dig @ns по всем NS зоны	Зона не синхронизирована (Serial не увеличен); валидирующие резолверы отбрасывают ответ

Управление DNS-записями массово: экспорт зоны, импорт и миграция без простоя

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

Экспорт и импорт зоны

• Экспорт в формате BIND — есть у большинства DNS-провайдеров. Это обычный текстовый файл зоны, его же понимает импорт у нового провайдера.
• API провайдера — надёжнее ручного экспорта, когда зон много: позволяет выгрузить и залить записи скриптом, а заодно держать зону в системе контроля версий.
• AXFR (передача зоны) — технически самый полный способ, но у публичных провайдеров он почти всегда закрыт. Если ваш провайдер разрешает AXFR с доверенных адресов, выгрузка делается одной командой.

# выгрузка зоны через AXFR (работает, только если разрешено)
dig @ns1.example.net example.com AXFR > example.com.zone

# если AXFR закрыт — собрать снимок по известным именам
for name in @ www api mail staging _dmarc _acme-challenge; do
  n=$( [ "$name" = "@" ] && echo example.com || echo "$name.example.com" )
  dig +noall +answer "$n" A AAAA CNAME MX TXT SRV CAA
done > zone-snapshot.txt

# нормализовать и сравнить два снимка (до и после переезда)
sort zone-before.txt > a.txt
sort zone-after.txt  > b.txt
diff -u a.txt b.txt

Миграция зоны без простоя

1. Выгрузите зону у текущего провайдера и сохраните снимок вывода dig по всем известным именам — это ваш эталон для сверки.
2. Создайте зону у нового провайдера и залейте записи. NS у регистратора пока не трогайте.
3. Сверьте зоны напрямую: опросите старые и новые авторитативные серверы одними и теми же запросами и сравните вывод построчно. Расхождения ищите до переключения, а не после.
4. Проверьте DNSSEC. Если он включён — сначала снимите DS у регистратора и дождитесь истечения его TTL. Пропуск этого шага кладёт домен целиком.
5. Переключите NS у регистратора. TTL делегирования в зоне TLD обычно измеряется днями, и снизить его вы не можете — он не ваш.
6. Держите старую зону живой минимум неделю: часть резолверов будет ходить на прежние серверы, пока не истечёт кэш делегирования.

Правило переезда: старая зона выключается последней. Пока оба комплекта NS отвечают одинаково, переключение незаметно для пользователей; как только они начинают расходиться — вы получаете плавающие сбои, которые почти невозможно воспроизвести.

Мониторинг DNS-записей и алерт на изменение

DNS — единственная точка, изменение которой мгновенно уводит весь трафик домена. При этом менять записи обычно может несколько человек, а история правок есть далеко не у каждого провайдера. Отслеживать стоит как минимум:

• NS и DS — изменение этих записей означает смену контроля над доменом. Неожиданная правка здесь — повод для немедленной проверки.
• A и AAAA основных имён — подмена адреса уводит трафик и позволяет выпустить сертификат на ваш домен.
• MX — подмена почтового маршрута тише всего и опаснее всего.
• TXT с SPF, DKIM и DMARC — их снятие или ослабление открывает домен для рассылки от вашего имени.
• CAA — снятие ограничения на УЦ обычно предшествует выпуску чужого сертификата.
• Срок делегирования домена — истёкший домен отваливается целиком, независимо от того, насколько аккуратно настроены записи.

Простейший вариант — регулярно снимать эталон и сравнивать с текущим состоянием, отправляя уведомление при расхождении:

#!/bin/sh
# /usr/local/bin/dns-diff.sh — сравнение снимка зоны с эталоном
DOMAIN="example.com"
BASE="/var/lib/dns-watch/$DOMAIN.base"
NOW="/tmp/$DOMAIN.now"

{
  dig +short NS  "$DOMAIN"  | sort
  dig +short DS  "$DOMAIN"  | sort
  dig +short A   "$DOMAIN"  | sort
  dig +short AAAA "$DOMAIN" | sort
  dig +short MX  "$DOMAIN"  | sort
  dig +short TXT "$DOMAIN"  | sort
  dig +short CAA "$DOMAIN"  | sort
} > "$NOW"

if [ -f "$BASE" ] && ! diff -q "$BASE" "$NOW" >/dev/null; then
  diff -u "$BASE" "$NOW" | mail -s "DNS changed: $DOMAIN" ops@example.com
fi
cp "$NOW" "$BASE"

Запускать такой скрипт достаточно раз в 15 минут — строкой планировщика вида */15 * * * * для пользователя, у которого есть право отправлять уведомления. Готовый вариант без своей инфраструктуры — мониторинг сайта и домена: он проверяет доступность и ключевые параметры домена по расписанию и присылает уведомление при изменении.

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

• DNS Lookup — все типы записей домена в одном отчёте, с выбором резолвера и историей проверок.
• Проверка отдельной DNS-записи — точечный запрос по конкретному имени и типу, когда нужно проверить один TXT или один CNAME.
• Проверка распространения DNS — как выглядит запись с резолверов в разных регионах; ответ на вопрос «уже распространилось или ещё нет».
• MX Lookup — почтовые маршруты домена и адреса хостов, на которые они указывают.
• Проверка почтовых настроек — SPF, DKIM и DMARC вместе, с разбором причин, по которым письма попадают в спам.
• WHOIS — регистратор, срок делегирования и текущие NS-серверы домена.
• Мониторинг — регулярная проверка домена и уведомление при изменении ключевых параметров.

Частые вопросы

Сколько ждать после изменения DNS-записи?

Столько, сколько составлял TTL записи до правки, — это верхняя граница. Если TTL был 3600, максимум через час новое значение увидят все резолверы, которые обращаются к вашей зоне. «48 часов» — миф, унаследованный от смены NS-серверов, где TTL делегирования действительно измеряется днями. Проверить фактическое состояние можно через проверку распространения.

Почему запись видна через dig, но сайт всё равно открывается старый?

Между dig и браузером есть три дополнительных кэша: операционной системы, самого браузера и уже установленных соединений. Сбросьте кэш ОС, закройте вкладку, проверьте в приватном окне. Если проблема только у части пользователей — вероятно, вы забыли удалить старую A-запись.

Можно ли иметь две A-записи с разными IP?

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

Почему DKIM не работает, хотя запись добавлена?

Две причины перекрывают почти все случаи. Первая — значение обрезано на 255 символах: длинный ключ нужно вводить несколькими строками в кавычках. Вторая — не тот селектор: имя записи должно точно совпадать с тем, чем подписывает письма ваш почтовый сервис. Проверьте длину собранного значения командой dig +short TXT selector._domainkey.example.com | tr -d '" ' | wc -c.

Что такое отрицательное кэширование и почему новый поддомен «не появляется»?

Если резолвер уже спрашивал это имя и получил «такого имени нет», он запоминает отрицательный ответ на время, заданное в SOA-записи зоны (обычно 300–3600 секунд). Поэтому не стоит проверять поддомен до того, как вы его создали: собственная проверка и создаёт ту задержку, на которую потом жалуются.

Кто настраивает PTR-запись?

Владелец IP-адреса, то есть хостинг- или интернет-провайдер, а не владелец домена. Обратная зона in-addr.arpa делегируется вместе с блоком адресов. У большинства провайдеров PTR ставится в панели управления сервером, у остальных — по заявке в поддержку. Для почтового сервера PTR обязателен: без него письма уходят в спам почти гарантированно.

Что важнее проверить после переезда хостинга?

По порядку: NS у регистратора совпадают с зоной, где вы правите записи; A и AAAA указывают на новый сервер и старых записей не осталось; MX не потерялись при переносе; TXT с SPF, DKIM, DMARC и верификационными токенами перенесены полностью; CAA не мешает выпуску сертификата; DS у регистратора соответствует ключам новой зоны.

Чеклист по работе с DNS-записями

• Проверил, куда делегирован домен: dig +short NS example.com — и правлю именно эту зону.
• Понимаю, что означает поле «Имя» в моей панели: пусто и @ — корень, www — поддомен, FQDN писать не нужно.
• На корне домена стоят A/AAAA или ALIAS, но не CNAME.
• На каждом имени с CNAME нет других записей.
• MX указывают на имена хостов с A-записями, не на CNAME и не на IP; в FQDN не потеряна точка.
• Ровно одна TXT-запись с v=spf1, без лишних пробелов, в пределах 10 DNS-запросов.
• DKIM опубликован под правильным селектором и не обрезан на 255 символах.
• DMARC заведён на _dmarc, начат с p=none и адресом rua для отчётов.
• Верификационные TXT-записи не удалены после прохождения проверки.
• Перед правкой TTL снижен заранее, а не в момент изменения.
• Результат проверен у авторитативного сервера через dig @ns, а не в браузере.
• Старые A-записи и записи прошлого хостинга удалены.
• При включённом DNSSEC порядок переезда соблюдён: сначала снять DS, потом менять зону.
• Есть эталонный снимок зоны и регулярное сравнение с уведомлением об изменениях.
• Срок делегирования домена под наблюдением — истёкший домен отменяет все остальные настройки.