Процесс разрешения имен

Разрешение имен – определение ip-адреса, сопоставленного с этим именем.

В DNS клиент, выполняющий разрешение имен, называется интерпретатором.

Интерпретатор работает на прикладном уровне модели TCP/IP (рис.1).

Рис.1.

Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

• Всего множества доменных имен (domain name space)

• Серверов доменных имен (domain name servers)

• Клиенты DNS (Resolver-ы)

Сервис системы доменных имен строится по схеме "клиент-сервер". В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени).

Это программное обеспечение и называют resolver.

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

Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.

Другой пример реализации resolver-а - это браузеры Nescape некоторых версий, где для ускорения процесса получения ответов на запросы к DNS запускался отдельный процесс resolvera.

В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

Нерекурсивное разрешение доменного имени

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

Рис 2. Рекурсивный запрос resolver и нерекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен.

Данная схема разрешения имени (установки соответствия между именем и IP-адресом) называют нерекурсивной (итеративной).

Агоритм работы:

1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у локального сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).

2. Локальный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:

- если адрес находится в зоне его (локального сервера) ответственности, сразу сообщает его resolver-у,

- если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server),

- обращается к TLD-серверу за адресом,

- получает от него адрес удаленного сервера,

- обращается к удаленному серверу за адресом,

- получает от удаленного сервера адрес,

В данном случае мы рассмотрели вложенность доменного имени второго порядка., т.е. хост имел имя похожее на quest.test.ua.

Последнее важно понять, т.к. корпоративные почтовые адреса типа user@test.ua как раз и требуют от прикладного программного обеспечения обращения за IP-адресом хоста test.ua.

TLD-сервер домена ua не обладает информацией о том, какому IP-адресу данное имя соответствует, но при этом он знает какой сервер отвечает за домен test.ua.

Если вложенность доменного имени будет большей, скажем третьего уровня (host.department.corp.ua), и этот уровень будет поддерживаться другим сервером доменных имен, отличным от того, который поддерживает второй уровень вложенности, то тогда нашему локальному серверу удаленный сервер доменных имен передаст не адрес хоста, а адрес нового сервера доменных имен, в зоне ответственности которого находится запрашиваемое имя.

Рассмотрим на примере работу DNS.

При входе в режиме удаленного терминала на компьютер polyn.net.kiae.su по команде:

/usr/paul>telnet polyn.net.kiae.su

Мы получаем в ответ:

/usr/paul>telnet polyn.net.kiae.su

trying 144.206.130.137 ...

login:

.....

Строчка, в которой указан IP-адрес компьютера polyn.net.kiae.su, показывает, что к этому времени доменное имя было успешно разрешено сервером доменных имен и прикладная программа, в данном случае telnet получила на свой запрос IP-адрес.

Таким образом, после ввода команды с консоли, и до появления IP-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

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

Мы рассматривали, только "прямые" (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные"(reverse) запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

Запросы обратного просмотра.

При таком запросе ip-адрес разрешается в доменное или хост-имя.

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

Для решения проблемы в корневом домене создается специальный домен in-addr.arpa, который использует ip-адреса в качестве индекса.

Следует заметить, что скорость разрешения "прямых" и "обратных" запросов в общем случае будет разная. Все зависит от того, где описаны "прямые"(forward) и "обратные"(reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).

Собственно нерекурсивным рассмотренный выше запрос является только с точки зрения сервера. С точки зрения resolver-а процедура разрешения запроса является рекурсивной, так как resolver перепоручил локальному серверу доменных имен заниматься поиском необходимой информации. Согласно RFC-1035, resolver и сам может опрашивать удаленные серверы доменных имен и получать от них ответы на свои запросы.

В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый "прямой" запрос (рис.3).

Рис.3. Нерекурсивный запрос resolver-а.

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

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

Самые умные resolver-ы умеют поддерживать кэш, в котором сохранияют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые "негативные" отклики (negative response results) на запроси (рис.4).

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

Рис.4. Схема разрешения запросов с кэшированием ответов.

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

Вообще говоря, прядок обработки запросов можно описать следующим образом:

• поиск ответа в локальном кэше

• поиск ответа на локальном сервере

• поиск информации в сети.

При этом кэш может быть как у resolver-а, так и у сервера.