TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) - читать бесплатно онлайн полную версию книги автора Сидни М. Фейт (Глава 12 DNS) #16

Глава 12 DNS

12.1 Введение

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

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

В первые дни существования Интернета использовалась также централизованная таблица. Ее главную копию обслуживал сетевой информационный центр Министерства обороны США (DOD NIC), что позволяло проводить преобразование имен в адреса другим системам, периодически копировавшим содержимое главной таблицы. Однако со временем этот метод стал неэффективным.

12.2 Назначение DNS

Система имен доменов (Domain Name System — DNS) обеспечивает более эффективный способ согласования имен и адресов Интернета. База данных DNS обеспечивает автоматизированную службу преобразования имен в адреса. Эта система успешно работает, и многие организации, даже не подключенные к Интернету, применяют DNS для обслуживания собственных внутренних имен компьютеров.

DNS является распределенной базой данных. Имена и адреса Интернета хранятся на множестве серверов по всему миру (ниже мы узнаем о хранении на этих же серверах важных сведений о маршрутизации электронной почты). Организация, владеющая именем домена (например, yale.edu), несет ответственность за обслуживание и работу с сервером имен, который выполняет трансляцию имен этого домена в адреса. Локальный обслуживающий персонал быстро отслеживает изменения, добавление или удаление сетевых узлов и согласует эти операции с первичным сервером (primary server) домена. Поскольку данные для трансляции имен в адреса очень важны, данная информация реплицируется на один или несколько вторичных серверов (secondary server).

12.3 Программное обеспечение BIND

Многие разработчики компьютеров предоставляют бесплатное программное обеспечение для сервера имен. Обычно оно является адаптацией пакета Berkeley Internet Domain (BIND) для конкретных условий. Периодически в Интернете появляются новые бесплатные версии пакета BIND.

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

12.4 Определители

Клиентская программа для просмотра информации DNS является стандартной частью любого продукта TCP/IP и называется определителем (resolver). Обычно определитель работает в фоновом режиме, и пользователь даже не замечает его присутствия. В приведенном ниже примере пользователь запрашивает соединение по telnet с системой minnie.jvhc.net. Пользовательское приложение telnet запрашивает локальную программу-определитель об IP-адресе для указанного сайта:

> telnet minnie.jvnc.net

Trying 128.121.50.141 ...

Connected to minnie.jvnc.net.

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

Примером может служить система tigger, используемая провайдером Global Enterprise System в качестве сервера электронной почты, сетевых новостей и сервера telnet. Как и большинство систем Unix, tigger имеет конфигурационный файл /etc/resolv.conf, в котором указаны локальные имена доменов и IP-адреса двух серверов имен доменов для данного домена.

> more /etc/resolv.conf

domain jvnc.net

128.121.50.2

128.121.50.7

Настольным системам TCP/IP также требуется информация DNS. Как показано на рис. 12.1, программный пакет Chameleon для Microsoft Windows предоставляет раскрывающееся меню, в которое вводят сведения об IP-адресах серверов имен доменов.

Рис. 12.1. Конфигурирование DNS

12.5 Просмотр адресов хостов

Как мы уже знаем, многие системы предоставляют интерактивные программы-определители, дающие возможность пользователям напрямую обращаться к серверам DNS, посылая к ним запросы и получая ответы. Приведем пример работы с программой-определителем nslookup для Unix:

1. Сразу после ввода пользователем имени программы локальный сервер по умолчанию идентифицирует себя, выводя собственное имя и адрес. В нашем примере именем будет r2d2.jvnc.net, а адресом — 128.121.50.2.

2. Пользователь вводит имя хоста, адрес которого нужно узнать.

3. Запрос отправляется на сервер.

4. После каждого запроса сервер (r2d2) идентифицирует себя и выводит ответ.

5. Если пользователь запрашивает локальную информацию, то сервер извлекает ответ из собственной базы данных.

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

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

Каждый этап диалога с программой разъясняется комментариями в правой части страницы. Отметим, что ответ, извлеченный из кеша сервера, маркируется как неавторитетный.

> nslookup

Default Server:

R2d2.jvnc.net

Выводится имя и адрес локального сервера.

Address: 128.121.50.2

> Mickey.jvnc.net.

Пользователь вводит запрос, ответ на который

находится в локальной базе данных.

