Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Запись SRV — это новый тип, позволяющий определять хост для искомого сервиса в домене. Например, веб-сервер для cs.wasington.edu может быть определен как cockatoo.cs.wasington.edu. Данная запись является расширенным вариантом записи MX, которая выполняет ту же задачу в рамках почтовых сервисов.

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

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

Наконец, последнее поле записи ресурса — это поле Value (значение) — может быть числом, именем домена или текстовой ASCII-строкой. Смысл поля зависит от типа записи. Краткое описание поля Value для каждого из основных типов записей дано в табл. 7.2.

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

Листинг 7.1.Часть возможной базы данных домена cs.vu.nl

; Официальная

информация

для 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.1 дается основная информация о домене, которая в дальнейшем нас интересовать не будет. Следующие две строки определяют два хоста, с которыми следует связаться в первую очередь при попытке доставить электронную почту, посланную по адресу person@cs.vu.nl . Хост по имени zephyr (специальная машина) следует опросить первым. В случае неудачи следует попробовать доставить письмо машине по имени top . В следующей строке определен сервер имен для домена star .

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

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

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

7.1.3. Серверы имен

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

Чтобы избежать проблем, связанных с хранением всей информации в одном месте, пространство имен DNS разделено на непересекающиеся зоны (zones). Один возможный способ разделения пространства имен, показанного на рис. 7.1, на зоны изображен на рис. 7.2. Каждая очерченная зона содержит часть общего дерева доменов.

Расстановка границ зон целиком зависит от администратора зоны. Это решение основывается на том, сколько серверов имен требуется в той или иной зоне. Например, на рис. 7.2 у Вашингтонского университета есть зона для washington.edu , управляющая доменом eng.washington.edu , но не доменом cs.washington.edu , расположенным в отдельной зоне со своими серверами имен. Подобное решение может быть принято, когда факультет английского языка не хочет управлять собственным сервером имен, но этого хочет факультет вычислительной техники.

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

Рис. 7.2. Часть пространства имен DNS, разделенная на очерченные зоны

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

Однако что происходит, если домен удаленный, как, например, в случае, когда flits.cs.vu.nl пытается найти IP-адрес для robot.cs.washington.edu в Вашингтонском университете? В этом случае, если в кэше нет информации о запрашиваемом домене, доступном локально, сервер имен посылает удаленный запрос. Поясним данный процесс на примере, показанном на рис. 7.3. На первом шаге (обозначен «1») посылается запрос локальному серверу имен. Этот запрос содержит имя искомого домена, тип (Л) и класс (IN).