Soa dns что это

Обновлено: 07.07.2024

Файл зоны состоит из ресурсных записей разных типов.
Единственный поддерживаемый класс записей — IN.
Набор ресурсных записей с одинаковым типом, классом и именем (в левой части записи) называется множеством записей (RRset).
Обязательными являются записи типа SOA и NS для имени, совпадающего с названием зоны. Все остальные могут отсутствовать.
Записи состоят из различных полей (параметров).

Формат записи временных параметров

В интерфейсе редактора зон возможно указать значение временных параметров в неделях, днях, часах, минутах и секундах, используя соответствующие буквы: w — недели, d — дни, h — часы, m — минуты, s — секунды.

XXw — XX недель, XXd — XX дней, XXh — XX часов, XXm — XX минут, XXs — XX секунд (где XX — число).

В файл зоны временной параметр будет записан в секундах.

Примеры записей:
1890 — 1890 секунд;
2d5h — 2 дня и 5 часов;
3h30s — 3 часа и 30 секунд.

Параметры Default TTL, TTL, Minimum TTL

Временные параметры Default TTL, TTL, Minimum TTL определяют время TTL (Time-to-live — «время жизни»), в течение которого DNS-серверы (кроме вторичных), получившие информацию о записях с любого DNS-сервера, будут ее хранить в своей памяти (кэше) и сообщать ее по запросам других DNS-серверов.

Определяет «время жизни» (time-to-live) для конкретной записи.
Необязательный параметр. Если значение параметра в записи не указано, то «время жизни» определяется параметром Default TTL.
Рекомендуемое значение:
86400 (1d);
Диапазон допускаемых редактором DNS-master значений:
от 600 до 2147483647 секунд включительно (2 31 −1).
Записи, принадлежащие одному множеству RRrset (с одинаковым типом, классом и именем в левой части записи), должны иметь одинаковое значение TTL.

Default TTL

Определяет время TTL— «время жизни», в течение которого кэширующие DNS-серверы, получившие информацию о записях с любого DNS-сервера, будут ее хранить в своей памяти (кэше) и сообщать ее по запросам других DNS-серверов и резолверов.
Рекомендуемое значение:
86400 (1d);
Диапазон допускаемых редактором DNS-master значений:
от 600 до 2147483647 секунд включительно (2 31 −1).

Minimum TTL

Формат записи временных параметров приведен в соответствующем разделе

Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, параметры времени кэширования зонной информации и взаимодействия DNS-серверов.

В любой зоне должна быть только одна SOA-запись для имени, совпадающего с именем зоны.

Формат SOA-записи

имя [TTL] SOA Данные
имя: имя зоны
TTL: см. описание параметра TTL
SOА: тип записи

Serial number

Serial number (серийный номер) — это номер версии файла зоны. Этот номер должен быть положительным целым числом и увеличиваться каждый раз, когда в файл зоны вносятся изменения (см. RFC1982). Увеличение серийного номера показывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону.
Вы можете не увеличивать этот номер вручную, т.к. он увеличивается автоматически при сохранении файла зоны в редакторе файлов зон.
Если вы измените серийный номер так, что после сохранения файла зоны он останется неизменным или станет меньше, чем был ранее, то вторичные серверы не будут перечитывать данные с первичного сервера, т.к. будут считать, что данные не изменились.
Диапазон допустимых значений (для редактора файлов зон): от 0 до 2147483646 включительно (2 31 −2).

Временной параметр Refresh показывает, как часто вторичные серверы должны запрашивать первичный сервер, чтобы узнать, не увеличился ли Serial number(серийный номер) зоны и, следовательно, не нужно ли обновить ее у себя.
Рекомендуемое значение: от 1h до 6h.
Диапазон допустимых значений: от 30m до 4w.
Формат записи временных параметров приведен в соответствующем разделе.

Параметр Retry показывает, как долго вторичный сервер имен должен ждать, перед тем как повторить попытку запроса первичного сервера (на предмет изменений серийного номера данной зоны), если предыдущая попытка оказалась неудачной.
Рекомендуемое значение: от 20m до 60m;
Диапазон допустимых значений: от 5m до 2w.
Формат записи временных параметров приведен в соответствующем разделе.