Server: r2d2.jvnc.net

Снова вывод идентификатора и адреса сервера.

Address: 128.121.50.2

Name: mickey.jvnc.net

Указанное в запросе имя.

Address: 128.121.50.143

Ответ.

> Www.novell.com.

Пользователь вводит запрос об удаленном хосте.

Server: r2d2.jvnc.net

Снова вывод идентификатора и адреса сервера.

Address: 128.121.50.2

Name: www.novell.com

Запрашиваемое имя.

Address: 137.65.2.5

Ответ сохранялся на диске r2d2 и был выведен

пользователю.

> Www.novell.com.

Пользователь повторяет запрос об удаленном

хосте.

Server: r2d2.jvnc.net

Снова вывод идентификатора и адреса сервера.

Address: 128.121.50.2

Non-authoritative answer:

Ответ получен из локального кеша.

Name: www.novell.com

Запрашиваемое имя,

Address: 137.65.2.5

Ответ.

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

Отметим, что в конце каждого запроса стоит символ точки. Ниже в мы рассмотрим причину этого.

12.6 Авторитетные ответы и ответы из кеша

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

Когда система посылает запрос к DNS, она не заботится о том, куда попадет запрос — на первичный или на вторичный сервер имен. Все серверы имен (первичные и вторичные) авторитетны (authoritative) для своего домена.

Для снижения трафика локальный сервер кеширует уже полученные ответы на своем жестком диске. При повторном запросе данные (если они еще находятся в кеше) извлекаются из кеша, формируя локальный ответ.

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

12.7 Трансляция адресов в имена

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

■ Установить тип запроса в ptr.

■ Записать адрес наоборот, дописав в конце его .in-addr.arpa.

Например:

> set type = ptr

> 143.50.121.128.in-addr.arpa.

Server: r2d2.jvnc.net

Address: 128.121.50.2

143.50.121.128.in-addr.arpa  host name = mickey.jvnc.net

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

Поддерево специального домена in-addr.arpa (см. рис. 12.2) создается для указания на все сетевые таблицы. Когда в это дерево помещается адрес, имеет смысл разместить первое число вверху, а оставшиеся числа сверху вниз. В этом случае все адреса 128.x.x.x окажутся ниже узла 128.

Рис. 12.2. Поддерево домена in-addr.arpa

Если читать метки на дереве с помощью тех же правил, что и для имен (сверху вниз), адреса получатся записанными в обратном порядке — в частности 143.50.121.128.in-addr.arpa.

Разумеется, пользовательский интерфейс программы nslookup мог бы скрыть эту технологию. Но это все же Unix, и на рис. 12.3 показана более дружественная для пользователя программа NSLookup, разработанная в Ashmount Research Ltd. Запросы вводятся в небольшом вторичном окне в нижней части общего окна программы, а ответы выводятся в верхнюю область окна. Отметим, что в обоих ответах присутствуют имена и адреса сервера имен, содержащего авторитетные сведения для данного запроса.

Рис. 12.3. Вопрос к DNS

12.8 Локальные и глобальные серверы имен доменов

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

Но при соединении сети с Интернетом сервер имен должен быть способен извлекать глобальную информацию. Ключом к пониманию данной операции является то, что, когда организация (например, microsoft.com) желает подключиться к Интернету, она обязана оформить сведения о себе в соответствующем комитете регистрации авторизации (registration authority), в нашем случае это InterNIC, и указать имена и адреса не менее чем двух серверов DNS. InterNIC добавит эти сведения в свой корневой список серверов имен доменов.

Корневой список реплицируется на несколько корневых серверов, играющих основную роль в обработке удаленных запросов DNS. Предположим, что запрос на трансляцию имени в адрес для www.microsoft.com поступил на локальный сервер имен trigger. Тогда:

■ Сервер проверяет принадлежность www.microsoft.com локальному домену.

■ Если имя не принадлежит локальному домену, проверяется его наличие в кеше.

■ Если имени нет и в кеше, сервер посылает запрос корневому серверу.

■ Корневой сервер возвращает имя и адрес сервера DNS, который содержит сведения о www.microsoft.com.

Для просмотра текущего списка корневых серверов следует запустить nslookup и указать тип запроса ns. Если ввести точку (что означает корень дерева), будут возвращены имена и адреса нескольких корневых серверов.

> nslookup

> set type = ns

> .

Server: r2d2.jvnc.net

Address: 128.121.50.2

Non-authoritative answer:

(Root) nameserver = C.ROOT-SERVERS.NET

(Root) nameserver = D.ROOT-SERVERS.NET

(Root) nameserver = E.ROOT-SERVERS.NET

(Root) nameserver = I.ROOT-SERVERS.NET

(Root) nameserver = F.ROOT-SERVERS.NET

(Root) nameserver = G.ROOT-SERVERS.NET

(Root) nameserver = A.ROOT-SERVERS.NET

(Root) nameserver = H.ROOT-SERVERS.NET

(Root) nameserver = B.ROOT-SERVERS.NET

Authoritative answers can be found from:

C.ROOT-SERVERS.NET internet address = 192.33.4.12

D.ROOT-SERVERS.NET internet address = 128.8.10.90

E.ROOT-SERVERS.NET internet address = 192.203.230.10

I.ROOT-SERVERS.NET internet address = 192.36.148.17

F.ROOT-SERVERS.NET internet address = 192.5.5.241

F.ROOT-SERVERS.NET internet address = 39.13.229.241

G.ROOT-SERVERS.NET internet address = 192.112.36.4

A.ROOT-SERVERS.NET internet address = 198.41.0.4

H.ROOT-SERVERS.NET internet address = 128.63.2.53

B.ROOT-SERVERS.NET internet address = 128.9.0.107

Корневой сервер обеспечивает прямые ссылки на серверы доменов второго уровня (как microsoft.com или yale.edu), расположенные ниже доменов COM, EDU, GOV и других доменов первого уровня. Примером может служить часть информации о 3com.com. полученная непосредственно из файла корневого списка (во втором столбце приведено значение тайм-аута в секундах, используемое в данном элементе):

3COM.COM.   172800 NS NS.3COM.COM.

NS.3COM.COM. 172800 А  129.213.128.2

3COM.COM.   172800 NS TMC.EDU.

TMC.EDU.   172800 А  128.249.1.1

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

Можно получить полную информацию о серверах имен организации, указав в команде nslookup тип запроса ns:

> set type = ns

> 3com.com.

3com.com nameserver = NS.3COM.COM

3com.com nameserver = TMC.EDU

3com.com nameserver = XANTH.CS.ODU.EDU

3com.com nameserver = AEROSPACE.AERO.ORG

3com.com nameserver = ANTARES.AERO.ORG

Authoritative answers can be found from:

NS.3COM.COM     inet address = 129.213.128.2

TMC.EDU       inet address = 128.249.1.1

XANTH.CS.ODU.EDU   inet address = 128.82.4.1

AEROSPACE.AERO.ORG inet address = 130.221.192.10

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

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

Производя просмотр имен серверов по коду страны, база данных InterNIC возвращает список имен и адресов корневых серверов этой страны. Диалог с программой nslookup показывает получение списка корневых серверов Канады:

> ca.

ca            nameserver = RELAY.CDNNET.СА

ca           nameserver = RSO.INTERNIC.NET

ca           nameserver = CLOUSO.CRIM.СА

ca            nameserver = SNORT.UTCC.UTORONTO.СА

ca           nameserver = NS2.UUNET.CA

RELAY.CDNNET.СА     inet address = 192.73.5.1

RSO.INTERNIC.NET    inet address = 198.41.0.5

CLOUSO.CRIM.CA     inet address = 192.26.210.1

SNORT.UTCC.UTORONTO.CA inet address = 128.100.102.201

NS2.UUNET.CA      inet address = 142.77.1.5

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

Аналогично организация может сформировать корневое дерево для собственных узлов DNS и авторизировать их как части именования доменов.

На практике используется относительно небольшое вторичное деление, и имена можно найти за несколько шагов. На рис. 12.4 показаны этапы разрешения (определения адреса по имени) для viper.cs.titech.ac.jp:

1. Производится обращение к корневому дереву InterNIC. При этом идентифицируется сервер в Японии.

2. Запрашивается один из корневых серверов Японии, который идентифицирует домен университета Titech.

3. Сервер университета Titech предоставляет адрес для хоста.

Рис. 12.4. Разрешение имен для системы из Японии

Отметим, что локальный сервер отвечает за предоставление ответа клиенту. Это правило связано с рекурсивным разрешением имен, что означает "искать ответ до тех пор, пока не будет получен результат".

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

