Что такое SOA-запись: полномочия DNS-зоны простыми словами

SOA означает Start of Authority (начало полномочий). SOA-запись — обязательная DNS-запись в корне зоны, несущая административные и временные сведения об этой зоне. Она указывает имя первичного сервера имён, поле ответственного лица, серийный номер и несколько таймеров, которые используют вторичные авторитативные серверы. Она не возвращает IP-адрес сайта и не является общим сертификатом состояния. Администраторы и диагностические инструменты изучают данные SOA, чтобы понять, как версионируется зона и как вторичные серверы узнают, когда проверять обновления. Её значения — это эксплуатационные метаданные, которые должны согласовываться с моделью управления DNS-провайдера.

Поля SOA-записи

Типичная SOA-запись содержит MNAME, называющий первичный исходный сервер в модели зоны, и RNAME, кодирующий контактные данные администратора зоны. Она также содержит серийный номер, интервалы обновления (refresh), повтора (retry) и истечения (expire) и значение TTL негативного кеширования. Точное отображение зависит от инструмента, а управляемый провайдером DNS может скрывать часть полей или вести их автоматически. RNAME использует синтаксис DNS, а не обычное написание адреса электронной почты; традиционно первая неэкранированная точка обозначает знак «@». Большинству пользователей не нужно править эту запись вручную, но она может пригодиться при расследовании делегирования или синхронизации.

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

SOA и негативное кеширование

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

• Изучайте SOA, когда нужны сведения о полномочиях на уровне зоны или серийном номере.
• Используйте записи NS, чтобы увидеть, какие серверы имён делегированы для домена.
• Для вопросов об адресах используйте A и AAAA; SOA не является адресной записью.
• Сравните авторитативные серверы, прежде чем считать, что различие серийных номеров указывает на сбой.
• Не меняйте управляемые провайдером поля SOA, не понимая их эксплуатационного эффекта.

Когда полезен SOA-запрос

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

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

Не правьте значения SOA наугад

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