SOA-запись (Start of Authority) — обязательная DNS Lookup, которая открывает зону и хранит её административные параметры: главный NS-сервер, e-mail ответственного, серийный номер и тайминги обновления. Вторичные серверы читают её serial, чтобы понять, изменилась ли зона, и запускать перенос. Одна SOA на зону.
Статья разбирает все семь полей SOA по RFC 1035, формат serial YYYYMMDDnn, роль minimum как negative TTL по RFC 2308, связь с зонными трансферами primary/secondary, команды проверки через dig и типичные ошибки вроде незабытого инкремента serial. Материал для администраторов доменов и DevOps.
Что такое SOA-запись
SOA (Start of Authority, «начало зоны полномочий») определена в RFC 1035 как первая запись в файле зоны. Она объявляет, что данный сервер является авторитетным для зоны, и задаёт глобальные параметры её обслуживания. В каждой зоне ровно одна SOA-запись — на apex-имени (например, example.com.).
SOA невидима для обычного пользователя, но критична для инфраструктуры: именно на её основе вторичные (secondary) серверы решают, нужно ли переносить зону, а резолверы — как долго кэшировать отрицательные ответы (NXDOMAIN). Ошибка в SOA не «ломает» сайт мгновенно, но приводит к рассинхронизации серверов и медленному распространению изменений.
Поля SOA-записи
SOA состоит из двух имён (MNAME, RNAME) и пяти числовых таймеров. В классической записи это выглядит одной логической строкой, разбитой скобками для читаемости.
MNAME — главный сервер имён
Полное доменное имя первичного (master/primary) NS-сервера зоны — источника истины, откуда вторичные тянут данные. MNAME также используется в механизме DNS NOTIFY: именно этот сервер рассылает уведомления об изменениях. Важно, чтобы MNAME указывал на реально авторитетный сервер, иначе NOTIFY не сработает.
RNAME — e-mail администратора
Контакт ответственного за зону, записанный в DNS-формате: символ @ заменён на точку. Так hostmaster.example.com. означает адрес hostmaster@example.com. Если в локальной части адреса есть точка, её экранируют обратным слэшем. Держите этот ящик рабочим — на него шлют уведомления о проблемах.
Serial — серийный номер
32-битное целое, версия зоны. Каждое изменение файла зоны должно увеличивать serial. Вторичный сервер сравнивает свой serial с serial первичного: если у первичного число больше — запускается перенос. Если serial забыли увеличить, вторичные считают зону неизменной и остаются со старыми данными.
Refresh, Retry, Expire, Minimum
Четыре таймера управляют жизненным циклом переноса зоны и кэширования. Refresh — как часто вторичный проверяет serial; Retry — пауза перед повтором после неудачи; Expire — когда вторичный признаёт данные протухшими и перестаёт отвечать; Minimum — TTL отрицательного кэширования по RFC 2308.
| Поле | Назначение | Типичное значение |
|---|---|---|
| MNAME | Первичный NS-сервер (источник зоны) | ns1.example.com. |
| RNAME | E-mail админа в DNS-формате | hostmaster.example.com. |
| Serial | Версия зоны, растёт при каждом изменении | 2026071301 |
| Refresh | Интервал проверки serial вторичным | 7200 (2 ч) |
| Retry | Пауза перед повтором после сбоя | 3600 (1 ч) |
| Expire | Срок жизни данных без связи с primary | 1209600 (14 дн) |
| Minimum | TTL отрицательного кэша (NXDOMAIN) | 3600 (1 ч) |
Формат serial: YYYYMMDDnn
Serial — просто растущее число, но на практике почти все используют дату: YYYYMMDDnn, где nn — счётчик правок за день. Например, 2026071302 — вторая правка 13 июля 2026 года. Такой формат читаем, монотонно растёт и переживает несколько правок в сутки.
Главное правило — serial должен строго увеличиваться. Учтите арифметику serial по RFC 1982: значение 32-битное и «заворачивается». Уменьшение serial (например, откат к «вчерашней» дате) вторичные могут воспринять как отсутствие изменений и не обновиться.
Пример SOA-записи
$TTL 3600
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2026071301 ; Serial (YYYYMMDDnn)
7200 ; Refresh — 2 часа
3600 ; Retry — 1 час
1209600 ; Expire — 14 дней
3600 ) ; Minimum — negative TTL 1 час
SOA и зонные трансферы
SOA — двигатель репликации между первичным и вторичными серверами. Схема стандартного цикла:
- Первичный сервер меняет зону и увеличивает serial.
- По NOTIFY (или по истечении Refresh) вторичный запрашивает SOA первичного.
- Вторичный сравнивает serial: если у первичного больше — запускает AXFR (полный) или IXFR (инкрементальный) перенос.
- Если первичный недоступен, вторичный повторяет попытки каждые Retry секунд.
- Если связи нет дольше Expire, вторичный перестаёт считать себя авторитетным и отвечает SERVFAIL.
Поэтому Expire всегда должен быть заметно больше Refresh и Retry — иначе при коротком сбое первичного вся зона «протухнет» на вторичных.
Как проверить SOA-запись
Самый быстрый способ — утилита dig. Она покажет все поля SOA и текущий serial, чтобы сверить его между серверами.
# Краткий вывод SOA
dig SOA example.com +short
# Полный вывод с секцией ANSWER
dig SOA example.com
# Проверить serial напрямую на конкретном сервере
dig @ns1.example.com SOA example.com +short
Через браузер без установки утилит воспользуйтесь нашим DNS-инструментом: введите домен, выберите тип SOA и сравните serial и тайминги. Полезно опросить каждый авторитетный сервер отдельно и убедиться, что serial везде совпадает.
Частые ошибки
- Serial не увеличен. После правки зоны забыли поднять число — вторичные не видят изменений и остаются на старых данных. Самая частая причина «изменения не применились».
- Serial уменьшен. Ручная правка с меньшим числом или откат даты — вторичные игнорируют перенос из-за арифметики RFC 1982.
- Expire меньше Refresh. При коротком сбое первичного зона протухает у вторичных и сайт отдаёт SERVFAIL.
- Слишком большой Minimum. Долгий negative-кэш означает, что удалённые по ошибке записи «висят» как NXDOMAIN у резолверов.
- Неверный RNAME. Забытая замена
@на точку или нерабочий ящик — уведомления о проблемах теряются.
Больше о структуре зоны — в статьях типы DNS-записей, руководство по TTL и NS-запись. Спецификации: RFC 1035, RFC 2308, MDN: DNS.
Частые вопросы
Сколько SOA-записей может быть в зоне?
Ровно одна. SOA обязана быть первой записью в файле зоны и располагаться на apex-имени домена. Наличие двух SOA — синтаксическая ошибка, зона не загрузится. Все административные параметры зоны хранятся в этой единственной записи, поэтому дублировать её нельзя ни при каких настройках.
Что произойдёт, если не увеличить serial?
Первичный сервер применит изменения, но вторичные серверы, сравнив serial, решат, что зона не менялась, и не запустят перенос. В результате часть резолверов получит новые данные с primary, а часть — старые с secondary. Всегда увеличивайте serial при каждой правке зоны.
Чем Minimum отличается от TTL записи?
TTL записи управляет кэшированием положительных ответов. Поле Minimum в SOA по RFC 2308 задаёт TTL отрицательного кэширования — как долго резолвер хранит ответ NXDOMAIN (домен не существует). Это разные механизмы: один ускоряет доступ, другой ограничивает повторные запросы к несуществующим именам.
Как выбрать значения таймеров SOA?
Ориентируйтесь на скорость обновлений и надёжность связи. Refresh 1–4 часа, Retry 15 минут–1 час, Expire 1–4 недели (всегда больше Refresh), Minimum 5 минут–1 час. При частых правках зоны и работающем NOTIFY Refresh можно увеличивать — уведомления запускают перенос без ожидания таймера.
Как быстро посмотреть serial своего домена?
Выполните dig SOA example.com +short — serial будет третьим числом в выводе. Чтобы сверить синхронизацию, опросите каждый авторитетный сервер отдельно через dig @nsX .... Без командной строки то же самое доступно в браузерном DNS-инструменте enterno.io.