DNS-записи домена: A, MX, TXT и NS простыми словами

DNS-записи домена - это короткая таблица, по которой интернет узнаёт, где у вашего домена сайт, куда доставлять почту и кому разрешено слать письма от вашего имени. Сайту нужна одна запись типа A с адресом сервера. Почте нужны запись MX и три текстовые записи для проверки отправителя. Остальное добавляется по мере надобности.

Таблица маленькая, правят её раз в год, и поэтому её никто не помнит. Отсюда типовая авария: при переезде на новый хостинг меняют "настройки домена", сайт открывается, все довольны, а через три дня выясняется, что всё это время не приходила почта. Ниже карта записей, порядок безопасной правки и команды, которыми можно проверить свой домен за пять минут.

Одна правка, после которой замолчала почта#

Сценарий собирательный, и узнать в нём себя может половина компаний, которые хоть раз меняли хостинг.

Компания переносит сайт к новому хостеру. В его инструкции первым пунктом стоит: "укажите у регистратора наши NS-серверы". Менеджер заходит в личный кабинет регистратора и указывает. К вечеру пятницы сайт открывается с нового сервера, задача закрыта.

В понедельник бухгалтер замечает, что с четверга нет писем от клиентов. В спаме пусто. Письма не терялись по дороге: их некуда было доставлять.

Что произошло. Вся таблица записей домена лежала на серверах старого хостера, и среди прочего в ней была запись, которая говорила, какой сервер принимает почту. Сменив NS-серверы, менеджер не перенёс сайт. Он сказал интернету: "теперь таблицу домена спрашивайте в другом месте". А в другом месте новый хостер автоматически создал свежую таблицу, в которой была запись для сайта и больше ничего полезного. Отправителям три дня уходили отказы.

Чтобы так не вышло, достаточно понимать две вещи: какие записи бывают и чем правка одной записи отличается от смены серверов имён.

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

Минимум для сайта: A для самого домена и запись для www, вторая A или CNAME на основное имя. Минимум для почты: MX и три текстовые записи. Это давно не пожелание: Gmail с 1 февраля 2024 года требует SPF или DKIM от любого отправителя, а Mail.ru в правилах для рассылок просит настроить все три. Зачем нужна каждая из трёх и какие значения в них писать, подробно разобрано в статье про почту на домене и письма в спаме.

Вот как выглядит зона обычного сайта с почтой на стороннем сервисе. Адреса и имена условные:

example.ru.                  A      203.0.113.10
www.example.ru.              CNAME  example.ru.
example.ru.                  MX 10  mx.mailservice.ru.
example.ru.                  TXT    "v=spf1 include:_spf.mailservice.ru ~all"
mail._domainkey.example.ru.  TXT    "v=DKIM1; k=rsa; p=MIGfMA0G..."
_dmarc.example.ru.           TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.ru"
example.ru.                  CAA    0 issue "letsencrypt.org"

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

Последняя строка таблицы с типами отличается от остальных, и о ней отдельно.

NS-записи: строка, которая меняет все остальные#

Таблица записей, её называют зоной, должна где-то лежать. Лежит она на серверах имён, и их адреса хранятся уже не у вас, а в общей зоне .ru, куда их передаёт регистратор. Это называется делегированием домена.

Отсюда два разных действия, которые в быту называют одинаково, "поменять DNS".

Правка одной записи в зоне и смена NS-серверов: что происходит с остальными записями и сколько это занимает

Поменять запись внутри зоны. Вы заходите туда, где лежит таблица, и правите одну строку: например, адрес в записи A. Остальные строки остаются как были. Почта, подтверждения прав, поддомены ничего не замечают.

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

Хостеры в инструкциях по переезду обычно предлагают второй путь, потому что им так проще: зона оказывается у них, и запись для сайта они создают сами. Вам проще первый. В статье о переносе сайта на другой хостинг у нас есть правило на этот счёт: если нет причины менять серверы имён, меняйте только A-запись.

По срокам эти действия тоже разные. Правка записи расходится за минуты или часы, о чём ниже. Смена серверов имён идёт дольше: справка Timeweb называет от 3 до 24 часов, REG.RU пишет, что обычно серверы обновляются в течение суток, а пределом называет 72 часа, у Beget в справке срок 24-72 часа. Срок жизни записей о серверах имён в самой зоне .ru, по нашему замеру 12 октября 2026 года, равен 345 600 секундам, то есть четырём суткам. У части посетителей старое значение может держаться дольше обещанного.

И одно новшество этого года. С 1 сентября 2026 года значимые операции с доменами .ru и .рф требуют подтверждения личности через Госуслуги. В перечне на сайте Координационного центра названы регистрация, продление, смена администратора или регистратора и делегирование. Уточните у регистратора, как это работает при смене серверов имён, и пройдите идентификацию заранее: в день, когда хостинг лежит и домен надо срочно увести, на это не будет времени. Что изменилось для владельцев доменов, мы писали в разборе правил с 1 сентября.

TTL: сколько интернет помнит старое значение#

У каждой записи есть срок жизни, TTL, в секундах. Это время, на которое чужие серверы запоминают ответ и не переспрашивают. TTL в 600 секунд означает, что после правки записи старое значение проживёт у посетителей до десяти минут. TTL в 86 400 секунд означает сутки.

У Timeweb срок по умолчанию как раз 600 секунд. В документации там же полезная оговорка: TTL позволяет оценить, сколько займёт обновление существующей записи, но "не влияет на скорость применения новых DNS-записей или обновления NS-серверов домена".