Параметр Expire указывает верхнее ограничение по времени, в течение которого вторичный сервер может использовать ранее полученные данные о зоне до того, как они потеряют силу из-за отсутствия обновления (например, вследствие отключения первичного сервера имен на длительное время).
Рекомендуемое значение: от 1w до 1m;
Диапазон допустимых значений: не менее значения параметра Refresh и не более 1 года.
Формат записи временных параметров приведен в соответствующем разделе.

Редактирование SOA-записи

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

Затем выбрать пункт «SOA и TTL».

После чего заполнить необходимые поля и нажать кнопку «Применить».

Далее, перед выгрузкой обновленного файла зоны можно посмотреть его содержимое, для этого нужно зайти в пункт «Ресурсные записи».

Нажать ссылку «предпросмотр зоны».

В открывшемся окне проверить правильность обновляемых данных.

В данном случае SOA-запись имеет следующий вид:

Если данные верны, то нужно выгрузить зону. Для этого закройте окно с содержимым файла зоны и нажмите кнопку «Выгрузить зону».

Запись типа A позволяет установить соответствие между именем хоста в домене и его IP-адресом.

Запись типа A имеет следующий формат:
имя_хоста [TTL] A IP-адрес
имя_хоста: доменное имя хоста (устройства), подключенного к Интернету, для которого данная запись определяет соответствие с его IP-адресом.
TTL: см. описание параметра TTL
А: тип записи
IP-адрес: IP-адрес хоста.

Обращаем ваше внимание на то, что у всех записей типа А, относящихся к одному имени хоста, значение TTL должно быть одинаковым.

или

Запись типа NS имеет следующий формат:
доменное_имя [TTL] NS имя_хоста
TTL: см. описание параметра TTL
NS: тип записи
имя_хоста: доменное имя DNS-сервера.

Обращаем ваше внимание на то, что у всех записей типа NS, относящихся к одному доменному имени, значение TTL должно быть одинаковым.

Если для делегирования некоторого домена в зону внесены NS-записи, то для этого доменного имени в данной зоне не может быть других типов записей, кроме glue-записей, если они нужны (см. RFC1034).

Запись типа MX (Mail Exchange — почтовый сервер) определяет почтовый сервер — машину, которая обрабатывает почту для вашего домена.

Запись типа MX имеет следующий формат:
доменное_имя [TTL] MX приоритет почтовый сервер
TTL: см. описание параметра TTL
MX: тип записи
приоритет: определяет значение приоритетности почтового сервера. Чем меньше число, тем выше приоритет почтового сервера (0 означает самый высокий приоритет, 65535 — самый низкий). Таким образом, почтовый сервер с более высоким приоритетом является основным, а почтовые серверы с более низкими приоритетами будут второстепенными и вступят в работу в том случае, если все более приоритетные серверы по каким-либо причинам недоступны или неработоспособны.
почтовый сервер: имя почтового сервера.

или

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

Запись типа CNAME (Canonical Name — каноническое имя) позволяет присваивать хосту мнемонические имена. Мнемонические имена, или псевдонимы, широко применяются для связывания с хостом какой-либо функции, либо просто для сокращения имени.

Реальное имя иногда называют каноническим.

Если для хоста есть запись типа CNAME, которая содержит его мнемонические имена, другие записи для данного хоста должны ссылаться на его реальное (каноническое) имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они прекращают свои запросы по мнемоническому имени и переключаются на реальное имя.

Кроме того, если данное имя использовано в качестве псевдонима, то на него нельзя занести записи любого другого типа.

Т.е. недопустима конструкция вида:
domain CNAME имя_хоста
domain MX 10 почтовый сервер

Мнемонические имена полезны, например, в случае, когда имя хоста изменилось, и вы хотите разрешить пользователям, знающим старое имя, получить доступ к хосту.

Запись типа CNAME имеет следующий формат:
мнемоимя [TTL] CNAME имя_хоста
Мнемоимя: мнемоническое имя хоста
TTL: см. описание параметра TTL
CNAME: тип записи
имя_хоста: каноническое имя хоста.

или

Запись типа AAAA позволяет установить соответствие между именем хоста в домене и его IPv6-адресом.

Запись типа AAAA имеет следующий формат:
имя_хоста [TTL] AAAA IPv6_адрес
имя_хоста: доменное имя хоста (устройства), подключенного к Интернету, для которого данная запись определяет соответствие с его IPv6-адресом.
TTL: см. описание параметра TTL
АAAA: тип записи
IPv6_адрес: IPv6-адрес хоста.

Обращаем ваше внимание на то, что у всех записей типа АAAA, относящихся к одному имени хоста, значение TTL должно быть одинаковым.

или

Записи типа PTR (Pointer — указатель) служат для выполнения обратного преобразования IP-адресов в имена хостов. Для каждого сетевого интерфейса хоста рекомендуется создать запись PTR.

Примечание: Если провайдер выделил вам несколько IP-адресов из своей сети, то по поводу записей в обратной зоне вам следует обращаться к нему.

Запись типа PTR имеет следующий формат:
адрес [TTL] PTR имя_хоста
адрес: преобразованный IP-адрес хоста
TTL: см. описание параметра TTL
PTR: тип записи.

Примеры PTR-записей

или

Записи типа SRV используются для поиска серверов, обеспечивающих работу тех или иных служб в данном домене.

С подробным описанием этого типа записей вы можете ознакомиться в RFC-2782.

Запись типа SRV имеет следующий формат:

_Service._Proto.Name [TTL] SRV Priority Weight Port Target
Service: название службы (пример: ldap, kerberos, gc и другие).
Proto: протокол, при помощи которого клиенты могут подключиться к данной службе (пример: tcp, udp).
Name: имя домена, в котором размещена данная служба.
TTL: см. описание параметра TTL.
SRV: тип записи.
Priority: приоритет данного сервера. Чем меньше число, тем выше приоритет (0 означает самый высокий приоритет, 65535 — самый низкий).
Weight: относительный вес для серверов с одинаковым приоритетом. Предназначен для распределения нагрузки между серверами, для которых указан равный приоритет.
Port: порт, на котором размещена указанная служба на данном сервере.
Target: доменное имя сервера, предоставляющего данную службу.

Примеры SRV-записей

или

Запись типа TXT обычно используется для текстового описания доменного имени.

Запись типа TXT имеет следующий формат:
имя [TTL] TXT текст
имя: имя домена или хоста
TTL: см. описание параметра TTL
TXT: тип записи
текст: одна или несколько текстовых строк, каждая из которых содержит не более 255 символов.

Примеры TXT-записи:

или

При добавлении или редактировании TXT-записи в интерфейсе редактора файлов зон:

Если необходимо внести несколько текстовых строк, то они должны быть разделены переводом строки.
Если в строке ввода более 255 символов, перевод строки осуществляется автоматически после 255-го символа.
Не нужно указывать кавычки (символ ") в начале и конце текстовой строки. В файл зоны строка автоматически будет записана в стандартном для поля TXT-формате, т.е. с кавычками.
Если в текстовой строке используются кавычки, то они будут автоматически экранированы.

Просмотр существующих ресурсных записей

Для просмотра ресурсных записей необходимо выбрать домен.

Перейти в раздел «Ресурсные записи»

После этого на странице откроется таблица со списком всех текущих ресурсных записей.

Добавление новых ресурсных записей

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

Указать необходимые параметры добавляемой записи.

* Количество и набор задаваемых параметров различаются в зависимости от типа добавляемой записи

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

Маски (символ "*") в записях файла зоны

DNS резервирует специальный символ, звездочку (*), для использования в файлах зоны в качестве части маски. Звездочка сопоставляется с любым числом меток в имени, за исключением тех случаев, когда запись для имени уже существует в базе данных DNS-сервера.

Место использования маски строго определено — это может быть только первый символ в поле имени текущего домена или имени хоста, отделенный от остальных символом ".".

Символ звездочка (*) недопустим в имени домена в левой части NS-записи.

Примеры использования масок:

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Ресурсные записи

Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

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

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP и просит вернуть доменное имя.

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

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

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Запись заголовка — служебную информацию о запросе.
Запись запроса — повторяет отправленный запрос.
Запись ответа — собственно, сам ответ.
Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

При развертывании собственного сайта арендатору хостинга приходится сталкиваться с массой специфических терминов, например, с SOA (Start Of Authority), ресурсной записью о сервере, где хранится эталонная информация о домене. Термин впервые появился в спецификации RFC 1035 (1998 г.). В документе описаны стандартные, устаревшие и экспериментальные функции, позволяющие полноценно использовать систему доменов.

Что представляет собой SOA-запись

Серверы доменных имен DNS обычно настраиваются в кластеры. Базы данных в них систематически синхронизируются посредством передачи зон. Запись SOA содержит данные для управления этим процессом – это серийный номер, время кэширования информации и взаимодействия с внешними запросами. Также в ней записана контактная электронная почта и имя главного сервера идентификации доменов.

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

Критично не только наличие данных, но еще и соблюдение определенного синтаксиса. Например, в блоке временных параметров положено использовать буквы, соответствующие неделям, дням, часам, минутам и секундам (w, d, h, m и s соответственно). Формат самой SOA-записи выглядит так:

Какие параметры хранятся в SOA-записи

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

Прочитать содержимое легко любым текстовым редактором вроде Блокнота или Notepad++. Подойдут и утилиты, встроенные в файловые менеджеры.

Основные типы информации в SOA:

TTL – время в секундах, которое затрачивается на кэширование данных, передаваемых через DNS-серверы.
MNAME – имена удаленных компьютеров, где будет храниться остальная информация о доменах.
RNAME (Hostname) – контактный электронный адрес лица, ответственного за конкретную SOA-запись.
Serial Number – серийный номер базы данных зоны, меняющийся при обновлении данных (это указывает вторичным серверам на то, что пора обновить конфигурацию).
Refresh – время в секундах, отпускаемое на запрос данных у первичного DNS-сервера, чтобы определить, требуется ли обновлять информацию (не менялся ли серийный номер).
Retry – время ожидания в секундах, через которое сервер будет принимать повторный запрос при неудачной попытке считывания информации.
Expire – период в секундах, в течение которого используются ранее полученные данные от первичного DNS-сервера. По истечении срока они теряют актуальность.
Minimum TTL – период хранения данных зоны в кэше.

Перечисленных параметров достаточно, чтобы обеспечить бесперебойную связь DNS-серверов между собой. Остальная информация хранится в других типах записей: NS, A, AAAA, MX, SRV, TXT, SPF, DKIM, CNAME. Подобная классификация упрощает считывание и понимание данных, а также снижает риски сбоев из-за ошибок доступа внешних приложений.

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

Стандартный способ проверки содержимого SOA-записи – это утилита DIG (Domain Information Groper). Она работает в веб-интерфейсе на сайте хостинга, предоставляющего доступ к DNS-серверам, или устанавливается на локальный компьютер. На сайте разработчика представлены дистрибутивы под 64-разрядную Windows и Linux-совместимые системы.

Процедура проверки в веб-версии:

По желанию ставится галочка на пункте «Текстовый ответ». Тогда ниже активной формы появится актуальное содержимое записи. Если требуется узнать, через какие серверы проходят запросы и за какое время это происходит, достаточно отметить пункт «С трассировкой». Ниже отобразиться весь перечень опрашиваемых адресов с ответами серверов.

Чуть иначе работает сервис XSEO. После ввода доменного имени и нажатия на кнопку «Проверить» отобразится название сервера, откуда был получен отклик, текущий серийный номер и другие параметры, о которых шла речь выше.

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

Подробнее об SOA-записи вы можете узнать в статье Что такое ресурсные записи DNS?

Какие параметры хранятся в SOA-записи

TTL – время, в течение которого информация будет кешироваться другими DNS-серверами.

Hostname – контактный адрес лица, который отвечает за администрирование файла зоны.

Serial number – 32-разрядное число, которое содержит в себе серийный номер файла зоны. Изменяется при каждом обновлении зоны.

Refresh – время (в секундах) ожидания ответа вторичного DNS перед запросом SOA-записи с первичных серверов. По истечении данного времени вторичный DNS обращается к первичному для получения копии текущей SOA-записи. Первичный DNS-сервер выполняет этот запрос. Вторичный DNS-сервер сравнивает полученный серийный номер зоны с имеющимся. Если они отличаются, то осуществляется запрос к первичному DNS-серверу на трансфер зоны.

Retry – если сервер недоступен, то в по истечении времени (в секундах), указанного в данном параметре, сервер повторно попытается синхронизировать информацию с первичных DNS-серверов.

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

Minimum TTL – время жизни кэша для негативного ответа на запрос в зонe.

Как проверить SOA-запись

Проверка SOA-записи осуществляется с помощью утилиты dig:

Введите ваш домен, выберите тип записи SOA и нажмите проверить:

Формат SOA-записи, полученный через утилиту dig, выглядит следующим образом:

В данном материале мы обсудим одну из самых важных записей описания ресурсов "Start of Authority"(SOA). Именно эта запись определяет ту зону, к которой относятся все описания ресурсов - прочие Resource Records.

Описание зоны по традиции начинают с записи SOA (Start Of Authority). На самом деле, после 1998 года, когда появился документ RFC 2308, описание зоны начинают с директивы управления $TTL, которая задает время хранения соответствий в кэше resolver или сервера доменных имен.

Запись SOA отмечает начало описания зоны. Обычно, это первая запись описания ресурсов (Resource Record - RR). Настоятельно рекомендуется наличие одной и только одной записи типа SOA в каждом файле описания зоны, который указан в записи primary файла named.boot или в директиве zone файла named.conf.

Формат записи SOA можно представить как:

[zone] [ttl] IN SOA origin contact (serial refresh retry expire minimum)

В этой записи каждое из полей обозначает следующее:

Поле zone - имя зоны. Если речь идет о зоне, описанной в записи primary файла named.boot, то в качестве имени употребляется символ коммерческого эт - "@". В этом случае в качестве имени текущей зоны берется имя, указанное в качестве первого аргумента команды primary из файла named.boot, или имя зоны, указанное в директиве zone файла named.conf.

Поле зоны обязательно должно быть указано, иначе named не сможет привязать следующие за данной записью описания ресурсов к имени зоны. Пустое имя зоны не является допустимым.

Можно, конечно, указывать и полное имя зоны, не забывая при этом ставить на конце имени ".":

Поле ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.

Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.

Довольно часто администраторы зон, которые делегируют части своих зон другим организациям, в ультимативной форме требуют, чтобы имя primary master не совпадало с именем зоны.

Elz и Bush в RFC-2181 отмечали, что это требование повсеместно нарушается и практически является бесполезным. Кроме того, существует документ (ripe-203), в котором написано, что данное требование (отличие имени primary master сервера от имени зоны в SOA) справедливо, за исключением случая, когда доменное имя зоны связано адресной записью с IP-адресом primary master этой зоны. Для небольших зон это случается сплошь и рядом, т.к. и primary master зоны и почтовый транспортный агент и прочие сервисы в мелких организациях устанавливаются на одной и той же машине.

Требование, однако, справедливо при заполнении интерактивных форм регистрации домена, т.к. система в момент регистрации не имеет ни малейшего понятия о том, что администратор зоны напишет в файле описания зоны, т.е. гарантии того, что имя зоны и имя primary master сервера совпадают, в момент регистрации домена нет.

Поле contact определяет почтовый адрес лица, осуществляющего администрирование зоны. Данный адрес должен совпадать со значением адреса указанным в заявке на домен. Есть, однако, одна особенность при указании этого адреса. Так как символ "@" имеет особый смысл при описании зоны, то вместо этого символа в почтовом адресе используется символ ".".

Если в имени пользователя есть какие-либо особые символы, имеющие специальные значения при описании зоны, то они должны маскироваться символом обратного слэша - "\".

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

Атрибут serial - определяет серийный номер файла зоны. Если говорить проще, то в этом поле ведется учет изменений файла описания зоны. Serial - это 32-битное целое число, и ограничение по числу цифр, которое можно встретить в руководствах по BIND, на самом деле условно.

В принципе это могут быть любые числа, но чаще всего администраторы используют в качестве серийного номера год (4 позиции), месяц (две позиции), день (две позиции) и версию внесения изменений в файл описания зоны (две позиции). Таким образом эта нотация будет выглядеть как:

ГГГГММДДВВ

Итого получается 10 символов. В старых руководствах по BIND указывают максимальное значение длины этого поля 8 символов.

Важность серийного номера определяется тем, что когда вторичный(secondary) сервер обращается к первичному(primary) серверу для обновления информации о зоне, то он сравнивает серийный номер из своего кэша с серийным номером из базы данных первичного сервера. Если серийный номер из primary сервер больше, то secondary сервер обращается к primary и копирует описание всей зоны целиком, если нет, то он не вносит изменений в свою базу данных. Таким образом, когда производятся изменения в базе данных primary сервера, то значение атрибута serial в поле данных записи SOA для зоны, описание которой было изменено, должно быть увеличено. Неизменение номера - это типичная ошибка, которую совершают администраторы зон. По этой причине лучше пользоваться средствами автоматического обновления зоны.

А что делать при достижении максимально возможного порядкового номера? Вопрос гипотетический, т.к., если даже использовать в качестве серийного номера приведенную выше нотацию, то мы достигнем предельных значений серийного номера только в 4294 году (цитируем по man named для FreeBSD 4.2 -RELEASE), но все же?

На самом деле все просто: нужно начинать сначала. До BIND 9 можно было просто указать 0-ую версию описания зоны в любой момент, и потом снова начать ее увеличивать.

Любителям математики следует прочитать раздел "Цикл порядкового номера" в книге Пола Альбитца и Крикета Ли "DNS и BIND" на странице 194 (Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.). Там подробно объяснена концепция непрерывного арифметического пространства и способ перехода к младшим целым номерам от старших за два шага изменения серийного номера описания зоны. Кроме того, арифметике серийного номера посвящен отдельный документ - RFC 1982.

Атрибут refresh определяет интервал времени, после которого slave сервер обязан обратиться к master серверу с запросом на верификацию своего описания зоны. Как уже было сказано в разделе "Типы серверов доменных имен", при этом проверяется серийный номер описания зоны.

Описание зоны загружается slave сервером каждый раз, когда он стартует или перегружается. Однако, при стабильной работе может пройти достаточно большой интервал времени, пока эти события не произойдут в действительности. Кроме того, большинство систем, которые поддерживают сервис доменных имен, работают круглосуточно. Следовательно, необходим механизм синхронизации баз данных master и slave серверов.

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

Атрибут retry начинает играть роль тогда, когда master сервер по какой-либо причине не способен удовлетворить запрос slave сервера за время определенное атрибутом refresh. А если говорить точнее, то в момент наступления времени синхронизации описания зоны master сервер по какой-либо причине не отвечает на запросы slave сервера.

Атрибут retry определяет интервал времени, после которого slave сервер должен повторить попытку синхронизовать описание зоны с master сервером. Ограничения на значение этого атрибута те же, что и для атрибута refresh.

При установке этого значения во внимание следует принимать несколько факторов. Во-первых, если master сервер не отвечает, то, скорее всего, произошло что-то серьезное (отделочники вырезали часть сети, т.к. мешала красить стены, экскаватор перекопал магистраль или отключили питание в сети). Такая причина не может быть быстро устранена, поэтому установка слишком малого времени опроса просто зря нагружает сеть.

Во-вторых, если на master сервере прописано много зон, и он обслуживает большое количество запросов, то сервер может просто не успеть ответить на запрос, а очень частые запросы от slave сервера просто "подливают масло в огонь", ухудшая и без того медленную работу сервера.

Атрибут expire определяет интервал времени, после которого slave должен прекратить обслуживание запросов к зоне, если он не смог в течение этого времени верифицировать описание зоны, используя информацию с master сервера.

Обычно это интервал делают достаточно большим. Если сделать маленький интервал, то какой смысл в slave сервере? Он просто скоропостижно скончается после отключения master сервера.

В течение всего этого времени, т.е. до достижения конца интервала expire, slave сервер будет пытаться установить контакт c master сервером и обслуживать запросы к зоне.

Правда все эти соображения хороши для случая, когда просто отключится или ломается машина, на которой стоит master сервер. Если же отключится вся сеть, которая описана в зоне, а для большинства организаций так оно и есть, то slave сервер становится подобным космическому аппарату "Пионер", который путешествует во Вселенной, давно потеряв всякую связь с Землей.

Тем не менее, существует несколько причин, по которым его наличие полезно. Во-первых, различные приложения по разному реагируют на ситуацию отсутствия соединения или невозможности найти соответствие доменному имени. Во-вторых, если зона доступна, а хост в ней недоступен, то приложение гораздо быстрее прерывает свою работу. В-третьих, время положительно кэширования гораздо больше времени негативного кэширования, а это ускоряет процесс прекращения попыток соединения с неработающим хостом, т.к. не нужно находить его адрес. В-четвертых, в отключенной сети все хосты не доступны, а они принадлежат, как правило, к одному домену, а адрес его slave сервера доменных имен закэширован и сам сервер доступен, что ускоряет, по крайней мере не замедляет, проверку доступности хостов домена (подробнее см. RFC 2182).

Существуют рекомендации по установки параметров записи SOA. Например, RFC 1537 рекомендует следующие установки для серверов, отличных от тех, которые поддерживают домены верхнего уровня:

28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800; Expire 7 days
86400 ; Minimum TTL 1 day

На самом деле установить в современных серверах minimum больше 3 часов нельзя (в том смысле, что написать-то можно, работать параметр не будет). Это максимальное время негативного кэширования, согласно документации на BIND 9.

Для TLD в том же документе рекомендованы:

86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000; Expire 30 days
345600 ; Minimum TTL 4 days

Конечно, это не догма. В этом легко убедиться, посмотрев соответствующие параметры в SOA для зоны ru программой nslookup:

Для зоны com информация несколько иная:

> com.
Server: [192.5.6.30]
Address: 192.5.6.30

Для полноты картины укажем и на более поздние рекомендации. Так, например, для небольших стабильных зон в 1999 году (ripe-203) рекомендовались следующие параметры SOA:

При этом автор (Peter Koch) подробно описывает причины, по которым установлены эти значения.

Например, для refresh интервал в сутки выставлен потому, что существует динамическое обновление зоны и оповещение slave серверов о произошедших изменениях. По этой причине нет смысла ставить маленький интервал обновления базы данных slave сервера. Если оповещение отключено или используются старые версии BIND, то, видимо, нужно спуститься с небес на землю и поставить интервал поменьше, скажем часов 8 (RFC 1537) или еще меньше.

Для атрибута expire обычно указывают одну или две недели. Однако считается, что за это время серьезные проблемы с primary master не решить, следовательно, период должен быть большим, что-то порядка месяца-двух.

Peter Koch написал в 2001 году более свежие рекомендации по установке значений в записи SOA (RIPE DNS GUIDE). По факту (значениям, перечисленным в примере записи SOA) они ничем не отличаются от приведенного выше примера.

В новых рекомендациях существует важное замечание относительно значения параметра minimum. Интерпретация его значения зависит от того, поддерживает ли конкретная реализация BIND негативное кэширование. Если поддерживает и mininum - это время негативного кэширования, то следует указывать значение 3600, если не поддерживает, то - 172800.

Обратите внимание на то, что все атрибуты записи SOA определяют порядок взаимодействия master сервера и slave серверов. Исключение составляет только атрибут minimum. В данном случае речь идет о кэшировании адресов не только сервером, но системой "умного" resolver.

Дело в том, что в качестве resolver на локальной вычислительной установке выступают функции из стандартной библиотеки, которые направляют рекурсивные запросы к локальному серверу доменных имен и сами не осуществляют кэширования соответствий между именами и IP-адресами. В этом случае кэширование осуществляется локальным сервером доменных имен.

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

Таким образом, когда речь идет об атрибуте minimum, то чаще всего его описывают в контексте программы named, которая может использоваться не только как master или slave сервер, но и как кэширующий сервер. В этом случае поле ttl записи описания ресурса, директива управления $TTL и атрибут minimum задают время хранения записи описания ресурса в кэше.

Приведем еще один пример записи типа SOA:

Обратите внимание, что интервалы заданы не в секундах, а в более понятной нотации (минутах (m), часах (h), днях (d), неделях (w)).

Читайте также: