Типовые примеры описания зон и файлов конфигурации 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 (защищенных сегментов сети), настройкой динамического обновления описания зон и уведомлений об этих изменениях мы рассмотри несколько позже.
