важна. Далее две строки указывают на два хоста, на которые нужно попытаться доставить электронную почту для [email protected]. Сначала следует связаться с хостом zephyr. В случае неудачи следует попробовать доставить письмо хосту top. Следующая строка задает в качестве сервера имен домена хост star.

После пустой строки, добавленной для удобства чтения, следуют строки, сообщающие IP-адреса хостов star, zephyr и top. Затем следует псевдоним www.cs.vu.nl, позволяющий не обращаться к какому-то конкретному компьютеру. Создание этого псевдонима позволяет домену cs.vu.nl изменять свой веб-сервер, не меняя адрес, по которому люди к нему обращаются. С той же целью в следующей строке создается псевдоним ftp.cs.vu.nl для FTP-сервера.

; Authoritative data for cs.vu.nl

cs.vu.nl.        86400   IN   SOA     star boss (9527,7200,7200,241920,86400)

cs.vu.nl.        86400   IN   MX      1 zephyr

cs.vu.nl.        86400   IN   MX      2 top

cs.vu.nl.        86400   IN   NS      star

star             86400   IN   A       130.37.56.205

zephyr           86400   IN   A       130.37.20.10

top              86400   IN   A       130.37.20.11

www              86400   IN   CNAME   star.cs.vu.nl

ftp              86400   IN   CNAME   zephyr.cs.vu.nl

flits            86400   IN   A      130.37.16.112

flits            86400   IN   A      192.31.231.165

flits            86400   IN   MX     1 flits

flits            86400   IN   MX     2 zephyr

flits            86400   IN   MX     3 top

rowboat                  IN   A      130.37.56.201

                         IN   MX     1 rowboat

                         IN   MX     2 zephyr

little-sister            IN   A      130.37.62.23

laserjet                 IN   A      192.31.231.216

Илл. 7.5. Часть гипотетической базы данных DNS (файла зоны) домена cs.vu.nl

В секции, относящейся к хосту flits, указаны два IP-адреса и три возможных варианта адреса для обработки почты, направляемой на адрес flits.cs.vu.nl. Разу­меется, прежде всего нужно попробовать доставить письмо самому хосту flits. Но если он выключен, необходимо обратиться к хостам zephyr и top.

Следующие три строки содержат типичные записи для компьютера, в данном случае для rowboat.cs.vu.nl. Эти строки содержат его IP-адрес, а также имена первого и второго хостов для доставки почты. Следом идет запись о компьютере, неспособном самостоятельно получать почту. Последняя строка, вероятно, описывает подключенный к интернету лазерный принтер.

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

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

Расстановка границ внутри каждой зоны определяется ее администратором. Это решение зависит от того, сколько серверов имен требуется в той или иной зоне. Например, у Чикагского университета (илл. 7.6) есть зона для домена uchicago.edu, которая управляет доменом cs.uchicago.edu, но не доменом eng.uchicago.edu, расположенным в отдельной зоне со своими серверами имен. Подобное решение может быть принято, когда факультет английского языка не хочет управлять собственным сервером имен, но этого хочет факультет вычислительной техники.

Илл. 7.6. Часть пространства имен DNS, разделенная на зоны (они обведены)

7.1.5. Разрешение имен

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

Процесс поиска адреса по имени называется разрешением имен (name resolution). Распознаватель обращается с запросом разрешения имени домена к локальному серверу имен. Если искомый домен относится к сфере ответственности данного сервера (к примеру, домен top.cs.vu.nl относится к домену cs.vu.nl), тогда сервер возвращает авторитетную запись (authoritative record) ресурса (так называют запись, которая поступает из управляющего ею авторитетного источника). В отличие от кэшируемых записей (cached records), которые могут устаревать, авторитетные записи всегда считаются верными.

Но что происходит, если домен является удаленным, как, например, в случае, когда flits.cs.vu.nl пытается найти IP-адрес для домена cs.uchicago.edu в Чикагском университете? В этом случае, при отсутствии информации о запрашиваемом домене в локальном кэше, сервер имен отправляет удаленный запрос. Этот запрос выполняется, как показано на илл. 7.7. На первом шаге запрос передается локальному серверу имен. В нем указывается имя искомого домена, тип (A) и класс (IN).

Илл. 7.7. Пример поиска распознавателем имени удаленного хоста за десять шагов

На следующем шаге запрос направляется одному из корневых серверов имен (root name servers) на вершине иерархии. На таких серверах хранится информация о каждом домене верхнего уровня. На рис 7.7 этот шаг обозначен цифрой 2. Чтобы связаться с корневым сервером, каждый сервер имен должен обладать информацией об одном или нескольких подобных серверах. Обычно эти сведения находятся в файле системной конфигурации, который загружается в кэш DNS на этапе запуска сервера DNS. Это просто список записей NS для корня, вместе с соответствующими записями А.

Существует 13 корневых серверов DNS, которым без всякого воображения были присвоены имена от a-root-servers.net до m.root-servers.net. Каждый корневой сервер логически представляет собой просто отдельный хост. Но поскольку весь интернет зависит от корневых серверов, для них используются мощные и активно реплицируемые компьютеры. Большинство этих серверов расположено в разных географических точках, доступ к которым осуществляется путем произвольной маршрутизации (она сводится к доставке пакета ближайшему экземпляру адреса получателя). Произвольная рассылка была подробно описана в главе 5. Репликация этих серверов повышает надежность и производительность.

Корневой сервер имен вряд ли знает адрес искомого хоста в домене uchicago.edu, и, возможно, ему даже неизвестно, к какому серверу имен этот домен привязан. Но он должен знать сервер имен для домена edu, где расположен домен cs.uchicago.edu. Он возвращает имя и IP-адрес для этой части ответа на третьем шаге.

Затем локальный сервер имен проводит дальнейший поиск. Он отправляет весь запрос серверу имен домена edu (a.edu-servers.net). Этот сервер имен возвращает информацию о сервере имен домена uchicago.edu. На рисунке это шаги 4 и 5. Теперь, уже приблизившись к цели, локальный сервер имен отсылает запрос серверу имен домена uchicago.edu (шаг 6). Если искомое доменное имя расположено на факультете английского языка, то ответ будет найден уже на этом этапе, поскольку зона uchicago.edu включает в себя этот факультет. Однако факультет вычислительной техники использует собственный сервер имен. Если нужное доменное имя находится на факультете вычислительной техники, то запрос вернет имя и IP-адрес сервера имен этого факультета в зоне uchicago.edu (шаг 7).

Наконец, локальный сервер имен направляет запрос серверу имен факультета вычислительной техники в зоне uchicago.edu (шаг 8). Поскольку этот сервер отвечает за домен cs.uchicago.edu, он должен выдать нужный ответ. Он вернет окончательный ответ на шаге 9, после чего на шаге 10 локальный сервер имен передаст его хосту flits.cs.vu.nl.

7.1.6. Практическое ознакомление с DNS

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