Из этого следует простой приём. Перед плановой правкой, за сутки или раньше, уменьшите TTL нужной записи до 300 секунд. В день переезда новое значение разойдётся за пять минут, и если что-то пошло не так, за те же пять минут вернётся старое. После переезда TTL можно поднять обратно.

Есть и обратная сторона. Короткий TTL означает, что серверы имён спрашивают чаще, и если они недоступны, домен перестаёт находиться быстрее. Для обычного сайта это не довод держать сутки, но довод не ставить 30 секунд навсегда.

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

CNAME не уживается с соседями. Стандарт, которому почти сорок лет, требует: если у имени есть запись CNAME, других записей у этого имени быть не должно. У самого домена всегда есть как минимум записи о серверах имён, а обычно ещё и почтовая. Поэтому на example.ru поставить CNAME нельзя, а на www.example.ru можно. Об это спотыкаются, когда конструктор или сервис рассылок просит "направить домен на наш адрес через CNAME". Для самого домена им дают запись A, а некоторые DNS-хостинги предлагают свой тип записи, обычно под названием ALIAS, который обходит ограничение.

MX ведёт на имя, а не на адрес. В почтовой записи пишут имя сервера, например mx.example.ru, а не цифры. И это имя само не должно быть псевдонимом. Число рядом с именем задаёт приоритет: чем оно меньше, тем раньше сервер попробуют. Два сервера с числами 10 и 20 означают основной и запасной.

SPF бывает только один. Подключили сервис рассылок, он попросил добавить запись, и в зоне появилась вторая строка, начинающаяся с v=spf1. По стандарту это ошибка: при двух записях проверка не проходит совсем, почтовые сервисы перестают считать ваши письма подтверждёнными, и часть из них уходит в спам. Нового отправителя дописывают в существующую запись. У той же записи есть второй предел: не больше десяти обращений к другим доменам при проверке. Пять подключённых сервисов его уже могут выбрать.

Как править записи и ничего не уронить#

1. Сохраните зону до правки. Снимок экрана со всеми записями или выгрузка в файл, если панель это умеет. Через год это будет единственный документ о том, как всё было устроено.
2. Выясните, где зона лежит сейчас. Не где куплен домен и не где стоит сайт, а какие серверы имён указаны у регистратора. Команда для этого ниже.
3. За сутки до плановой правки уменьшите TTL записи.
4. Меняйте одну запись за раз и проверяйте результат. Переносите сайт - трогайте только A и AAAA.
5. Если всё же меняете серверы имён, сначала заведите на новых серверах все записи по сохранённой копии, проверьте их и только потом переключайте.
6. После правки проверьте почту руками: письмо снаружи на адрес домена и письмо с домена наружу.
7. Старую зону и старый сервер не удаляйте две недели.

Раз в год: уборка в зоне#

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

Большая часть мусора безвредна. Опасны два вида.

Первый: CNAME, который ведёт на адрес в чужом сервисе, где вашего проекта уже нет. Вы удалили страницу на конструкторе, а запись promo.example.ru по-прежнему указывает на его серверы. Если сервис позволяет другому клиенту занять освободившийся адрес, на вашем поддомене появится чужое содержимое: с вашим именем в адресной строке и, возможно, с формой для ввода паролей.

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

Раз в год пройдите по зоне с вопросом "что это и кому нужно" к каждой строке. Непонятное не удаляйте сразу: сначала сохраните копию зоны.

Как посмотреть записи своего домена#

На Mac и Linux есть команда dig. Откройте терминал и подставьте свой домен:

dig +short example.ru NS      # где лежит зона
dig +short example.ru A       # куда ведёт сайт
dig +short example.ru MX      # кто принимает почту
dig +short example.ru TXT     # SPF и подтверждения
dig +short _dmarc.example.ru TXT

В Windows то же самое делает nslookup:

nslookup -type=MX example.ru

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

Где держать зону#

Мест три: серверы имён регистратора, серверы хостера и отдельный DNS-хостинг. Базовый вариант обычно бесплатный у всех. У Selectel, например, DNS-хостинг идёт бесплатно в дополнение к другим услугам.

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

Следующая ступень: DNS-хостинг, который сам следит за сервером и подменяет запись, когда тот перестал отвечать. У российского EdgeЦентра это тариф за 600 рублей в месяц без НДС. Нужен он не всем, и как понять, нужен ли вам, посчитано в разборе резервного сервера для сайта.

Что с DNS делаем мы#

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

На поддержке ведём домен дальше: следим за сроком регистрации и сертификата, правим записи по заявкам, держим копию зоны. Разовая задача вроде "разобраться, почему письма уходят в спам" или "перенести зону к регистратору" считается по часам, 3 000 рублей за час.

Источники#

• RFC 1034: доменные имена, концепции и средства - правило о записи CNAME.
• RFC 2181: уточнения к спецификации DNS - запись MX не должна вести на псевдоним.
• RFC 7208: Sender Policy Framework - одна запись SPF на имя, предел в десять обращений.
• RFC 8659: запись CAA.
• Документация Timeweb Cloud: управление DNS-записями - TTL по умолчанию, сроки смены серверов имён.
• Справка REG.RU: DNS-серверы прописаны, а сайт недоступен и о делегировании доменных имён.
• Справка Beget: изменение NS-серверов.
• Справка Google: требования к отправителям писем и технические требования Mail.ru к рассылкам.
• Координационный центр доменов .RU/.РФ: вопросы и ответы - операции, требующие идентификации через Госуслуги.
• Документация Selectel: DNS-хостинг и EdgeЦентр: DNS-хостинг.