Что такое SOA-запись в DNS?

DNS
Опубликовано

Если вы когда-нибудь изучали DNS-записи домена с помощью dig или онлайн-инструмента, вы наверняка встречали SOA-запись, не до конца понимая её назначение. Между тем это одна из самых важных записей любой DNS-зоны: она определяет, кто является авторитетом зоны, как вторичные DNS-серверы должны синхронизироваться и как долго данные остаются актуальными при недоступности первичного сервера.

Что содержит SOA-запись

SOA расшифровывается как Start of Authority. Каждая DNS-зона обязана содержать ровно одну SOA-запись. Она всегда находится на вершине зоны и включает семь отдельных полей. Вот как выглядит типичная SOA-запись:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
                          2025052901  ; Serial
                          7200        ; Refresh
                          3600        ; Retry
                          1209600     ; Expire
                          86400 )     ; Minimum TTL

Разберём каждое поле:

  • MNAME (ns1.example.com.): первичный авторитетный DNS-сервер зоны. Это сервер, к которому обращаются вторичные серверы за обновлениями
  • RNAME (admin.example.com.): email администратора зоны, но с точкой вместо @. Здесь это [email protected]. Если локальная часть содержит точку, её нужно экранировать обратным слешем (имя\.фамилия.example.com.)
  • Serial (2025052901): номер версии зоны. Каждое изменение должно увеличивать этот номер, иначе вторичные серверы не обнаружат обновление. Распространённый формат YYYYMMDDNN (дата плюс дневной счётчик)
  • Refresh (7200): интервал в секундах между проверками вторичных серверов. Здесь каждые 2 часа
  • Retry (3600): время ожидания перед повторной попыткой, если проверка Refresh не удалась. Здесь 1 час
  • Expire (1209600): время, по истечении которого вторичный сервер перестаёт отвечать за зону, если не может связаться с первичным. Здесь 14 дней. После этого вторичный считает свои данные устаревшими и прекращает обслуживание зоны
  • Minimum TTL (86400): с RFC 2308 это поле определяет, как долго кэшируются отрицательные ответы (NXDOMAIN). Здесь 24 часа. Если кто-то запросит несуществующий поддомен, резолвер сохранит ответ "не существует" в кэше на 24 часа

Почему серийный номер так важен

Serial — вероятно, поле, вызывающее больше всего проблем на практике. Когда вторичный сервер обращается к первичному при очередном Refresh, он сравнивает свой локальный серийный номер с номером на первичном. Если у первичного номер выше, вторичный запускает передачу зоны (AXFR или IXFR) для обновления. Если номер не изменился, ничего не происходит.

Классическая ошибка: изменить DNS-запись на первичном сервере, не увеличив serial. В результате первичный имеет правильную версию, но вторичные продолжают отдавать старую часами или даже днями. Пользователи получают разные ответы в зависимости от сервера, и проблему сложно диагностировать, если никто не додумается проверить SOA.

Формат YYYYMMDDNN — условность, а не обязательство. Serial — 32-битное целое, так что любое значение от 0 до 4 294 967 295 работает. Но формат даты рекомендован, потому что делает ошибки заметными: serial 2025052901 — очевидно первое изменение 29 мая 2025 года.

Как взаимодействуют Refresh, Retry и Expire

Эти три значения образуют систему отказоустойчивости для DNS-зон. Refresh задаёт нормальный ритм синхронизации. Retry вступает в действие при сбое. Expire — последний рубеж: по истечении этого времени без связи с первичным вторичный предпочтёт вообще не отвечать, чем отдавать потенциально устаревшие данные.

Для стандартного домена RFC 1912 рекомендует:

  • Refresh: 3 600 до 86 400 секунд (от 1 часа до 24 часов)
  • Retry: 600 до 3 600 секунд (от 10 минут до 1 часа)
  • Expire: 1 209 600 до 2 419 200 секунд (от 2 до 4 недель)
  • Minimum TTL: 3 600 до 86 400 секунд (от 1 часа до 24 часов)

Если зона меняется часто (например, CDN или инфраструктура с динамическим балансированием), снизьте Refresh до 300 или 600 секунд. Если зона стабильна, 86 400 прекрасно подходит и снижает нагрузку на первичный сервер.

Как просмотреть SOA-запись домена

В Linux и macOS удобнее всего команда dig:

dig SOA example.com

В Windows используйте nslookup:

nslookup -type=SOA example.com

Ответ покажет все семь полей SOA. Обратите особое внимание на serial: если он выглядит старым или застывшим, это часто объясняет, почему DNS-изменения не распространяются корректно.

Частые ошибки в SOA

Несколько проблем, которые встречаются регулярно на практике:

  • В RNAME используется @ вместо точки, что ломает синтаксис. [email protected] в SOA должен записываться как admin.example.com.
  • Serial случайно уменьшается после восстановления из резервной копии. Вторичные серверы откажутся синхронизироваться, пока serial первичного не превысит их локальное значение
  • Expire установлен слишком коротким (несколько часов). Если первичный упадёт на выходных, вторичные перестанут отвечать до того, как кто-то сможет вмешаться
  • Minimum TTL равен 0, то есть резолверы не кэшируют отрицательные ответы. Каждый запрос к несуществующему поддомену вызывает полный round trip, что может перегрузить ваши DNS-серверы при сканировании или атаке
SOA-запись редко правят первой при настройке домена, но именно она часто объясняет, почему "DNS не распространяется". Прежде чем искать сложные причины, проверьте, что serial был правильно увеличен и что значения Refresh и Expire соответствуют вашему сценарию использования.