SOA-запись: почему ваш домен работает без сбоев

Когда заходит речь о настройке домена, всё внимание обычно достаётся A-записям, CNAME и MX. И в целом это логично: они все же отвечают за работу с сервером и почтой. Но есть запись, о которой вспоминают, только когда что-то пошло не так. Она не отвечает за отображение сайта, но если её настроить неверно, сайт может лечь целиком. Речь о SOA — Start of Authority.

Что это вообще такое

Представьте себе паспорт доменной зоны. SOA-запись — это как первая страница документа. В ней указано, кто выдал паспорт, когда и на каких условиях его нужно менять. Без этой записи зона считается недействительной. Технически DNS-сервер может содержать сколько угодно ресурсных записей, но если в файле зоны нет SOA — всё это не имеет силы. 

SOA-запись привязана к самому домену и создается автоматически в момент его регистрации. Её невозможно удалить, но можно и нужно корректировать — иначе сбоев при синхронизации не избежать.

Зачем нужна SOA-запись, если сайт открывается и без неё

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

У любого серьёзного домена есть как минимум два DNS-сервера — первичный (мастер) и один или несколько вторичных (слейвов). Вторичные сервера не должны думать. Их задача — слепо копировать информацию с мастера. Но как часто копировать? Что делать, если мастер временно недоступен? И как понять, что данные на слейве устарели и их пора удалить? На все эти вопросы отвечает именно SOA.

Можно сказать, что SOA — это свод правил, по которым живут все сервера зоны. Если эти правила невнятны, при любом сетевом сбое часть пользователей начнет попадать на старый сайт или вовсе получать ошибку, что сервер не найден.

Что хранится внутри: разбираем параметры

SOA-запись состоит из нескольких полей. Далее мы рассмотрим каждый из них подробнее. 

→ Первый параметр — Primary Name Server (MNAME). Здесь указывается главный DNS-сервер зоны. Именно с него вторичные серверы будут забирать обновления. Здесь указывается каноническое имя сервера, обычно вроде `ns1.yourhosting.com`. Важно, чтобы этот сервер действительно существовал и был доступен.

→ Второй — Responsible Person’s Email (RNAME). Это адрес администратора зоны, в котором символ «@» заменяется на точку. То есть адрес `admin@example.com` превращается в `admin.example.com`. И сделано это не просто для красоты: такой формат исключает путаницу в синтаксисе DNS-файла. На практике этот адрес используется редко, но по стандарту он должен быть рабочим на случай, если кому-то понадобится срочно связаться с владельцем домена.

Далее следует блок из пяти чисел, который иногда называют «таймингами». Это сердце SOA, и вот что скрывается за каждой цифрой.

→ Serial (серийный номер) — критичный параметр. Это версия файла зоны, обычно в формате ГГГГММДДЧЧ. Когда администратор меняет любую запись в зоне, он обязан увеличить этот номер. Вторичный сервер при каждой проверке первым делом сравнивает свой Serial с тем, что на мастере. Если у мастера номер больше, то пора обновляться. Если администратор забудет поправить номер, слейв просто проигнорирует изменения, и новые A-записи никогда не станут доступными всему интернету.

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

→ Retry (повторная попытка) начинает действовать, если мастер не ответил. Это интервал, через который слейв предпримет следующую попытку достучаться. Обычно он меньше Refresh. Логика такая: если связь упала, не стоит заваливать сервер запросами, но и ждать слишком долго нельзя. Значение в 900 секунд (15 минут) встречается чаще всего.

→ Expire (истечение срока) — это время, в течение которого вторичный сервер продолжит раздавать старые данные, если мастер так и не появился. Когда этот срок истекает, слейв перестает отвечать на запросы для этой зоны. Дело в том, что в данном случае он будет считать данные безнадежно устаревшими и потенциально опасными. Здесь уместно ставить несколько недель (например, 604800 секунд, или 7 дней). Этого достаточно, чтобы пережить длительные аварии на стороне хостинга.

→ И последний — Minimum (минимальное TTL). Вопреки старому названию, сегодня это не минимальное время жизни записи. Это значение по умолчанию для негативного кеширования — на сколько секунд другие серверы запомнят сам факт того, что какого-то поддомена не существует. Это помогает не закидывать мастер-сервер запросами к несуществующим именам вроде `random123.yourdomain.com`.

Как редактировать SOA, ничего не сломав по дороге

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

Первое правило — будьте внимательным при заполнении Serial. Каждое изменение в зоне должно сопровождаться увеличением этого числа. Люди часто забывают это сделать при ручной правке файла на сервере. 

Второе правило касается таймингов. Не стоит ставить слишком агрессивные значения. Указав Refresh в 60 секунд, вы заставите десятки вторичных серверов каждую минуту тревожить ваш мастер. 

Третье — поле RNAME. Следите, чтобы там стоял реальный адрес в правильном формате. Некоторые регистраторы доменов могут отправлять уведомления о нарушениях или жалобах именно на этот контакт. Если там указан `nobody@nowhere.no`, вы рискуете пропустить важное письмо и лишиться домена.

Редактировать SOA можно через панель управления доменом у регистратора, через интерфейс хостинга или напрямую в файле зоны на сервере (обычно `/var/named/domain.com.db`). В любом случае, перед правкой сделайте резервную копию текущей записи. Это займёт десять секунд, но сэкономит часы диагностики в случае ошибки.

×××

SOA — это основа, которая не прощает ошибок при настройке. Не меняйте значения просто из любопытства, всегда увеличивайте Serial и держите контактный адрес в порядке. Тогда ваша DNS-зона будет работать как часы, даже если вы вспоминаете о ней раз в полгода.