12.10 Соединение серверов имен с Интернетом

Подключение собственного сервера DNS к общемировому Интернету предполагает несколько этапов:

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

2. Присвоение имен и адресов собственным хостам

3. Получение списка корневых серверов, объединяющих всемирную службу

4. Установка одного первичного сервера имен DNS и не менее одного вторичного

5. Тестирование серверов

6. Перевод серверов в рабочий режим

7. Регистрация имени домена организации и ее серверов в региональной регистрационной службе

12.11 Разработка базы данных сервера имен

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

12.11.1 Зоны

Дерево имен организации может состоять из одной или нескольких зон (zone). Зоной называется непрерывная часть дерева имен, управляемая как единое целое. На рис. 12.5 показана структура зон для домена fishfood.com.

Рис. 12.5. Определение зон

Корневая база данных Интернета должна ссылаться на сервер имен центрального офиса компании (flshfood.com). Этот сервер будет формировать ответы на запросы адресов для своей зоны. Если же запрашивается имя системы из подразделений компании в Мериленде или Джорджии, то сервер центрального офиса возвратит имя и адрес сайта соответствующего подразделения компании. DNS будет пересылать запрос на сервер требуемой зоны.

12.11.2 Размещение серверов DNS

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

12.11.3 Перенос зон

Вторичный сервер настроен на обеспечение доступа к копиям информации об одной или нескольких зонах. Он получает информацию для зоны от первичного сервера посредством переноса зоны (zone transfer).

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

12.12 Данные DNS

Для сервера DNS требуется, по крайней мере, следующая информация:

■ Список корневых серверов всего мира, чтобы выяснить, куда посылать внешние запросы. Файл такого списка можно скопировать с сервера регистрации InterNIC.

■ Список имен и соответствующих им адресов.

■ Список адресов и соответствующих им имен.

12.13 Элементы описании в DNS

Данные DNS хранятся как набор текстовых элементов. Информационная запись содержит следующие элементы:

[имя] [TTL] [класс] Тип_Записи Данные_Записи [; комментарий]

Время жизни (TTL) указывает, как долго может быть кеширована запись после извлечения.

Если этот параметр не указан, то используется значение по умолчанию для имени или класса последнего элемента, включенного в список. В Интернете в текущий момент используется единственный класс IN, поэтому данное значение появляется только один раз, в первой записи.

Порядок расположения полей класса и TTL может быть изменен. Значение TTL выражается числом и, следовательно, не может быть перепутано с классом (IN).

12.13.1 Записи о ресурсах

Эта часть элемента данных состоит из:

[TTL] [класс] Тип_записи Данные_записи

и называется записью о ресурсах (resource record — RR). Существует несколько типов записей о ресурсах, каждый из которых идентифицируется символом или коротким акронимом. Типы записей о ресурсах перечислены в таблице 12.1.

Таблица 12.1 Типы записей о ресурсах

Тип записи	Описание
SOA	Start Of Authority (начало авторизации) — идентифицирует домен или зону, а также набор числовых параметров.
NS	Отображает имя домена на имя компьютера, авторитетного для данного домена.
A	Отображает имя системы на ее адрес. Если система (например, маршрутизатор) имеет несколько адресов, для каждого из них должна существовать отдельная запись.
CNAME	Отображает псевдоним на действительное каноническое имя.
MX	Mail Exchanger (обмен почтой). Идентифицирует систему, доставляющую в организацию сообщения электронной почты.
TXT	Обеспечивает способ добавления текстовых комментариев к базе данных. Например, запись txt может отображать fishfood.com на название компании, ее адрес или на номер телефона.
WKS	Well-Known Services (общеизвестные службы). Может перечислить доступные на хосте прикладные службы. Используется не слишком часто, если вообще применяется.
HINFO	Host Information (информация о хосте) — например тип компьютера и его модель. Используется редко.
PTR	Отображает IP-адрес на имя системы. Используется в файлах трансляции адресов в имена.

12.14 Пример файла трансляции имен в адреса

Рис. 12.6 демонстрирует файл трансляции имен в адреса для нашего мифического домена fishfood.com. Файл содержит несколько комментариев, которые отмечены символом точки с запятой (;).

12.14.1 Записи SOA

