Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

VPS с гибкой конфигурацией: за 1€

Мощные выделенные сервера: от 25€

Собственный Дата-Центр
Поддержка 24/7

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

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

Рекомендованная литература:

  1. P. Mockapetris. RFC-1034. DOMAIN NAMES - CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  2. P. Mockapetris. RFC-1035. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  3. Альбитц П., Ли К.. DNS и BIND. - Пер. с англ. - СПб: Символ-Плюс, 2002. - 696 с.

Полезные ссылки:

  1. http://www.fima.net/bind-8.html - это очень коротко про настройку BIND 8.x.x. На самом деле, прежде, чем это читать, нужно попрактиковаться с named. Но, в принципе С.Минаков снабдил всех желающих исчерповующей справочной информацией.

Назад Оглавление Вперед

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...