Записи SOA: Основа каждого файла зоны

Для любого пользователя Интернета само собой разумеется, что ему необходимо ввести в браузере URL сайта, чтобы попасть на желаемую домашнюю страницу. Они не замечают, что на самом деле компьютер устанавливает соединение с помощью IP-адреса. Это происходит благодаря системе доменных имен (DNS) и ее функции разрешения имен. Здесь имя домена преобразуется в необходимую последовательность чисел. Чтобы система функционировала, серверы имен должны иметь файлы зон. В свою очередь, эти простые текстовые файлы содержат многочисленные записи DNS, которые и обеспечивают работу DNS.

Самыми известными, конечно, являются записи A. Это связано с тем, что в этих записях происходит фактическое разрешение имен. Кроме того, существуют также записи PTR, которые обеспечивают обратный DNS, или записи MX для электронной почты. Но для чего предназначены записи SOA?

DNS — это децентрализованная, иерархическая система: Серверы имен предоставляют информацию не любому серверу в Интернете, а только тем, которые находятся в выделенной зоне. Для этого сервер DNS управляет файлами зон. Это простые текстовые файлы, в которых перечислены все DNS-записи зоны. Чтобы установить различные полномочия, каждый файл зоны должен содержать запись SOA. SOA расшифровывается как Start of Authority (начало полномочий). Соответственно, эта запись предоставляет информацию по ряду вопросов, например, о том, является ли вообще адресованный сервер ответственным за запрос.

Запись SOA особенно важна в случае кластеров серверов. Вместо того чтобы брать на себя нагрузку по всем запросам, запросы распределяются между различными устройствами. Для того чтобы файлы зон оставались актуальными на всех серверах, необходимо регулярно выполнять перенос зон. Для этого «ведомые» (т.е. серверы, расположенные ниже по иерархии) синхронизируют свои данные с данными «ведущего» сервера. Порядок передачи зоны регулируется записью SOA. Для этой цели данный тип записи DNS получает различные виды информации.

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

• <name>: имя зоны
• <class>: класс сети
• <type>: тип записи
• <mname>: имя мастера
• <rname>: адрес электронной почты ответственного администратора
• <serial>: инкрементный серийный номер, определяющий версию файла зоны
• <refresh>: спецификация времени, когда ведомое устройство должно запросить текущую версию ведущего устройства
• <retry>: спецификация времени, когда ведомое устройство должно снова выполнить неудачную попытку запроса
• <expire>: спецификация времени, с которого ведомый не выпускает дальнейшую информацию при отсутствии обратной связи с ведущим
• <minimum>: спецификация времени, в течение которого информация может храниться в кэше.

Первые три поля типичны для записей DNS. Имя зоны — это доменное имя в форме полного доменного имени (FQDN). Это означает, что спецификация — отличная от той, которую вы можете узнать из URL — заканчивается точкой. Причина этого в том, что FQDN показывает полную иерархическую структуру домена, в конце которой находится корневой каталог. Разумеется, он пуст, поэтому остается только разделительная точка. Вы найдете это обозначение во всех доменных именах DNS, а также в полях MNAME и RNAME.

Поле class имеет лишь историческое значение и по этой причине во многих случаях просто опускается. Когда DNS только разрабатывался, существовали также проекты Hesiod (HS) и Chaos (CH). Оба они уже устарели, поэтому в этом поле можно использовать только интернет с аббревиатурой IN. Тип относится к виду используемой записи DNS, в данном случае SOA.

MNAME также известно как primary master и указывает, какой сервер расположен над ведомым. Это делается для того, чтобы был определен сервер имен, через который подчиненный сервер должен попытаться выполнить передачу зоны. При форматировании адреса электронной почты в поле RNAME необходимо учитывать некоторые особенности. Символ @ не допускается в обозначении. Вместо него точка отделяет локальную часть (например, имя пользователя) от домена. Если в исходном адресе электронной почты перед символом @ стоит точка, то это следует обозначить обратной косой чертой ().

Серийный номер должен постепенно увеличиваться с каждым изменением, вносимым в файл зоны. Утвердились две версии. С одной стороны, простой процесс может начинаться с 1 и с каждым изменением серийный номер увеличиваться на 1. При таком варианте количество уже сделанных изменений можно считать из серийного номера.

Другой вариант — выбор формата даты: YYYYMMDDVV. В начале указывается четырехзначный год, затем месяц и день (каждый из которых занимает две позиции), а в конце указывается двухзначный номер версии. Таким образом, в этом формате можно определить дату создания версии. С каждым изменением, которое вносится в тот же день, номер версии увеличивается на единицу. На новый день порядковый номер переставляется на соответствующее место, а номер версии сбрасывается на 00.

