Система доменных имен. DNS серверы. Иерархическая структура DNS. Отображение доменных имен в сетевые адреса и обратно

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

Каждая ресурсная  запись состоит из следующих полей:

- имя (NAME) - доменное имя, к которому привязана или которому "принадлежит" данная ресурсная запись,

- TTL (Time To Live) - допустимое время хранения данной ресусной записи в кэше неответственного DNS-сервера,

- тип (TYPE) ресурсной записи - определяет формат и назначение данной ресурсной записи,

- класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети,

- длина поля данных (RDLEN),

- поле данных (RDATA), формат и содержание которого зависит от  типа записи.

Наиболее важные типы DNS-записей:

- Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес — 192.0.34.164. Эта запись содержит цифровой IP адрес ассоциированный с именем.

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

- Запись CNAME Canonical Name (каноническое имя) (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя. Эта запись содержит каноническое имя (FQDN с которым ассоциируется запись A) хоста с которым объединяется эта запись. Этот тип записи используется для предоставления псевдонимов имен, для осуществления ссылки на другое имя которому соответствует другая RR. Если имя имеет запись CNAME относящуюся к нему, она образует псевдоним и другие RR не смогут использовать то же самое имя.

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

- Запись MX (mail exchange) или почтовый обменник  указывает  сервер(ы) обмена почтой для данного домена.

- Запись NS (name server) сервер имен, указывает на DNS-сервер для данного домена. Запись этого типа используется для  делегирования  поддеревьев пространства доменных имен другому серверу имен. Запись содержит FQDN сервера имен DNS с информацией о поддомене и связанным с поддоменом. Таким способом устанавливается иерархическая структура DNS.

- Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Эта запись содержит текстовое имя. Эти записи объединяют имена, встроенные в специальные пути от цифрового IP адреса и используются для предоставления обратного преобразования из IP в текстовое имя.

Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста. Например, (на момент написания), для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

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

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

- Запись SRV (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.

- MX: Mail eXchange (почтовый обменник). Эта запись содержит FQDN хоста, разрешающего SMTP электронной почты для именованного домена, вместе со значением приоритета, используемого для выбора хоста MX при передаче почты. Это используется для определения других серверов, которые доставляют и буферизируют почту, если в данный момент главный MX недоступен. Также это используется для прямой доставки почты на центральный сервер, а не к каждой рабочей станции.

- HINFO: Host Information (информация о хосте). Содержит две строки, предполагающих описание аппаратного обеспечения и операционной системы платформы. Здесь определяются настройки для использования на некоторых системах, но их использование не обязательно. Некоторые сайты, из соображений безопасности, не публикуют эту информацию.

- TXT: Text (текст). Свободное текстовое поле, иногда заполняются сепецифичными для сайта дополнительными данными, в дальнейшем интерпретируемые локальными соглашениями.

2.4 Делегирование

Использование записей NS, управляет разделением пространства имен DNS между разными точками в дереве посредством делегирования и следующие подразделы в них делегируются вновь. Этот нюанс в различии между доменами и зонами очень важен. Любое имя в DNS называется доменом и срок обновления для этого имени и для всех подчиненных имен за ним един для дерева. Ограничение зоны сужает полномочия и определяется делегированием. Зона начинается с делегирования (или из корня) и охватывает все имена в домене после этой точки, за исключением имен в следующих вложенных делегированиях.

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

2.5 Делегирование множеству серверов

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

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

2.6 Вторичность, кэширование и SOA запись

В порядке поддержки согласованности между этими серверами, один обычно настраивается как первичный (primary) сервер и все административные изменения производятся на этом сервере. Остальные сервера настраиваются как вторичные (secondary) и передают содержание первичных. Эта операционная модель не обязательна, но по некоторым соображениям это бывает необходимо, вместо этого можно использовать несколько первичных, но тогда согласованность должна поддерживаться другим способом. Серверы имен, которые содержат записи RR для определенной зоны, какими бы они не являлись, первичными или вторичными, считаются авторитетными по этой зоне. Сервер DNS может быть авторитетным для нескольких зон.

Когда сервера имен получают ответ на запрос, они могут  кэшировать  результаты. Это значительно увеличивает полезную скорость запросов, уменьшая загрузку сети и серверов имен верхнего уровня. Так как эта процедура - главный пользователь памяти процесса сервера имен.

Здесь перечислим некоторые  параметры, необходимые для поддержки  содержимого вторичных серверов и кэшей. Значения этих параметров для конкретного файла доменной зоны содержатся в записи SOA. Это поля:

Поля записи SOA

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

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

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

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

- TTL (Время жизни). Это поле определяет время, в секундах, в течение которого запись ресурса этой зоны остается действительной в кэше других серверов. Если данные изменяются, это значение должно быть маленьким. TTL это часто используемая аббревиатура, расшифровываемая как «Time To Live» (время жизни).

2.7 Разрешение имен

Клиенты DNS настраиваются  на адреса DNS серверов. Обычно, это авторитетные серверы домена, членами которого они являются. Все запросы разрешения имен начинаются с запроса к одному из этих локальных серверов. Запросы DNS бывают двух форм:

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

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

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

2.8 Обратное разрешение

DNS предоставляет разрешение  имен в записи ресурсов, также  как запись A с IP адресом. Это  не предоставляет возможностей  полного поиска совпадения в  обратном направлении и это  не механизм запроса "какое  имя относится к соответствующей RR".

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

Это достигается следующим  образом:

- Обычное доменное имя, зарегистрированное и определенное исключительно для отображения IP адресов. Доменное имя использует «in-addr.arpa.» в котором отражено историческое начало Интернет в государственной программе исследования прогрессивных проектов министерства обороны США (Advanced Research Projects Agency).

- Этот домен разделяется и делегируется в соответствии со структурой IP адресов. Часто IP адреса записываются в четырехчисловом с точками виде, где каждый октет из 4-х октетного адреса записан в десятеричной системе и отделен точками. Диапазон IP адреса обычно делегируется из самой левой части адреса и часто очень небольшой. Таким образом, чтобы позволить простое делегирование обратного просмотра домена, все происходит наоборот, когда используется иерархическое пространство имен DNS, в котором домены более высокого уровня находятся в правой части имени.

- Каждый байт IP адреса записывается как текст ASCII, представляющий цифры в десятеричной системе, с обратным порядком октетов, разделенных точками и добавленным в конце доменным именем in-addr.arpa.. Например, чтобы описать имя хоста в сети, который имеет IP адрес 11.22.33.44 согласно этому алгоритму получится «44.33.22.11.in-addr.arpa.», что является правильным, структурированным доменным именем. Обычно сервис имен должен отправлять запрос серверу имен о PTR записи присвоенной сгенерированному имени.