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

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

Ответ.

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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