Самоучитель системного администратора. 5-е изд

128 
Глава 3 
ние актуальной копии записей, поскольку при следующем запросе данных из 
этой зоны сервер загрузит копию с того сервера DNS, на который настроена
пересылка запросов. Поэтому при рассмотрении проблемных ситуаций следует 
выяснить на официальных ресурсах адреса NS-серверов нужного домена и про-
верить записи с помощью утилиты nslookup, подключаясь к соответствующему 
NS-серверу (см.
разд. «Обслуживание и диагностика неисправностей DNS-
сервера» далее в этой главе
). 
П
РИМЕЧАНИЕ
Для обновления записей DNS на клиентских компьютерах следует очистить кэш DNS-
записей командой 
ipconfig /flushdns
. 
Передача зон
— так называется специальная операция копирования всех запи-
сей той или иной зоны с одного DNS-сервера на другой. По соображениям без- 
опасности передача зон обычно разрешается только на заранее определенный
администратором системы список IP-адресов DNS-серверов. Если операция пе-
редачи зоны запрещена, то вы не сможете создать на своем DNS-сервере вто-
ричную зону для данного домена. 
Делегирование зон
— если на DSN-сервере создана, например, прямая зона для 
домена 
test.local
, то запись о домене третьего уровня 
level3.test.local
должна со-
держаться на этом же сервере. Если географически домен 
level3.test.local
удален 
от основного домена, то поддержание записей в его зоне на DNS-сервере стано-
вится не очень удобным. Проще поручить администратору этого домена вносить 
изменения в DNS-записи самостоятельно, для чего используется процесс деле-
гирования зоны. При делегировании зоны DNS-сервер создает у себя запись, 
указывающую, что запросы разрешения имени для этой зоны должны перена-
правляться на другой DNS-сервер, на который проведено делегирование зоны. 
Stub-зона (зона-заглушка)
— при делегировании зоны на исходном сервере со-
храняется информация о NS-сервере делегированной зоны. Поскольку админи-
стратор делегированной зоны может изменять ее DNS-записи, то он может сме-
нить и записи NS-сервера. Если соответствующее изменение не будет внесено 
на сервер, который осуществляет делегирование, то процесс разрешения имен 
будет нарушен (основной сервер по-прежнему станет отправлять запросы на уже 
не существующий адрес, и в результате будет формироваться неверный ответ). 
Для исправления подобной ситуации в DNS-сервере, начиная с Windows Server 
2003, введены stub-зоны. При создании stub-зоны в ней определяются NS-записи 
делегированной зоны. Причем, если администратор делегированной зоны меня-
ет эти записи, то соответствующие изменения вносятся и в записи stub-зоны.
В результате гарантируется целостность процесса разрешения имен. 
Зона «точка»
— домен самого верхнего уровня, как уже указывалось ранее, 
принято называть именем «точка». Если в DNS создать зону «точка» (зона с та-
ким именем создается при установке службы каталогов с одновременной уста-
новкой и настройкой сервера DNS), то это будет фактически означать, что этот 
сервер является корневым в структуре DNS (см. 
следующий раздел
), т. е. он 

Структура сети 
129 
должен разрешать самостоятельно любые запросы имен. Если этот DNS-сервер 
не может разрешить имя, то его ответ сообщит, что такого хоста не существует. 
П
РИМЕЧАНИЕ
При необходимости пересылки запросов DNS на другие серверы зону «точка» следует 
удалить, после чего появится возможность настройки пересылки запросов DNS. 
Порядок разрешения имен в DNS 
Для разрешения имен в DNS предусмотрено два типа запросов: итеративный и ре-
курсивный. 
Итеративный запрос
служит для получения от DNS-сервера, которому он направ-
лен, наилучшего ответа, который может быть получен 
без обращения
к другим 
DNS-серверам. 
Рекурсивный запрос
предполагает, что сервер DNS должен выпол-
нить все операции для разрешения имени. Обычно для этой цели необходимо
выполнить несколько запросов к различным серверам DNS. 
Процесс определения имени с использованием итеративных запросов весьма тру-
доемок. Необходимо найти NS-сервер нужного домена и затем запросить от него 
данные по требуемому имени. Обычно клиенты все эти операции возлагают на 
DNS-серверы, отправляя им рекурсивный запрос. 
DNS-сервер после получения рекурсивного запроса просматривает собственный 
кэш имен. Если он находит нужную запись, и она еще не устарела, то это значение 
возвращается клиенту. Если записи нет, то сервер предпринимает попытку поиска 
сервера имен для домена, содержащегося в запросе. Чтобы найти такой сервер, за-
прос 
всегда
отправляется на корневой сервер, далее от него получают информацию 
по домену первого уровня, запросом на домен первого уровня получают информа-
цию о NS-серверах домена второго уровня и т. д. После этого отправляется итера-
тивный запрос на NS-сервер соответствующего домена. Естественно, что большин-
ство информации от корневых доменов уже кэшировано на исходном сервере. 
Этим резко снижается нагрузка на сеть и уменьшается время ответа на запрос.
В результате запросы не доходят до корневых серверов, но сама цепочка разреше-
ния имени 
всегда выполняется от корня
до текущего домена. 
Обычно администраторы локальных DNS-серверов настраивают свой сервер на пе-
ресылку (forwarding) запросов разрешения имен на тот или иной сервер DNS 
(обычно это DNS-сервер провайдера). Тем самым вся процедура разрешения имен 
будет выполняться уже другим сервером. Поскольку мощные серверы Интернета 
обычно имеют существенно больший кэш и лучший канал подключения к глобаль-
ной сети, то таким способом достигается уменьшение времени ответа и снижение 
трафика. 
Основные типы записей DNS 
При создании первичной зоны для своего домена следует обратить внимание на 
добавление некоторых специальных 
записей ресурсов
(resource records), приведен-
ных в табл. 3.9. 

130 

жүктеу/скачать 20,51 Mb.

Достарыңызбен бөлісу: