- •2. Основы межсетевого обмена в сетях tcp/ip
- •2.1. Структура стека протоколов tcp/ip
- •2.2. Основные протоколы стека tcp/ip
- •2.2.1. Протоколы slip и ppp
- •2.2.2. Протокол arp. Отображение канального уровня на уровень межсетевого обмена
- •2.2.3. Протокол ip
- •2.8. Формат пакета Ipv4
- •2.2.4. IPing - новое поколение протоколов ip
- •2.2.6. User Datagram Protocol - udp
- •2.2.7. Transfer Control Protocol - tcp
- •2.3. Принципы построения ip-адресов
- •2.4. Подсети
- •2.5. Порты и сокеты
- •2.6. Основные принципы ip-маршрутизации
- •2.7. Настройка операционной системы и сетевые интерфейсы
- •2.8. Настройка сетевых интерфейсов
- •2.8.1. Настройка Ethernet-интерфейса
- •2.8.2. Настройка slip
- •2.8.3. Настройка интерфейса ppp
- •2.9. Маршрутизация, протоколы динамической маршрутизации, средства управления маршрутами
- •2.9.1. Статическая маршрутизация
- •2.9.2. Динамическая маршрутизация
- •2.9.3. Программа routed
- •2.9.4. Программа gated
- •2.10 Анализ и фильтрация tcp/ip пакетов
- •3. Информационные сервисы Internet
- •3.1. Система Доменных Имен
- •3.1.1. Принципы организации dns
- •3.1.2. Bind (Berkeley Internet Name Domain)
- •3.1.3. Регистрация доменных имен
- •3.1.4. Серверы доменных имен и механизм поиска ip-адреса
- •3.1.5. Настройка resolver
- •3.1.6. Программа named
- •3.1.6.1. Файлы настройки named
- •3.1.6.2. Запись "Start Of Authority"
- •3.1.6.3. Запись "Name Server"
- •3.1.6.4. Адресная запись "Address"
- •3.1.6.5. Запись Mail eXchanger
- •3.1.6.6. Запись назначения синонима каноническому имени "Canonical Name"
- •3.1.6.7. Записи типа "Pointer"
- •3.1.6.8. Запись типа hinfo
- •3.1.6.9. Запись определения информационных сервисов "Well Known Services"
- •3.1.6.10. Команды описания зоны
- •3.1.6.11. Файлы описания зоны
- •3.1.7. Примеры настроек программы named и описания зон
- •3.1.7.1. Небольшой поддомен в домене ru
- •3.1.7.2. Описание "прямой" и "обратной" зон для поддомена определенного на двух подсетях
- •3.1.7.3. Делегирование поддомена внутри домена
- •3.1.8. Программа nslookup
- •3.1.9. Dns и безопасность
- •3.2. Электронная почта в Internet
- •3.2.1. Принципы организации
- •3.2.2. Формат почтового сообщения (rfc-822)
- •3.2.3. Формат представления почтовых сообщений mime и его влияние на информационные технологии Internet
- •3.2.3.1. Поле версии mime (mime-Version)
- •3.2.3.2. Поле типа содержания тела почтового сообщения (Content-Type)
- •3.2.3.3. Поле типа кодирования почтового сообщения (Content-Transfer-Encoding)
- •3.2.3.4. Дополнительные необязательные поля
- •3.2.4. Протокол обмена почтой smtp (Simple Mail Transfer Protocol)
- •3.2.5. Интерфейс Eudora
- •3.2.6. Системы почтовой рассылки (программа sendmail)
- •3.2.6.1. Принцип работы программы sendmail
- •3.2.7. Настройка программы sendmail
- •3.2.7.1. Тестирование Sendmail и способы запуска
- •3.3. Эмуляция удаленного терминала. Удаленный доступ к ресурсам сети
- •3.3.1. Протокол Telnet
- •3.3.2. Интерфейс пользователя (telnet) и демон (telnetd)
- •3.3.2.1. Программа-сервер (telnetd)
- •3.3.2.2. Программа-клиент (telnet)
- •3.3.3. Организация модемных пулов, настройка оборудования. Квоты пользователей
- •3.4. Обмен файлами. Служба архивов ftp
- •3.4.1. Типы информационных ресурсов
- •3.4.2. Протокол ftp
- •3.4.3. Сервер протокола - программа ftpd
3.1.6. Программа named
К сожалению достаточно подробной единой документации по named, в которой было бы приведено достаточно большое множество примеров описания файлов настроек named для различных конфигураций доменов, в природе (в архивах сети Internet, да и в книгах, посвященных проблеме администрирования сетей TCP/IP) не существует. Данное описание также не претендует на полный обзор возможностей named, но позволяет некоторым образом упорядочить представление об этих возможностях. Кроме того, в данном разделе приводятся примеры из практики настройки этого сервера доменных имен, которые могут быть полезны в практической работе и отражают наиболее типичные случаи организации доменов.
Программа named является одним из наиболее популярных серверов доменных имен из тех, что используются в Internet. Для своей работы она использует 53 порты TCP и UDP.
При разработке named была реализована концепция функционирования трех типов серверов доменных имен: primary, secondary, cache. Если быть более точным, то named может одновременно выполнять функции всех трех типов серверов.
Primary server - это основной сервер зоны . В его базе данных описывается соответствие доменных имен и IP-адресов для машин, принадлежащих данной зоне. База данных сервера хранится на том же компьютере, где и функционирует сервер доменных имен. При запуске сервера последний обращается к файлам своей базы данных, после чего он становится способным отвечать на запросы разрешения доменных имен IP-адресами и обратно.
Secondary server - это дублирующий сервер зоны. Он также способен отвечать на запросы прикладных программ и других серверов, требующих разрешения доменных имен IP-адресами и/или наоборот, как и primary server. Главное отличие от primary server заключается в том, что secondary server не имеет своей базы данных зоны, а копирует ее с primary server в момент своего запуска и затем заботится о поддержке соответствия между скопированной базой данных и базой данных primary server в соответствии с настройками последнего.
Caсhe server - это сервер, который запоминает в своем буфере (caсhe) соответствия между именами и IP-адресами и хранит их некоторое время. Если пользователь достаточно часто обращается к каким-либо ресурсам сети, то в случае использования caсhe-сервера он всегда будет быстро получать IP-адрес или доменное имя, т.к. его прикладное программное обеспечение будет пользоваться услугами caсhe-сервера. При этом обращение к местному серверу зоны, корневому серверу и удаленным серверам зон будут осуществляться только один раз - в момент первого обращения к ресурсу.
Для организации зоны (домена) необходимо иметь primary server и, как минимум один secondary server. Если с primary server все более или менее понятно - он создается на компьютере, который входит в описываемый домен и управляется администратором домена, то размещение secondary server всегда вызывает определенные трудности. Как уже говорилось выше, его можно создать на другом компьютере домена и тем самым формально выполнить условия по организации двух серверов доменных имен для одной зоны . Но в этом решении есть два нюанса. Во-первых, организация второго сервера доменных имен заставляет устанавливать либо еще одну Unix-машину, либо Windows NT, в которых есть поддержка BIND. Во-вторых, с точки зрения надежности secondary server лучше всего размещать у провайдера, т.к. обычно именно он делегирует зону из своего домена, и через его сервер доменных имен по рекурсивной или нерекурсивной процедуре разрешения имени весь остальной мир получает доступ к машинам вашего домена.
Если же домен распределен по нескольким сетям или подсетям, которые к тому же и территориально расположены в разных зданиях или различных частях города, или даже в разных городах, то тогда для каждой из этих частей домена следует организовать secondary server, что не отменяет размещения secondary server у провайдеров, поддерживающих такую распределенную систему.
В любом случае secondary server всегда не один, но каждый администратор должен сам решать сколько их надо заводить. Кроме этого если сервер заводится у коммерческого провайдера, то за него придется платить.
О второй Unix-машине или Windows NT было упомянуто из тех соображений, что многие маленькие локальные сети строятся по схеме, в которой многозадачная и многопользовательская операционная система ставится только на машине-шлюзе, через которую локальная сеть подключается к сети провайдера. На всех остальных машинах устанавливается либо Windows 95, либо MS-DOS, одним словом персональная операционная система.
Совершенно очевидно, что выделять еще одну машину для общественных нужд не очень хочется, а свою собственную зону иметь желательно. Поэтому, либо обращаются к провайдеру с запросом на размещение secondary server, либо договариваются с кем-то еще.
Любой сервер является кэширующим сервером. И primary, и secondary серверы запоминают на некоторое время, в своем буфере (cache) соответствие между именами и IP-адресами любой зоны, если к ней хоть раз обращались, и была выполнена процедура разрешения адреса. Это позволяет сократить обмен запросами между серверами и обеспечить более быстрое разрешение адреса для часто используемых ресурсов.
Организация на базе named только кэширующего сервера основано на том предположении, что primary и secondary серверы зоны могут быть перегружены запросами (типичный случай для большой организации). В этих условиях время на разрешение имени может быть довольно значительным. Кэширующий сервер на вашей вычислительной установке позволит несколько сократить это время если вы постоянно обращаетесь к одним и тем же хостам. Ждать придется только при первом обращении, когда будет выполняться стандартная процедура разрешения адреса, все последующие обращения будут удовлетворяться вашим кэширующим сервером.
Если число зон, к которым вы обращаетесь не очень велико, то для них на вашей вычислительной установке имеет смысл сделать secondary server для этих зон (если конечно позволяют ресурсы вашего компьютера). При этом ни у кого регистрировать ваш secondary server не надо. В этом случае для указанных зон вы просто создаете долговременный кэш, который обслуживает только вашу зону.
От общего описания типов серверов, которые можно организовать при помощи программы named прейдем к файлам ее настройки.