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

DNS-сервер, отвечающий за имена хостов в своей зоне, должен хранить информацию о хостах в базе данных и выдавать ее по запросу других устройств. База данных DNS представляет собой текстовый файл, состоящий из исходных записей RR (resource records). Эти записи описывают компьютеры и их функции в локальной зоне. Для организации обмена информацией с удаленными серверами DNS должно быть запущено программное обеспечение сервера DNS (обычно это программа named).

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

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

SOA

Start of Authority [SOA] - Учетная запись Начала Ответственности [SOA]– Отмечает начало зоны, является первой записью в файле зоны. Каждая Зона содержит одну учетную запись SOA, которая поддерживает следующие возможности для каждой Зоны:

Primary DNS Server (origin) (Имя первичного DNS сервера)

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

Mailbox of the Responsible Person (contact) (Почтовый ящик ответственного лица) Указывает адрес электронной почты лица, ответственного за содержание Зоны. Хорошая практика - указывать здесь должностной адрес (hostmaster, root, admin ...), а не адрес конкретного человека. Правило преобразования contact в адрес: первая слева точка заменяется знаком (@).

Serial Number (serial) (Серийный номер)

Используется вторичными DNS серверами для проверки изменений Зоны. Если номер Serial Number выше, чем у вторичных DNS серверов, то автоматически будет произведен перенос Зоны. При совершенных изменениях в Зоне или ее учетных записях это число автоматически возрастет. Может строиться по любым правилам, но обязательно должно увеличиваться при каждом изменении файла зоны.

Лучше всего использовать формат: YYYYMMDDXX (год, месяц, день, номер изменения зоны за текущий день). Этот порядковый номер используется при передаче информации от основного (primary) к вторичным (secondary) серверам.

Вторичный сервер запрашивает у основного SOA-запись и сравнивает порядковый номер зоны, которая хранится на вторичном сервере, с порядковым номером зоны основного сервера. Если номер на основном сервере больше (т.е. вторичный сервер содержит уже устаревшую информацию), вторичный сервер запрашивает передачу всего файла зоны (zone transfer). Пример: 19990110001

Refresh Interval(refresh) (Интервал обновлений) - интервал времени между опросами вторичных серверов.

Показывает, как часто вторичные DNS сервера проверяют, были ли совершены изменения в Зоне. Каждые "refresh" секунд вторичный сервер проверяет порядковый номер SOA. Величина, указанная в refresh, должна отражать реальную частоту обновления зоны. Для более стабильных зон можно указывать большие значения refresh.

Рекомендуемое значение: 8-24 часа (28800 - 86400)

Пример:

86400 ; refresh (1 day)

Retry Interval (retry) (Интервал повторных попыток)

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

Рекомендуется: час (3600) или два (7200).

Пример:

7200 ; retry (2 hour)

Expire Interval (expire) (Интервал окончания действия)

• сколько времени вторичный сервер должен хранить информацию о зоне, если основной сервер недоступен, т.е. как долго зона была доступна после обновления. По истечении этого срока, вторичный сервер отмечает, что его ответы не являются достоверными (non-authoritative answer). Как правило, это достаточно большая величина: 3600000 - 42 дня.

Пример:

1209600 ; expire (14 days)

Вторичные серверы автоматически удалят Зону, если в ней не было обновления в данном промежутке времени.

Minimum (default) TTL (minimum)

Используемое по умолчанию TTL для новых учетных записей, создаваемых вне Зоны. Сколько времени нужно хранить запись в кэш-памяти любого name-сервера, который запрашивает информацию о домене. После этого информация устаревает и name-сервер должен будет послать запрос на один из авторитетных серверов (primary, secondary).

Minimum TTL

Должно соответствовать средней частоте изменений в зоне, но не более 345600 (4 days).

TTL (time to live) - определяет время актуальности данных при кешировании запросов (значение TTL задает длину промежутка времени, используемого другими серверами DNS для определения длительности кэширования информации для этой записи, после чего эта информация будет уничтожена как устаревшая.). Задается в секундах. Если TTL составляет 86 400 секунд, т.е. 24 часа, это означает, что при изменении записи DNS, вплоть до 24 часов после изменения DNS-серверы по всему миру могут выдавать старые данные из кеша, пока он не будет обновлён. Именно это значение может уменьшить или увеличить ненужный DNS-трафик к авторитетному name-серверу. Если вы меняете записи, лучше установить minimum меньше, чтобы устаревшая информация не оставалась в сети. Для достаточно стабильной зоны значение minimum выбирайте в пределах нескольких дней.

Выбирамые значения TTL: На выбор TTL: 900 (15 м) 3600 (1 ч) 10800 (3 ч) 21600 (6 ч) 43200 (12 ч) 86400 (24 ч) 259200 (72 ч)

NS

Запись NS (name server) указывает на DNS-сервер для данного домена. Записи типа NS (Name Server - cервер имен) описывают authoritative DNS-серверы для домена. Количество записей типа NS в файле зоны должно точно соответствовать количеству DNS-серверов, обслуживающих домен и включать все DNS-серверы, указанные в домене. Запись NS используется для обозначения сервера, который поддерживает описание зоны.

A

Запись A (address record) или запись адреса связывает имя хоста с адресом IP.

Например, запрос A-записи на имя imena.ua вернет его IP адрес — 195.39.196.42 Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес — 2001:7fd::1

MX

Запись типа MX (Mail Exchange - почтовый сервер) определяет почтовый сервер - машину, которая обрабатывает почту для домена. Приоритет: определяет значение приоритетности почтового сервера. Чем меньше число, тем выше приоритет почтового сервера (0 означает самый высокий приоритет, 65535 - самый низкий). Почтовый сервер с более высоким приоритетом является основным, а почтовые серверы с более низкими приоритетами будут второстепенным и вступят в работу в том случае, если все более приоритетные серверы по каким-либо причинам недоступны или неработоспособны.

CNAME

Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя. Записи CNAME позволяют дать машинам удобные или значащие имена. CNAME удобно использовать, если вы меняете имя машины, но хотите оставить доступ для клиентов, которые помнят старое имя.

Особенности данного типа записи:

• CNAME нельзя использоваться для самого домена (@).
• При использовании CNAME для какого-либо субдомена создать для него запись другого типа (А, ТХТб др.) невозможно.

TXT

TXT - комментарии или какая-то другая информация Текстовые ресурсные записи. Использование: Технология SPF (Sender Policy Framework) является одним из способов идентификации отправителя электронного письма и предоставляет дополнительную возможность фильтрации потока почты на предмет наличия в нём спаммерских сообщений. С помощью SPF почта разделяется на "разрешенную" и "запрещённую" относительно домена получателя или отправителя.

SRV

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

Формат SRV записи следующий:

_Service._Proto.domain.tld. TTL_number IN SRV priority_number weight_number port_number host_name

Описание полей:

Service: название службы (пример: ldap, kerberos, gc и другие) Proto: протокол, при помощи которого клиенты могут подключиться к данной службе (пример: tcp, udp) Name: имя домена, в котором размещена данная служба TTL: определяет "время жизни" для конкретной записи. Необязательный параметр. Если значение параметра в записи не указано, то "время жизни" определяется параметром Default TTL. SRV: тип записи Priority: приоритет данного сервера. Чем меньше число, тем выше приоритет (0 означает самый высокий приоритет, 65535 - самый низкий) Weight: относительный вес для серверов с одинаковым приоритетом. Предназначен для распределения нагрузки между серверами, для которых указан равный приоритет. (Частота обращения клиента к серверам с одним приоритетом должна быть пропорциональна весу сервера. Если установить на двух серверах вес 5, то каждый получит 50% обращений (равномерная нагрузка)) Port: порт, на котором размещена указанная служба на данном сервере Target: доменное имя сервера, предоставляющего данную службу

PTR

PTR - преобразование IP-адреса в имя (прописывает владелец ip)

С помощью обратных доменов (обратных зон) IP-адреса преобразуются в имена хостов. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена.

Формат записи PTR:

IN-ADDR name [TTL] [ class ] PTR name Внимание!! Трансляция IP-адресов в домен находится в ведении провайдера и именно провайдер делегирует (или не делегирует) права на ведение реверсной зоны.