Записи DNS для разработчиков — A, CNAME, MX, TXT и TTL, которые сделали вас ждать 48 часов

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

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

Как работает DNS на практике (30-секундная версия)

Когда браузер разрешает example.com, он спрашивает рекурсивный резолвер (обычно ваш провайдер или 8.8.8.8). Резолвер проверяет свой кэш. Если есть попадание в кэш, он возвращает сохранённый ответ. Если нет, он идёт вверх по дереву DNS — от корневых серверов → TLD-серверов (.com) → вашего домена авторитетный сервер — и сохраняет результат на время, указанное в TTL.

Каждая DNS-запись имеет тип, имя, значение и TTL. Это всё. Сложность заключается в том, чтобы понимать, какой тип делает что и как записи взаимодействуют неочевидным образом.

Типы записей, которые вы действительно будете использовать

A-запись — IP-адрес для имени хоста

Связывает имя хоста с IPv4-адресом. Это наиболее распространённый тип записи, с которым вы столкнётесь.

example.com.     300   IN  A   93.184.216.34
www.example.com. 300   IN  A   93.184.216.34

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

Для IPv6 эквивалент — это AAAA-запись. То же самое понятие, только 128-битный адрес вместо 32-битного.

CNAME-запись — алиас к другому имени хоста

Показывает одно имя хоста на другое имя хоста (а не IP). Резолвер идёт по цепочке, пока не достигнет A-записи.

www.example.com.    300  IN  CNAME  example.com.
blog.example.com.   300  IN  CNAME  mysite.netlify.app.

CNAME против A — когда использовать что: Если вы указываете на сервис, который предоставляет вам имя хоста (Netlify, Vercel, GitHub Pages, Heroku, большинство CDN), используйте CNAME. Если у вас есть статический IP, используйте A-запись. Просто.

Жёсткое правило: вы не можете размещать CNAME на вершине зоны (на базовом домене — example.com, а не www.example.com). RFC 1034 запрещает это, потому что вершина должна содержать записи SOA и NS, а CNAME на том же имени вызывает конфликт. Когда Netlify или Vercel говорят вам добавить CNAME для корневого домена, они на самом деле имеют в виду использование их DNS-провайдера, который поддерживает записи ANAME или ALIAS — проприетарное расширение, которое ведёт себя как CNAME, но разрешает A-записи на уровне зоны.

Также: никогда не используйте CNAME для CNAME если это возможно. Технически допустимо, но каждый переход в цепочке — это дополнительный запрос DNS. Более того, если промежуточная CNAME выходит из строя, ваша запись тоже выходит из строя.

MX-запись — маршрутизация почты

Указывает другим почтовым серверам, куда доставлять письма для вашего домена. MX-записи имеют приоритетный номер — чем меньше номер, тем выше приоритет.

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

Если mail1 недоступен, отправляющие серверы попробуют mail2. Это корректный механизм отказа, а не балансировка нагрузки — вы не разделяете трафик, вы устанавливаете порядок предпочтений.

Ошибку, которую совершают разработчики: указывают MX на IP-адрес или на CNAME. Значения MX должны указывать на A-записи (имена хостов), а не на IP-адреса или CNAME. Некоторые DNS-провайдеры позволяют сохранять эту неправильную настройку без предупреждения, и тогда ваша почта работает безошибочно.

Если вы устанавливаете Google Workspace или Microsoft 365, они предоставят вам набор MX-записей. Не изменяйте приоритетные номера, думая, что вы умны — логика маршрутизации почты зависит от их точности.

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

TXT-записи содержат произвольные текстовые строки. На практике они используются для трёх вещей:

• Проверка домена — Google Search Console, Stripe, GitHub и сотни других сервисов будут просить вас добавить TXT-запись, чтобы доказать, что вы владеете доменом
• SPF (Sender Policy Framework) — устанавливает, какие почтовые серверы разрешены отправлять письма от имени вашего домена
• DKIM и DMARC — записи аутентификации почты, которые предотвращают фальсификацию

SPF-запись выглядит так:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Это означает: Google и SendGrid разрешены отправлять письма от имени этого домена; всё остальное должно вызывать подозрение (~all = мягкий отказ, -all = жёсткий отказ).

DMARC-запись находится на _dmarc.example.com:

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

Важное: вы можете иметь только одну SPF-запись на домен. Если вы добавляете вторую (потому что новый сервис сказал вам это), обе записи будут существовать, почтовые серверы увидят конфликтные политики, и аутентификация почты будет нарушена. Слишьте их вместо этого: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

NS-запись — делегирование имени сервера

Указывает, какие серверы являются авторитетными для вашего домена. Обычно вы устанавливаете эти записи в вашем регистраторе домена, а не напрямую в DNS-зоне. Когда вы мигрируете с одного DNS-провайдера на другой (например, с серверов GoDaddy на Cloudflare), вы обновляете NS-записи на уровне регистратора.

Распространение NS-записей объясняет, почему миграции доменов происходят медленно. TTL-значения NS-записей часто составляют 24–48 часов, и изменения на уровне регистратора имеют собственную задержку распространения.

TTL — число, которое заставило вас ждать 48 часов

TTL (Time To Live) — это число в секундах. Оно говорит кэширующим резолверам, на сколько времени хранить ответ перед тем, как снова спрашивать. TTL в 300 означает пять минут. TTL в 172800 означает 48 часов.

Когда вы изменяете DNS-запись, старый ответ всё ещё кэшируется повсюду до истечения старого TTL. Если ваша A-запись имела TTL в 48 часов и вы только что изменили IP, некоторые пользователи могут получить старый сервер в течение двух дней — и после того, как изменение внесено, ничего не поделать.

Решение — снизить TTL до начала изменения. Стандартная практика при запланированной миграции:

1. Снизить TTL до 300 (5 минут) не менее чем за 48 часов до миграции — вам нужно подождать, пока истечёт старый высокий TTL
2. Сделать изменение DNS
3. Подождать 5–10 минут для распространения
4. Поднять TTL обратно к разумному значению (3600–86400) после того, как вы подтвердили, что новая конфигурация работает

Если вы забыли шаг 1 и сразу перешли к шагу 2 с высоким TTL, вы останетесь в ситуации. Вы можете снизить TTL сейчас, но это сокращает ожидание только для резолверов, которые ещё не кэшировали его. Любые резолверы, которые уже кэшировали запись, должны подождать до истечения оригинального TTL.

Быстрый справочник

Запись	Указывает на	Общественное использование	Проблема
А	IPv4-адрес	Имя хоста → IP-адрес сервера	Нет проверок работоспособности — неисправные IP остаются в цепочке до истечения TTL
AAAA	IPv6-адрес	Имя хоста → IPv6-адрес сервера	Легко забыть добавить вместе с A-записью для поддержки дуального стека
CNAME	Другое имя хоста	Алиасы, маршрутизация через CDN/PaaS	Не может использоваться на вершине зоны; MX/NS не могут указывать на CNAME
MX	Имя хоста (A-запись)	Маршрутизация доставки почты	Значение должно быть именем хоста, а не IP-адресом; приоритетные номера важны
TXT	Произвольный текст	SPF, DKIM, DMARC, проверка домена	Разрешено только одно SPF-запись на домен — объединяйте, а не добавляйте
NS	Имя сервера имени	Делегирование DNS	Изменения проходят через регистратор и распространяются медленно
CAA	Домен CA	Какие CA могут выдавать SSL-сертификаты для вашего домена	Легко заблокировать себя от обновления сертификата из-за неправильной настройки

То, что сэкономит вам время

Используйте dig напрямую, а не через веб-инструмент. dig @8.8.8.8 example.com A обходит ваш локальный резолвер и показывает ровно то, что видит Google DNS. Добавьте +short для только ответа. Добавьте +trace чтобы пройти полную цепочку разрешения.

# Check what Google sees right now
dig @8.8.8.8 example.com A +short

# Check MX records
dig @8.8.8.8 example.com MX

# Check TXT (SPF, DMARC, verification tokens)
dig @8.8.8.8 example.com TXT
dig @8.8.8.8 _dmarc.example.com TXT

# Full resolution trace
dig @8.8.8.8 example.com A +trace

Проверьте TTL перед любыми миграциями. Выполните dig example.com A и посмотрите на число в третьей колонке секции ответа. Это сколько (в секундах) вы можете ждать, если измените запись прямо сейчас, не снизив TTL сначала.

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

Вам также может понравиться