Первой записью в файле стоит начало авторизации (Start of Authority — SOA):

FISHFOOD.COM. IN SOA NS.FISHFOOD.COM. (

            postmaster.FISHFOOD.COM.

           94101101 ; serial number

             86400 ; refresh after 24 hours

             7200 ; retry after 2 hours

            2592000 ; expire after 30 days

            345600 ; default TTL of 4 days

; fishfood.com file

FISHFOOD.COM. IN SOA NS.FISHFOOD.COM. (

            postmaster.FlSHFOOD.COM.

            94101101 ; serial number

             86400 ; refresh after 24 hours

              7200 ; retry after 2 hours

             2592000 ; expire after 30 days

             345600 ; default TTL of 4 days

FISHFOOD.COM. IN NS NS.FISHFOOD.COM.

FISHFOOD.COM. IN NS NS2.FISHFOOD.COM

LOCALHOST IN A 127.0.0.1

NS    IN A 172.66.1.1

NS2    IN A 172.66.1.100

MAIL-RELAY IN A   172.66.1.2

      IN TXT  www, ftp on mail-relay

      IN TXT  gopher on mail-relay

      IN HINFO SUN UNIX ; should not include

WWW   IN CNAME MAIL-RELAY

FTP   IN CNAME MAIL-RELAY

GOPHER IN CNAME MAIL-RELAY

FISHFOOD.COM. IN MX 1 MAIL-RELAY

*       IN MX 1 MAIL-RELAY

NS       IN MX 1 MAIL-RELAY

;end of fishfood.com file

Рис. 12.6. Пример файла трансляции имен в адреса

Круглые скобки в записи SOA позволяют расширить эту запись на следующие строки. В запись включено несколько значений тайм-аута (измеряются в секундах). Данная запись SOA указывает:

■ Сервер ns.fishfood.com является первичным для домена fishfood.com.

■ Сведения о всех возникающих проблемах нужно сообщать на postmaster@fishfood.com (следует заменить первую точку на символ @).

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

■ Соединяться с первичным сервером каждые 24 часа.

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

■ Повторить попытку соединения через 2 часа, если он не сможет соединиться с первичным в намеченное время.

■ Отметить все свои данные просроченными и прекратить отвечать на запросы, если он не сможет соединяться с первичным в течение 30 дней.

Показанные в примере значения рекомендованы (см. RFC 1537) для серверов верхнего уровня.

12.14.2 Время жизни (Time-To-Live)

В RFC 1035 (специфицирует протокол DNS) заявлено, что TTL в записи SOA — это минимальное значение тайм-аута, разрешенное для всех записей. Но на практике администратору хочется использовать TTL в записи SOA как значение по умолчанию, указывая меньшие значения только для определенных хостов, информация на которых должна быстро измениться. В реализации следуют этому более осмысленному действию, а не требованиям стандарта.

В приведенном примере значение по умолчанию (для TTL — 4 дня) обычно располагается в диапазоне от одного дня до недели, в зависимости от устойчивости данного элемента сайта.

12.14.3 Дополнение имени

Имя, которое не заканчивается точкой, дополняется именем домена для зоны, например fishfood.com. Таким образом, в этом файле ns будет соответствовать ns.fishfood.com.

12.14.4 Запись о сервере имен

Запись о сервере имен (Name Server — NS) идентифицирует сервер для домена. Если имеются подзоны, необходимы и элементы для дочерних серверов имен подзон, чтобы сервер с более высоким уровнем мог использовать указатели на серверы низшего уровня. Записи об адресе требуются для обеспечения доступа к дочерним серверам и называются связующими (glue records).

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

12.14.5 Записи об адресе

Запись об адресе (address records) — это просто отображение имени в адрес. Таким образом, адресом ns.fishfood.com будет 172.66.1.1.

12.14.6 Записи CNAME

Вспомним, что для более осмысленного именования можно присваивать серверным хостам короткий псевдоним. В показанном примере службы World Wide Web пересылки файлов и gopher выполняются на той же машине, которая поддерживает доставку электронной почты. Запись для канонического имени (canonical name — CNAME) определяет короткое имя для хоста и разрешает пользователям вводить www.fishfood.com, ftp.fishfood.com или gopher.fishfood.com.

12.14.7 Записи для почтового обмена

Серверы обмена почтой (Mail Exchanger — MX) обеспечивают доставку в/из сети (см. главу 16). В файле существуют три записи MX, которые идентифицируют сервер MX для fishfood.com.

fishfood.com. IN MX 1 MAIL-RELAY

*       IN MX 1 MAIL-RELAY

ns       IN MX 1 MAIL-RELAY

Эти записи фактически указывают, что:

■ Почта, адресованная на некто@fishfood.com, должна быть доставлена на mail-relay.fishfood.com.

■ Подстановочный символ * позволяет пересылать почту, адресованную особым хостам, которые отсутствуют в списке DNS. Почта, адресованная на некто@любой_хост.fishfood.com, должна быть доставлена на mail-relay.fishfood.com.

■ Почта, адресованная на некто@ns.fishfood.com, должна быть передана по адресу mail-relay.fishfood.com.

Все это выглядит так, будто подстановочный символ должен полностью обеспечить обращение к ns.fishfood.com. Тогда зачем же нужен отдельный оператор? Правила для подстановочного символа гласят, что он может быть применен только к системам, не имеющим никаких других записей в базе данных DNS.

Числа, стоящие после MX, называются предпочтительными (preference numbers). Они будут рассмотрены в главе 16 при описании работы с электронной почтой.

12.14.8 Записи TXT и HINFO

Записи ТХТ не имеют никакого реального назначения, но позволяют администратору включить в базу данных произвольные комментарии.

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

12.15 Трансляция адресов в имена

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

> netstat -а

Active Internet connections (including servers )

Proto Recv-Q Send-Q Local Address Foreign Address    (state)

Tcp    0   121   tigger.nntp  c3po.4809       ESTABLISHED

Tcp    0    0   tigger.smtp  news.std.com.1472   TIME_WAIT

Tcp    0   925  tigger.1176  sun3.nsfnet-rela.smtp ESTABLISHED

Tcp    0    0  tigger.pop-3  ringotty8.16284    TIME_WAIT

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

Вспомним, что адреса размещаются в специальном домене IN-ADDR.ARPA и дерево этого домена должно расширяться от наиболее общей части адреса к менее общей. При этом порядок номеров в каждом адресе становится обратным. Поэтому поддерево сети 172.66 называется 66.172.in-addr.arpa. На рис. 12.7 показан обратный поиск записи.

66.172.in-addr.arpa. IN SOA NS.FISHFOOD.COM. (

               postmaster.FISHFOOD.COM.

                94101101 ; serial

                 86400 ; refresh after 24 hours

                  7200 ; retry after 2 hours

                2592000 ; expire after 30 days

                 345600 ; default TTL of 4 days

66.172.in-addr.arpa. IN NS  NS.FISHFOOD.COM.

1.1          IN PTR NS.FISHFOOD.COM.

66.172.in-addr.arpa. IN NS  NS2.FISHFOOD.COM.

100.1         IN PTR NS2.FISHFOOD.COM.

2.1         IN PTR MAIL-RELAY.FISHFOOD.COM.

Рис. 12.7. Таблица обратного просмотра

Элементы также будут обратными. Например, элементу 100.1 соответствует адрес 172.66.1.100.

12.16 Формат сообщений DNS

Обмен сообщениями запросов и ответов между клиентом и серверами DNS имеет простой формат. Сервер добавляет информацию ответа к исходному запросу и посылает полученное сообщение обратно. На рис. 12.8 показан полный формат сообщения.

Рис. 12.8. Общий формат сообщения DNS

12.16.1 Секция заголовка

Секция заголовка содержит поля, представленные в таблице 12.2.

Таблица 12.2 Поля заголовка сообщения DNS

Поле	Описание
ID Идентификатор	Служит для согласования запроса и ответа.
Parameters Параметры:	Запрос или ответ.
Обычный или обратный просмотр.
Является ли ответ авторитетным.
Является ли ответ усеченным.
Рекурсивно или нет сообщение.
Допустима ли рекурсия в ответе.
Для ответа — код ошибки.
Number of queries Количество запросов	Присутствует в запросе и ответе.
Number of answers Количество ответов	Присутствует только в ответе.
Number of authority records Количество авторитетных записей	Присутствует в ответе. Информация в авторитетных записях включает имя сервера, хранящего авторитетные данные.
Number of additional records Количество дополнительных записей	Присутствует в ответе и содержит адреса авторитетных серверов.

12.16.2 Секция запроса

Запрос имеет поля, перечисленные в таблице 12.3. Обычно сообщение содержит единственный запрос. Но можно в общей секции объединить несколько различных запросов.

Таблица 12.3 Поля запросов DNS

Поле	Описание
Name (Имя)	Имя домена или IP-адрес в поддереве IN-ADDR.ARPA
Type (Тип)	Тип запроса, например А или NS
Class (Класс)	IN для Интернета записывается как 1

12.16.3 Секция ответа

Сам ответ, информация об авторитетности и дополнительные сведения структурированы так же, как и в запросе. Ответ состоит из последовательности записей о ресурсах, содержащих поля, показанные в таблице 12.4.

Таблица 12.4 Поля записей о ресурсах

Поле	Описание
Name (Имя)	Имя узла для данной записи
Type (Тип)	Тип записи, например SOA или А, записанный числовым кодом
Class (Класс)	IN соответствует 1
TTL	Время жизни 32-разрядное целое число со знаком, отражающее время кеширования записи
RDLENGTH Длина записи	Длина поля данных в записи о ресурсах
RDATA Данные записи	Например, для записи об адресе — значение IP-адреса. Запись SOA содержит обширные сведения.

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

12.17 Используемый транспорт

Запросы и ответы DNS обычно пересылаются через UDP, но разрешается применять и TCP, который используется для переносов зон.

12.18 Примеры

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

Запрос требовал трансляции имени www.microsoft.com в адрес, а в ответе было получено два адреса. Дело в том, что два различных компьютера работают как сервер WWW компании Microsoft и разделяют между собой трафик от клиентов. Если клиент не получает ответа по первому адресу (возможно, при сильной загруженности этой системы), он может обратиться ко второму компьютеру.

> nslookup

Server: DEPT-GW.cs.YALE.EDU Address: 128.36.0.36

> set d2

> www.microsoft.com.

Server: DEPT-GW.cs.YALE.EDU Address: 128.36.0.36

res_mkquery(0, www.microsoft.com, 1, 1)

------

SendRequest(), len 35

HEADER:

 opcode = QUERY, id = 5, rcode = NOERROR

 header flags: query, want recursion

 questions = 1, answers = 0, auth. records = 0, additional = 0

QUESTIONS:

 www.microsoft.com, type = A, class = IN

------

------

Got answer (67 bytes):

HEADER:

 opcode = QUERY, id = 5, rcode = NOERROR

 header flags: response, auth. answer, want recursion,

 recursion avail.

 questions = 1, answers = 2, auth. records = 0, additional = 0

QUESTIONS:

 www.microsoft.com, type = A, class = IN

ANSWERS:

 -> www.microsoft.com

   type = A, class = IN, ttl = 86400, dlen = 4

   inet address = 198.105.232.5

 -> www.microsoft.com

   type = A, class = IN, ttl = 86400, dlen = 4

   inet address = 198.105.232.6

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

При повторном запросе ответ придет из кеша локального сервера. Так как информация не авторитетна, локальный сервер предоставляет в ответе имена и адреса авторитетных серверов для microsoft.com.

> www.microsoft.com.

Server: DEPT-GW.cs.YALE.EDU

Address: 128.36.0.36

res_mkquery(0, www.microsoft.com, 1, 1)

------

SendRequest(), len 35

HEADER:

 opcode = QUERY, id = 8, rcode = NOERROR

 header flags: query, want recursion

 questions = 1, answers = 0, auth. records = 0, additional = 0

QUESTIONS:

 www.microsoft.com, type = A, class = IN

------

------

Got answer (194 bytes):

HEADER:

 opcode = QUERY, id = 8, rcode = NOERROR

 header flags: response, want recursion, recursion avail,

 questions = 1, answers = 2, auth. records = 3, additional = 3

QUESTIONS:

 www.microsoft.com, type = A, class = IN

ANSWERS:

 -> www.microsoft.com

  type = A, class = IN, ttl = 86392, dlen = 4

   inet address = 198.105.232.5

 -> www.microsoft.com

   type = A, class = IN, ttl = 86392, dlen = 4

   inet address = 198.105.232.6

AUTHORITY RECORDS:

 -> MICROSOFT.COM

   type = NS, class = IN, ttl = 172792, dlen = 7

   nameserver = ATBD.MICROSOFT.COM

 -> MICROSOFT.COM

   type = NS, class = IN, ttl = 172792, dlen = 16

   nameserver = DNS1.NWNET.NET

 -> MICROSOFT.COM

   type = NS, class = IN, ttl = 172792, dlen = 7

   nameserver = DNS2.NWNET.NET

ADDITIONAL RECORDS:

 -> ATBD.MICROSOFT. COM

   type = A, class = IN, ttl = 187111, dlen = 4

   inet address = 131.107.1.7

 -> DNS1.NWNET.NET

   type = A, class = IN, ttl = 505653, dlen = 4

   inet address = 192.220.250.1

 -> DNS2.NWNET.NET

   type = A, class = IN, ttl = 505653, dlen = 4

   inet address = 192.220.251.1

Отметим, что в обоих запросах о www.microsoft.com. введена конечная точка. Если она опущена, запрос первоначально будет послан с добавленным в конец именем локального домена.

Это демонстрирует запуск запроса на компьютере Йельского университета, подключенном к cs.yale.edu. В следующем примере показаны происходящие при этом события. Запрос был отклонен, но далее автоматически переделан для исключения дополнительных обозначений в конце имени.

> www.microsoft.com

Server: DEPT-GW.CS.YALE.EDU

Address: 128.36.0.36

res_mkquery(0, www.microsoft.com.CS.YALE.EDU, 1, 1)

------

SendRequest(), len 47

HEADER:

 opcode = QUERY, id = 6, rcode = NOERROR

 header flags: query, want recursion

 questions = 1, answers = 0, auth. records = 0, additional = 0

QUESTIONS :

www.microsoft.com.CS.YALE.EDU, type = A, class = IN

...

12.19 Дополнительные типы записей

Одним из способов увеличения преимуществ Domain Name System является определение новых типов записей. За последние годы предложено множество таких типов. Полезные — добавлены в DNS, другие не вышли за рамки экспериментального применения.

Существуют определенные типы записей, используемые только в отдельных случаях, например в сетевом протоколе без установления соединений (Connectionless Network Protocol — CLNP) из третьего уровня модели OSI. Этот протокол рассматривается как часть Интернета.

В OSI используется адресация точек доступа к сетевым службам (Network Service Access Point — NSAP), обеспечивающая маршрутизацию данных на хосты. Поскольку для этого требуется отображение имен и адресов на хосты OSI, для баз данных DNS были определены записи с типом NSAP, обеспечивающие трансляцию имен в адреса. Обратное отображение обычно выполняется через записи с типом PTR.

Позже мы узнаем, что определен новый тип записи для трансляции имен в адреса IP версии 6.

12.20 Недостатки DNS

Domain Name System — очень важная система. Некорректные элементы базы данных могут сделать невозможным доступ к прикладным хостам. Поскольку многие администраторы используют распределенную базу данных с ручным вводом информации, весьма вероятно возникновение ошибок. К типичным проблемам DNS можно отнести:

■ Отсутствие точки в конце полного имени.

■ Отсутствие записей NS. Иногда новый сервер имен оказывается не внесенным в список везде, где на него должны присутствовать ссылки (например, в базе данных родительского домена).

■ Противоположная проблема — искаженное делегирование (lame delegation), когда запись NS для сервера имен перестает существовать. Это может причинить множество неудобств.

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

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

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

■ Псевдоним, ссылающийся на другой псевдоним.

■ Псевдонимы, указывающие на неизвестные имена хостов.

■ Адресная запись без соответствующей записи PTR.

■ Запись PTR без соответствующей адресной записи.

К счастью, существуют бесплатные программное инструменты для отладки баз данных DNS. Они описаны в RFC Tools for DNS Debugging (инструменты для отладки DNS).

12.21 Дополнительная литература

Для Domain Name System существует много документов RFC. Мы упомянем только наиболее важные из них.

RFC 1034 определяет концепции и возможности DNS. RFC 1035 описывает реализации и спецификации протокола для Domain Name System. В этих документах можно найти детальное описание форматов сообщений.

RFC 1713 специфицирует отдельные инструменты для отладки DNS. RFC 1912, 1536 и 1537 рассматривают общие ошибки конфигурирования DNS и недостатки реализаций, а также предлагает способы решения данных проблем.