Rover's Home: Система доменных имен (материалы книги П.Б. Храмцова)

Система доменных имен (материалы книги П.Б. Храмцова)

Лучшей книгой по системе доменных имен является "DNS и BIND" Пола Альбитца и Крикета Ли. Однако, даже в этом издании изложены не все вопросы, связанные с администрированием DNS. Кроме того, жизнь не стоит на месте. Постоянно появляются новые проблемы и, как следствие, способы их решения. Мы предлагаем вашему вниманию электронную версию книги П.Б. Храмцова, к.т.н., доцента кафедры информационных ресурсов факультета информатики РГГУ, руководителя группы информационного обеспечения РНЦ "Курчатовский Институт".

История и правила именования хостов

Как работает система доменных имен

Типы серверов доменных имен. Master, Slave, Cache, Stealth, Root.

BIND (Berlekey Internet Name Domain). Общие сведения.

Resolver. Типовые настройки.

Типовые настройки named (пакет BIND). Кэширующий сервер, slave и master.

BIND 4.x

BIND 8.x и BIND 9.x

Описание зоны. Формат записи описания ресурсов (RR).

Запись "Start Of Authority" (SOA)

Запись "Name Server"(NS), проблема некорректного делегирования зон (lame delegation), метрика RTT (round trip time) и ее применение в BIND.

Адресная запись "Address". Балансировка нагрузки. Round Robin. Учет топологии сетей.

Записи типа "Pointer". Домен IN-ADDR.ARPA. Делегирование "обратных" зон. Инверсные запросы.

Запись Mail exchanger (MX). Электронная почта и DNS.

Запись назначения синонима каноническому имени "Canonical Name". Особенности использования синонимов при работе с NS и MX записями.

Файлы описания зоны. Директивы управления.

Типовые примеры описания зон и файлов конфигурации BIND

Настройка кэширующего сервера доменных имен. Примеры описания зон и файлов конфигурации BIND. Запуск и проверка работоспособности.

BIND 4

BIND 8.x и BIND 9.х

Проверка работоспособности

Небольшой корпоративный домен в домене ru. Описание "прямой" зоны. Описание "обратных" зон. Настройки BIND.

Описание "прямой" и "обратных" зон

Настройка BIND 4.x для поддержки небольшого корпоративного домена

Настройка BIND 8.x и BIND 9.x для поддержки небольшого корпоративного домена

Настройка slave сервера для корпоративного домена

"Прямая" и "обратная" зоны для домена, определенного на двух адресных пулах типа х.х.х.х/24 или организация обратных зон на "суперсетях" класса C

Тестирование серверов и системы доменных имен

Программа интерактивного тестирования серверов DNS - nslookup

Программа тестирования системы доменных имен - host

Программа тестирования системы доменных имен - dig

Прочие средства и способы тестирования работы системы доменных имен

Система доменных имен Internet. Немного истории и принципы построения иерархии имен.

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

В адресе электронной почты формально доменным именем можно считать то, что написано после символа коммерческого ат - "@". Например, в user@corp.ru доменное имя почтового узла - corp.ru.

Имя Web-узла - это доменное имя этого узла. Например, Web-узел компании Microsoft имеет доменное имя Microsoft.com.

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

Довольно часто наряду со словосочетанием "интернет-адрес" употребляют "доменный адрес". Вообще говоря, ни того, ни другого понятий в сетях TCP/IP не существует. Есть числовая адресация, которая опирается на IP-адреса, (группа из 4-ех чисел, разделенных символом ".") и Internet-сервис службы доменных имен (Domain Name System - DNS).

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

Тем не менее, установка соединений для обмена информацией в Интернет осуществляется по IP-адресам. Символьные имена системы доменных имен - суть сервис, который помогает найти необходимые для установки соединения IP-адреса узлов сети.

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

DNS существовала не с момента рождения TCP/IP сетей. Поначалу для облегчения взаимодействия с удаленными информационными ресурсами в Интернет стали использовать таблицы соответствия числовых адресов именам машин.

Авторство создания этих таблиц принадлежит доктору Постелю (Dr. Jon Postel - автор многих RFC - Request For Comments). Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP.

