|
часть — нет. Поэтому перед предполагаемой сменой записей DNS необходимо
уменьшить время их жизни и выждать период, равный старому времени жизни. Это
позволит сократить период такой неопределенности в разрешении имен. После вы-
полнения операции настройки следует вернуться к старым величинам, чтобы снизить
нагрузку на сеть и DNS-серверы.
Если вы предполагаете, что копия DNS-записей на сервере DNS неактуальна, то
следует выполнить операцию
очистки кэша
для соответствующей зоны, для че-
го необходимо в консоли управления сервером включить опцию отображения
дополнительных параметров, найти нужную зону среди структуры кэша и вы-
полнить для нее очистку. Однако и эта операция также не гарантирует получе-
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
Do'stlaringiz bilan baham: |