Запись SOA заканчивается тремя-четырьмя временными характеристиками — каждая в секундах. Первое поле («Refresh») определяет промежуток времени до того момента, когда ведомый снова запросит у ведущего актуальную версию файла зоны. Если этот запрос остается без ответа, поле «Retry» определяет, когда должна быть предпринята новая попытка. Важно, чтобы эта спецификация была меньше предыдущей.

Если сервер, расположенный ниже по иерархии, не получает дальнейших ответов, третья временная спецификация («Expire») определяет, как долго еще может использоваться файл зоны, прежде чем сервер откажется от доставки информации DNS. Если сервер продолжает отправлять старые данные файла зоны клиентам, отправляющим запросы, они могут перестать быть действительными. Это может привести к проблемам с соединением и рискам безопасности.

Поле «Минимум» завершает запись. Оно соответствует времени жизни, знакомому вам по другим типам записей DNS. Оно определяет, как долго клиент может хранить запрошенную информацию в кэше, прежде чем будет отправлен новый запрос. Однако чаще всего TTL устанавливается для всей зоны с помощью директивы $TTL. Как только это сделано, нет необходимости выполнять эту процедуру отдельно для каждой записи. Имя зоны также может быть определено уже в начале файла, а затем присвоено директивой $ORIGIN.

Запись всегда появляется в начале файла зоны.

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

Эта нотация используется для предварительного определения TTL и доменного имени. Символ @ в начале записи относится к директиве происхождения. Для того чтобы вложить временные спецификации и разделить их на несколько строк, вводятся круглые скобки.

Ни один файл зоны не будет действительным без SOA-записи в начале. На практике записи SOA выглядят следующим образом:

В этом фрагменте файла зоны видно, как — для того чтобы сделать размещение более четким — мы ввели больше информации, чем просто запись SOA. Файл начинается со спецификации доменного имени (в данном случае example.org) и TTL. Затем следует запись SOA. Поскольку мы уже определили зону в директиве $ORIGIN, здесь достаточно символа @ в качестве ссылки.

Сразу после сетевого класса и спецификаций типа записи следует (условный) хозяин зоны, за которым, в свою очередь, следует адрес электронной почты администратора. Точка включается через обратную косую черту — в данном случае маскирующий символ. Затем следующий период заменяет символ @ для фактического адреса; следующий, как обычно, определяет домен верхнего уровня (TLD). С помощью скобки можно раскрыть вложенную область, которую затем можно разделить на несколько строк. Однако можно также написать все значения друг за другом и разделить их только пустыми пробелами.

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

Скобка должна быть закрыта в конце записи SOA.

Впоследствии мы также включили в пример файла зоны запись NS и запись A. Видно, что запись SOA должна быть размещена перед всеми остальными записями — но не перед директивами домена и TTL.

Если вы хотите проверить SOA-запись сайта, вы можете установить специальное программное обеспечение или просто воспользоваться веб-службой. С помощью Google Public DNS, DNS-сервера поставщика поисковых систем, проверка SOA-записи проходит быстро и гладко: Вы просто вводите соответствующий домен на сайте продукта. На следующей странице вы уже получаете результат, правда, только для записи A. Поэтому вы можете выбрать SOA в соответствующем поле и запустить другой поиск одним нажатием кнопки.

Публичный DNS также предлагает дополнительные опции: EDNS Client Subnet — функция для установления более эффективных соединений с DNS. В настоящее время ее предлагают только Google и OpenDNS. DNSSEC, в свою очередь, гарантирует, что информация, полученная через DNS, действительно исходит от отправителя. Данные, которые передаются без этих мер безопасности, теоретически могут быть манипулированы третьими лицами. Для простой проверки SOA-записи можно оставить обе опции без изменений.

Запрос выполняется в разделе «Вопрос». Результат запроса можно найти в поле «Ответ». В поле данных ответа можно узнать главный сервер, адрес электронной почты ответственного лица и временные характеристики. Что здесь заметно, так это то, что последнее значение (минимальное) соответствует спецификации TTL вплоть до секунды. Предположительно, эта секунда уже прошла, поэтому и получается минимальное расхождение.

Спецификация в пункте «тип» иллюстрирует специфическую особенность: Вместо обозначения SOA как в запросе, так и в ответе можно найти цифру 6. Организация Internet Assigned Numbers Authority (IANA) присвоила каждому типу записи DNS индивидуальное значение. Даже те типы записей, которые не используются или уже не используются, имеют свой номер. В результате получается почти бесшовный список различных типов. В этой системе записи SOA имеют номер 6.