Современные операционные системы тоже поддерживают таблицы соответствия IP-адреса и имени машины (точнее хоста) - это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:

127.0.0.1 localhost
144.206.130.137 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.40 apollo Apollo www.polyn.kiae.su

Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того, для разных IP-адресов может быть указано одно и то же имя.

Напомним еще раз, что по самому мнемоническому имени никакого доступа к ресурсу получить нельзя. Процедура использования имени заключается в следующем:

сначала по имени в файле hosts находят IP-адрес,

затем по IP-адресу устанавливают соединение с удаленным информационным ресурсом.

Обращения, приведенные ниже аналогичны по своему результату - инициированию сеанса telnet с машиной Apollo:

telnet 144.206.160.40

или

telnet Apollo

или

telnet www.polyn.kiae.su

В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows последних версий поддерживают эту систему соответствия IP-адресов именам хостов.

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

DNS была описана Полом Мокапетрисом (Paul Mockapetris ) в 1984. Это два документа: RFC-882 и RFC-883 (Позже эти документы были заменены на RFC-1034 и RFC-1035). Пол Мокапетрис написал и реализацию DNS - программу JEEVES для ОС Tops-20. Именно на нее в RFC-1031 предлагается перейти администраторам машин с ОС Tops-20 сети MILNET. Не будем подробно излагать содержание RFC-1034 и RFC-1035. Ограничимся только основными понятиями.

Роль имени (доменного имени) в процессе установки соединения осталось прежним. Это значит, что главное, для чего оно нужно, - получение IP адреса. Соответственно этой роли, любая реализация DNS является прикладным процессом, который работает над стеком протоколов межсетевого обмена TCP/IP. Таким образом, базовым элементом адресации в сетях TCP/IP остался IP-адрес, а доменное именование (система доменных имен) выполняет роль вспомогательного сервиса.

Система доменных имен строится по иерархическому принципу. Точнее по принципу вложенных друг в друга множеств. Корень системы называется "root" (дословно переводится как "корень") и никак не обозначается (имеет пустое имя согласно RFC-1034).

Часто пишут, что обозначение корневого домена - символ ".", но это не так, точка - разделитель компонентов доменного имени, а т.к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее символ "." достаточно прочно закрепился в литературе в качестве обозначения корневого домена. От части это вызвано тем, что в файлах конфигурации серверов DNS именно этот символ указывается в поле имени домена (поле NAME согласно RFC-1035) в записях описания ресурсов, когда речь идет о корневом домене.

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

В 80-е годы были определены первые домены первого уровня (top-level): gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики Союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п.

Однако Интернет не СССР, и просто так выбросить домен su из системы доменных имен нельзя. На основе доменных имен строятся адреса электронной почты и доступ ко многим другим информационным ресурсам Интернет. Поэтому гораздо проще оказалось ввести новый домен к существующему, чем заменить его.

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

Со списком доменов первого уровня (top-level) и их типами можно ознакомиться, например, в материале "Общая информация о системе доменных имен".

Как уже было сказано, вслед за доменами первого уровня(top-level) следуют домены, определяющие либо регионы (msk), либо организации (kiae). В настоящее время практически любая организация может получить свой собственный домен второго уровня. Для этого надо направить заявку провайдеру и получить уведомление о регистрации (см. "Как получить домен").

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

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

Рис.1. Пример части дерева доменных имен.

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

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

polyn.net.kiae.su.

Частичное имя - это имя, в котором перечислены не все, а только часть имен узлов, например:

polyn
apollo.polyn
quest.polyn.kiae

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

Слово "Хост" не является в полном смысле синонимом имени компьютера, как это часто упрощенно представляется. Во-первых, у компьютера может быть множество IP-адресов, каждому из которых можно поставить в соответствие одно или несколько доменных имен. Во-вторых, одному доменному имени можно поставить в соответствие несколько разных IP-адресов, которые, в свою очередь могут быть закреплены за разными компьютерами.

Еще раз обратим внимание на то, что именование идет слева направо, от минимального имени хоста (от листа) к имени корневого домена. Разберем, например, полное доменное имя demin.polyn.kiae.su. Имя хоста - demin, имя домена, в который данный хост входит, - polyn, имя домена, который охватывает домен polyn, т.е. является более широким по отношению к polyn, - kiae, в свою очередь последний (kiae) входит в состав домена su.

Имя polyn.kiae.su - это уже имя домена. Под ним понимают имя множества хостов, у которых в их имени присутствует polyn.kiae.su. Вообще говоря, за именем polyn.kiae.su может быть закреплен и конкретный IP-адрес. В этом случае кроме имени домена данное имя будет обозначать и имя хоста. Такой прием довольно часто используется для обеспечения коротких и выразительных адресов в системе электронной почты.

Имена хоста и доменов отделяются друг от друга в этой нотации символом ".". Полное доменное имя должно оканчиваться символом ".", т.к. последняя точка отделяет пустое имя корневого домена от имени домена верхнего уровня. Часто в литературе и в приложениях эту точку при записи доменного имени опускают, используя нотацию неполного доменного имени даже в том случае, когда перечисляют все имена узлов от листа до корня доменного именования.

Следует иметь в виду, что доменные имена в реальной жизни достаточно причудливо отображаются на IP-адреса, а тем более на реальные физические объекты (компьютеры, маршрутизаторы, коммутаторы, принтеры и т.п.), которые подключены к сети.

Компьютер, физически установленный и подключенный к Сети в далекой Америке, может совершенно спокойно иметь имя из российского корпоративного домена, например, chalajva.ru, и наоборот, компьютер или маршрутизатор российского сегмента может иметь имя из домена com. Последнее, к слову сказать, встречается гораздо чаще.

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

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

Следует также упомянуть о канонических доменных именах. Это понятие встречается в контексте описания конфигураций поддоменов и зон ответственности отдельных серверов доменных имен. С точки зрения дерева доменных имена не разделяют на канонические и неканонические, но с точки зрения администраторов, серверов и систем электронной почты такое разделение является существенным. Каноническое имя - это имя, которому в соответствие явно поставлен IP-адрес, и которое само явно поставлено в соответствие IP-адресу. Неканоническое имя - это синоним канонического имени. Более подробно см. "настройка BIND".

Наиболее популярной реализацией системы доменных имен является Berkeley Internet Name Domain (BIND). Но эта реализация не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию DNS.

Тем не менее, даже администраторам Windows желательно знать принципы функционирования и правила настройки BIND, т.к. именно это программное обеспечение обслуживает систему доменных имен от корня до TLD (Top Level Domain).

Рекомендованная литература:

P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)

P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)

W.Lazear. RFC-1031. MILNET NAME DOMAIN TRANSITION. 1987. (http://www.ietf.org/rfc/rfc1031.txt?number=1031)

Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.

Полезные ссылки:

http://www.dns.net/dnsrd/docs/ - коллекция ссылок на документы о системе доменных имен.

http://www.internic.net/faqs/authoritative-dns.html - коротенькое описание назначения системы доменных имен.

http://www.icann.org/ - сайт организации, которая в ответе за именование в Интернет.

http://www.ispras.ru/~grn/dns/index.html - Г.В. Ключников. Служба доменных имен (Domain Name System). 1999. На самом деле, это отличная компиляция приведенных в конце книжки первоисточников. Примеры взяты из этих же первоисточников. Очень качественный перевод и грамотно скомпонованный текст.

http://www.ibb.ru/articles/stat_3.phtml - из серии "DNS за пять минут" J, но в качестве введения в тему данный материал может пригодиться.

http://www.pi2.ru:8100/prof/techsupp/dns.htm - своеобразное описание системы доменных имен. Во всяком случае, самобытное. Но некоторые аспекты освещены довольно необычно.

Как работает система доменных имен.

Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:
- Всего множества доменных имен (domain name space)
- Серверов доменных имен (domain name servers)
- Клиенты DNS (Resolver-ы)
Множество доменных имен было подробно рассмотрено в материале "Доменная адресация. Немного истории и принципы построения", поэтому сосредоточимся на двух оставшихся компонентах серверах и resolver-ах.

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

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

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

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

Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из rosolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

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

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

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

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

Поясним приведенную схему нерекурсивной процедуры разрешения запроса:
1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).
2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:
  1. если адрес находится в зоне его (местного сервера) ответственности, сразу сообщает его resolver-у,
  2. если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server),
  3. обращается к TLD-серверу за адресом,
  4. получает от него адрес удаленного сервера,
  5. обращается к удаленному серверу за адресом,
  6. получает от удаленного сервера адрес,
В данном случае мы рассмотрели вложенность доменного имени второго порядка., т.е. хост имел имя похожее на quest.kuku.ru или даже kuku.ru.

Последнее важно понять, т.к. корпоративные почтовые адреса типаuser@kuku.ru как раз и требуют от прикладного программного обеспечения обращения за IP-адресом хоста kuku.ru. TLD-сервер домена ru не обладает информацией о том, какому IP-адресу данное имя соответствует, но при этом он знает какой сервер отвечает за домен kuku.ru.

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

Как видно из приведенной схемы, получение информации из системы доменных имен - это многоходовой процесс, который не реализуется мгновенно. В следующем примере показано как на практике ощущается работа 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-адреса на экране монитора прикладная программа осуществила запрос к серверу доменных имен и получила ответ на него.

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

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

Любопытно, что в системе Windows 3.1 некоторые программы трассировки, показывали сначала IP-адрес шлюза, а только потом, после разрешения "обратного" запроса, заменяли его на доменное имя шлюза. Если сервис доменных имен работал быстро, то эта подмена была практически незаметна, но если сервис работал медленно, то промежутки бывали довольно значительными.

Проверить на сколько "чувствительны" запросы traceroute c точки зрения отображения трассы к использованию сервера доменных имен можно задав поиск трассы с использованием сервера:
```
>traceroute www.w3.org
```
и без использования сервера:
```
>traceroute -n www.w3.org
```
Если в примере с telnet и ftp мы рассматривали, только "прямые" (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные"(reverse) запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

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

Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named.

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

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

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

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

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

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

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

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

Вообще говоря, прядок обработки запросов можно описать следующим образом:
1. поиск ответа в локальном кэше
2. поиск ответа на локальном сервере
3. поиск информации в сети.
При этом кэш может быть как у resolver-а, так и у сервера.

Прежде, чем мы двинемся дальше в нашем понимании работы системы доменных имен введем еще одно понятие - зону.

Между доменом и зоной существует разница, которую бывает трудно найти, но всегда нужно иметь в виду. Домен - это все множество машин, которые относятся к одному и тому же доменному имени. Например, все машины, которые в своем имени имеют постфикс kiae.su относятся к домену kiae.su. Зона - это "зона ответственности" конкретного сервера доменных имен, т.е. понятие домена шире, чем понятие зоны. Если домен разбивается на поддомены, то у каждого из них может появиться свой сервер. При этом зоной ответственности сервера более высокого уровня будет только та часть описания домена, которая не делегирована другим серверам. Разбиение домена на поддомены и организация сервера для каждого из них называется делегирование прав управления зоной соответствующему серверу доменных имен, или просто делегированием зоны.

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

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

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

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

На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена по рекурсивному запросу, используя при этом нерекурсивный опрос своих серверов поддоменов.

Рис 4. Нерекурсивная обработка запроса местным сервером доменных имен на получение IP-адреса по доменному имени.

Рис. 5. Рекурсивная (для местного сервера) и нерекурсивная (для удаленного сервера) процедуры разрешения адреса по IP-имени.

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

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

Рекомендованная литература:
1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.
Полезные ссылки:
1. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_und_HowDnsWorks.htm?id=1945 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы системы доменных имен. Описывает общие принципы построения DNS и взаимодействия resolver и серверов.
2. http://www.microsoft.com/windows2000/en/server/help/sag_DNS_ovr_ClientFeatures.htm?id=1942 - Документация Microsoft по Windows 2000 Server. Раздел посвящен принципам работы resolver.
3. http://www.nominum.com/resources/documentation/Bv9ARM.pdf- Документация по BIND 9. Справочное руководство системного администратора. Нужно ознакомиться с разделом, посвященном lightweight resolver.
4. http://www.igc.ru/cgi-bin/man-cgi?traceroute - описание команды traceroute, раз уж ее здесь упомянули.
5. http://www.menandmice.com/online_docs_and_faq/glossary/glossarytoc.htm- глоссарий терминов DNS.