| ||||||||||||
| ||||||||||||
|
2004 г
Система доменных именМатериалы книги П.Б. Храмцоваiнфоцентр Типовые примеры описания зон и файлов конфигурации BINDВ данном материале мы даем короткий обзор наиболее типичных случаев, которые встречаются при организации работы с системой доменных имен. При этом мы опираемся и на потребности обычных пользователей, и на задачи, которые решают администраторы зон системы DNS. Архитектура "клиент-сервер", положенная в основу системы доменных имен заставляет сетевых администраторов решать задачи взаимодействия с DNS как со стороны обычных пользователей, так и с обратной стороны - точки зрения администраторов DNS. Когда речь заходит об организации поиска информационных ресурсов по их доменному имени, то сетевой администратор должен обеспечить для своих пользователей быстрый поиск IP-адресов по доменным именам в "прямых зонах" и поиск доменных имен по IP-адресам в "обратных" зонах. Типовым решением данной задачи является организация кэширующего сервера доменных имен, который должен обслуживать рекурсивные запросы к DNS с группы корпоративных хостов. Настройки данного типа сервера мы рассмотрим в материале "Настройка кэширующего локального сервера доменных имен". Современная особенность решения этой задачи состоит в том, чтобы сократить до необходимого минимума число обслуживаемых хостов и не порождать избыточного DNS трафика, а также избежать проблем с безопасностью. Вообще говоря, под "корпоративными хостами" мы понимаем некоторую группу хостов, которую обслуживает администратор DNS. Это могут быть хосты компании, вуза, министерства, отдела научно-исследовательского института и т.п. Эти хосты мы называем "корпоративными" по аналогии с "корпоративными доменами". Последнее словосочетание принято применять для доменов второго уровня, принадлежащим организациям. Второй круг проблем возникает в том случае, когда сетевой администратор реально отвечает за сервер, который является авторитативным для зоны. Это означает, что мы имеем дело либо с master сервером, либо со slave сервером зоны. В большинстве случаев настройка master сервера зоны просто расширяет настройки кэширующего сервера. Строго говоря, это справедливо только для BIND, да и то только в тех случаях, когда безопасность системы не ставится на первое место. Простейший переход от кэширующего сервера к master серверу зоны мы разберем в материале "Небольшой корпоративный домен в зоне ru". При этом мы постараемся указать на возможность повышения безопасности эксплуатации сервера. Поддержка slave сервера еще проще, чем поддержка master. В этом случае не нужно самому прописывать информацию в файлы описания зоны. Зона просто скачивается с master сервера. Этот вариант настройки сервера мы рассмотрим в материале "Настройка slave сервера для корпоративного домена". Кроме перечисленных случаев интерес представляют случай размещения зоны на двух сетях класса C (в нотации CIDR x.x.x.x/24) и размещение зоны на подсети класса C. Особенности работы с такого сорта доменами заключены в организации "обратных" зон. Этим вопросам будут посвящены материалы: "Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях типа /24" и "Делегирование обратных зон для подсетей сетей сети класса С (/24)" Отдельно следует рассмотреть вопрос делегирования поддоменов (материал "Делегирование поддомена внутри корпоративного домена"). Это связано с тем, что некорректное делегирование является одной из самых распространенных ошибок, которые встречаются в системе DNS. Проблемы с вязанные с повышением безопасности, организацией "расщепленных" доменов, работа из-под firewall (защищенных сегментов сети), настройкой динамического обновления описания зон и уведомлений об этих изменениях мы рассмотри несколько позже. Рекомендованная литература:
Полезные ссылки:
|
 | |||||||||
| |||||||||
|
CITForum © 1997–2025