Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

Примером может служить система 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

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

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

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

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

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