Реферат система доменных имен dns
Обновлено: 04.07.2024
Задача DNS (Domain Name System) - преобразование символьного имени в IP-адрес и наоборот, а также предоставление некоторой дополнительной информации (например, информации о почтовых серверах и др.).
Сервер имен - это программа управления распределенной базой данных, в которой хранятся символьные имена сетей и хостов вместе с их IP-адресами. DNS является распределенной базой данных, построенной по иерархическому принципу. Не существует такого хоста в сети, на котором хранилась бы вся эта информация.
Доменное имя состоит из несколько полей (длиной не более 63 символов), разделенных точками. Имя может содержать не более 255 символов. Cтрочные и прописные символы в имени эквивалентны.
Анализ имени производится справа налево. Самая правая секция имени характеризует страну (каждой стране соответствует свой собственный двухсимвольный код) или характер организации, которой принадлежит домен (образовательная, коммерческая, правительственная и т.д.). Список основных типов организаций приведен в таблице:
Государственное учреждение (только в США)
Военная организация (только в США)
Сетеобразующая организация (интернет-провайдеры и проч.)
Специальный домен, предназначенный для преобразования IP -адреса в имя
Если имя домена не завершено символом точки, DNS может попытаться его дополнить именем локального домена. Например, если именем локального домена является "nord.nw.ru", то имя хоста "ns" будет дополнено названием домена и приведено к виду "ns.nord.nw.ru.". Если же имя домена завершается точкой - это значит, что имя указано полностью, это называется fully-qualified domain name (FQDN).
Если требуется запросить в DNS не адрес, соответствующий заданному имени, а наоборот, имя, соответствующее заданному адресу, тогда адрес преобразуется в специальную строку, которая отправляется в запросе серверу имен. В этой строке четыре числа адреса в десятичной форме переставляются в обратном порядке (т.к. в IP -адресе старшим байтом является первый, а серверы имен обрабатывают запросы справа налево) и дополняются суффиксом “. in - addr . arpa .”. Например, для определения имени, соответствующего адресу 192.168.1.2, серверу имен будет отправлен запрос, содержащий строку “2.1.168.192. in - addr . arpa .”.
Существует два вида запросов к серверам имен: рекурсивные и итеративные. Первый вид предполагает получение клиентом IP-адреса по заданному имени, а второй предназначен только для получения адреса сервера, который может сообщить адрес. В рекурсивном режиме обычно работают локальные серверы имен, которые предназначены для обработки запросов пользователей сети этой организации. В итеративном режиме работают серверы, обслуживающие большие домены, например, региональные.
В качестве транспорта DNS использует UDP (порт 53) (для обмена короткими запросами и ответами) или TCP (порт 53) (для пересылки больших объемов информации, например, некоторой зоны целиком).
Основные типы DNS -записей и запросов и типы классов запросов приведены в таблицах.
Компьютеры в сети общаются между собой, используя IP-адреса — числовые имена, имеющие такой вид: 217.107.217.21. IP-адрес можно сравнить с номером телефона — чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.
Содержание
Введение……………………………………………………………………4
Служба DNS…………………………………………………………5
Базовая конфигурация DNS…………………………………….6
DNS для разрешения имен……………………………………..10
Интеграция DNS с Active Directiry…………………………………17
Преимущества интеграции с Active Directiry………………….18
Планирование и администрирование DNS ………………………..22
Планирование DNS………………………………………………22
Администрирование DNS……………………………………….27
Добавление DNS……………………………………………29
Удаление DNS……………………………………………….29
Управление DNS…………………………………………….30
Защита инфраструктуры DNS………………………………34
Заключение…………………………………………………………………….36
Список литературы………………………………………
Работа содержит 1 файл
Курсовая ОССО.docx
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Государственное образовательное учреждение высшего профессионального образования
Курсовая работа
Студент гр.________ ___________________ Ю. И. Красавина
(номер группы) (подпись)
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
Государственное образовательное учреждение высшего профессионального образования
Задание на курсовую работу
Перечень вопросов, подлежащих рассмотрению:
- Структура DNS;
- Использование DNS для разрешения имен;
- Интеграция DNS с Active Directory;
- Планирование DNS;
- Администрирование DNS.
студент группы З8581 _____________ Красавина Ю. И.
- Служба DNS…………………………………………………………5
- Базовая конфигурация DNS…………………………………….6
- DNS для разрешения имен……………………………………..10
- Преимущества интеграции с Active Directiry………………….18
- Планирование DNS………………………………………………22
- Администрирование DNS……………………………………….27
- Добавление DNS……………………………………………29
- Удаление DNS……………………………………………….29
- Управление DNS…………………………………………….30
- Защита инфраструктуры DNS………………………………34
Компьютеры в сети общаются между собой, используя IP-адреса — числовые имена, имеющие такой вид: 217.107.217.21. IP-адрес можно сравнить с номером телефона — чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.
В данной работе будут рассмотрены следующие вопросы: конфигурация DNS (структура DNS и использование DNS для разрешения имен, интеграция DNS с Active Directory, планирование и администрирование DNS.
1. Служба DNS
Domain Name System (система доменных имен) – это стандарт службы имен для Интернета, который используется для помощи клиентам в разрешении имен узлов в их IP-адреса и для поиска служб в сети.
Cуществует еще один тип серверов имен, которые не являются полномочными для какой-либо зоны. Эти сервера называются caching-only (только кэширующими) – они просто перенаправляют запросы клиентов другим серверам имен и кэшируют их ответы.
Число серверов DNS, присутствующих в сети зависит от ряда факторов, таких, как потребность в отказоустойчивости, быстродействие и т.д.
В традиционных конфигурациях DNS имеется как минимум 2 DNS сервера, которые являются полномочными в зоне. Зона – это административная единица DNS, представленная набором серверов DNS, которые ответственны за поддержку информации, относящейся к одному или более домену или поддомену. Один сервер выступает как основной сервер имен и это единственный сервер, который поддерживает перезаписываемую копию файла зоны. Периодически, основной сервер имен реплицирует файл зоны на другой сервер (или сервера), назначенные вторичными серверами имен. Этот сервер (сервера) тоже поддерживает файл зоны, но копию, предназначенную только для чтения. Процесс репликации часто называют передачей зон. Главная причина для того, чтобы иметь 2 или более сервера DNS – это уверенность, что если один из них выйдет из строя, другой может быть доступен для обработки запросов, относящихся к домену, содержащемуся в файле зоны.
Установка конфигурации DNS предполагает решение двух задач: настройка сервера DNS (в пакете BIND функции сервера выполняет программа named) и администрирование домена. В данной работе рассмотрим особенности выполнения первой задачи. При настройке сервера DNS устанавливаются основные опции, указывается расположение других серверов DNS (в частности, серверов корневого домена) и задается информация о поддерживаемых зонах. Даже для небольшого домена необходим вторичный (ведомый) сервер имен. В принципе вы можете установить конфигурацию вторичного сервера, скопировав содержимое соответствующих файлов, созданных для локального сервера, но гораздо лучше настроить вторичный сервер так, чтобы от автоматически дублировал параметры первичного сервера.
Главный конфигурационный файл - BIND. Основные опции BIND задаются в главном конфигурационном файле с именем named. conf. Этот файл обычно располагается в каталоге /etc. В некоторых дистрибутивных пакетах Linux файл с опциями, установленными по умолчанию, в каталоге /etc отсутствует. В этом случае файл-образец надо искать в каталоге, содержащем документацию BIND (обычно это каталог /usr/share/doc/bind-версия).
Пример файла named, conf
directory "/var/named/"; auth-nxdomain yes; forwarders
434 _ Часть III. Серверы Internet
zone "0. 0.127.in-addr.arpa"
Файл named, conf состоит из нескольких разделов. Раздел options содержит определения глобальных опций, в частности, в нем задается каталог, в котором содержатся файлы с описанием зоны. Разделы zone описывают конкретные зоны - домены либо другие группы имен или IP-адресов. Большинство строк, содержащихся в файле named, conf, оканчиваются точкой с запятой (;). Это требование надо выполнять, в противном случае BIND может некорректно интерпретировать содержимое конфигурационного файла. В основном содержимое файла named. conf представляет собой указатели на файлы, в которых находятся дополнительные сведения о зонах. Эти файлы содержатся в каталоге /var/named либо в другом каталоге, заданном с помощью опции directory.
Одна из основных задач, которые вам предстоит решить при инсталляции сервера DNS, - получить список корневых серверов. Сделать это можно несколькими способами.
- Требуемый файл может входить в поставку пакета BIND. Обычно он называется named, са или db.cache и располагается в каталоге /var/named. Если содержимое этого файла устарело, вы можете получить новый файл одним из двух описанных ниже способов.
- Файл named, са, содержащий список корневых серверов, можно скопировать посредством протокола FTP, обратившись по адресу ftp://ftp.rs . internic. net/domain/.
Чтобы вы могли воспользоваться вторым или третьим из описанных выше способов, в вашей сети должен работать сервер DNS. Если сервер DNS в сети отсутствует, вы можете скопировать нужный файл, воспользовавшись компьютером другой сети, либо временно настроить компьютер, на котором должен быть установлен сервер DNS для преобразования посредством внешнего сервера имен.
Получив файл со списком корневых серверов, скопируйте его в каталог /var/named. Кроме того, вам следует убедиться в том, что ссылка на этот файл присутствует в конфигурационном файле /etc/named, conf.
BIND осуществляет преобразование имен одним из трех описанных ниже способов:
1. Если пакет BIND настроен для поддержки запрошенного имени, сервер возвращает адрес, указанный в его конфигурационном файле;
2. Если запрашиваемый адрес находится в кэше, сервер возвращает его. В этом случае повышается быстродействие и снижается нагрузка на сеть;
3. Если требуемый адрес в кэше отсутствует, сервер передает запрос корневому серверу и другим серверам. Типичная процедура преобразования имен была рассмотрена выше. Для выполнения преобразования требуется лишь несколько секунд, но чтение из кэша осуществляется гораздо быстрее.
DNS — Domain Name Service Служба Доменных Имен, предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Цель контрольной работы. Доменные имена. Как работает DNS-сервер
1. DNS-СЕРВЕР
Основной задачей DNS-сервера является трансляция доменных имен в IP-адреса и обратно.
DNS-сервер работает как хороший компьютерщик: он всегда либо знает ответ, либо знает у кого спросить.
Имеется некий домен верхнего уровня, обозначаемый точкой: ". ". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени — они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.
Клиент спрашивает своего сервера.
Если тот является сервером данной зоны, то ответит, на чем все заканчивается.
Сервер спрашивает корневой сервер.
Это приближенная модель, которая тем не менее позволяет представить работу системы DNS.
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd. org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.
Делегирование зоны… in-addr. arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS — сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd. org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.
Одна из проблем состоит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить права на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов
Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:
делегирование зоны… in-addr. arpa клиентам, имеющим пул адресов, кратный 256.
регистрация доменного имени клиента у держателя той зоны, в которой клиент хочет зарегистрироваться;
поддержание вторичного сервера прямой и обратной DNS-зон клиента;
поддержание первичного сервера этих зон, если клиент по какой-либо причине не поддерживает их сам (особенно это относится к случаю виртуальных зон и к случаю выделения малого пула адресов);
Политика и стратегия назначения имен
com — commercial (коммерческие)
edu — educational (образовательные)
gov — goverment (правительственные)
mil — military (военные)
net — network (организации, обеспечивающие работу сети)
org — organization (некоммерческие организации)
Рекурсивные сервера удобно использовать в локальных сетях
2. База данных DNS
Для каждого домена администратор ведет базу данных DNS. Эта база данных представляет собой набор простых текстовых файлов, расположенных на основном (первичном) сервере DNS (вторичные сервера периодически копируют к себе эти файлы). В файлах конфигурации сервера указывается, в каком именно файле содержатся описания каких зон, и является ли сервер первичным или вторичным для этой зоны.
Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:
[имя] [время] [класс] тип данные
Время задает интервал времени в секундах, в течение которого данные могут сохраняться в кэше сервера.
класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.
Тип может быть одним из следующих:
SOA — определяет DNS зону
NS — сервер имен для зоны
A — преобразование имени в IP-адрес
PTR — преобразование IP-адреса в имя
MX — почтовая станция
CNAME — имена машины
TXT — комментарии или какая-то другая информация
Есть также некоторые другие типы, но они намного менее распространены.
SOA — описание зоны
Теперь попробуем рассмотреть записи. Первой описываем зону:
21600; Refresh — 6 часов
1800; Retry — 30 мин
1209600; Expire — 2 недели
432000); Minimum — 5 дней
Refresh говорит вторичным серверам, как часто они должны проверять значение serial.
Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.
Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими.
Minimum задает время жизни записей по умолчанию для данной зоны.
NS описывает сервера имен
Теперь опишем сервера имен, обслуживающие наш домен:
Здесь ничего сложного нет. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.
A описывает хосты
Дальше идут записи A, описывающие ваши компьютеры и позволяющие преобразовать имена в IP-адреса.
major IN A 192.168.0.1
colonel IN A 192.168.0.2
localhost. IN A 127.0.0.1
localhost IN CNAME localhost.
C помощью CNAME можно задавать короткие имена серверов
Записи CNAME позволяют дать машинам удобные или значащие имена. Например:
MX описывает пересылку почты.
Реверсная зона позволяет определить имя по адресу
PTR преобразовывает адрес в имя.
Итак, мы создаем еще один файл зоны (для зоны, например, 0.168.192. IN-ADDR. ARPA), копируем в него запись SOA (а заодно и NS), после чего начинаем писать:
Можно задавать не только относительные, но и абсолютные имена:
Не забудьте еще задать обратное преобразование для 127.0.0.1.
Настройте трансфер зоны.
3. Система русских доменных имен
В настоящее время для работы с мультиязыковыми доменнными именами на компьютере клиента (например, посетителя сайта) должна быть установлена специальная программа, преобразующая символы национального алфавита в RACE-формат, который и используется при запросе к DNS.
В дальнейшем поддержка мультиязыковых доменов будет встраиваться непосредственно в операционные системы и браузеры. Для разработчиков ПО, желающих обеспечить поддержку национальных доменных имен в своих продуктах, компания VeriSing разработала бесплатный набор библиотек (SDK).
Учитывая сложность внедрения новой системы доменных имен, компания разделила ее тестовую эксплуатацию и ввод в строй на несколько этапов. Уже сейчас вы можете зарегистрировать доменное имя имя на русском языке, однако его делегирование будет произведено только по завершению создания необходимой инфраструктуры.
4. Принципы работы динамического DNS
Компьютер, подключающийся к сети Интернет, независимо от существующих на нем настроек, видится всем остальным по некоторому IP-адресу. Этот адрес может быть постоянным, прописанным в настройках компьютера и не изменяющийся при подключении к Сети, а может быть динамическим, присваиваемым ему на текущий сеанс связи провайдером. Во втором случае этот адрес при каждом подключении может оказываться отличным от предыдущего. Если же вы хотите, чтобы к вашему компьютеру могли обращаться ваши друзья или иные посетители, его IP-адрес должен быть постоянным.
Да, интернет-сервисы могут располагаться не только на специально выделенных для этого серверах, но и на домашних компьютерах. На таком компьютере может размещаться сайт, каталог файлов или картинок, почтовый или игровой сервер. Но если ваш IP-адрес будет динамическим, то при каждом подключении к Сети вам нужно будет посылать его своим постоянным посетителям, чтобы они могли попасть на ваш сайт. К тому же, подключаться к сайту им придется по IP-адресу, а не по его названию. Что делать, чтобы избежать подобной проблемы?
Сервис DDNS состоит из двух компонент. Первая — специальное ПО, работающее на удаленном компьютере. Вторая — клиентская программа, устанавливаемая на рабочее место. Первая компонента отвечает за взаимодействие со своим DNS, настройкой и поддержкой пользовательских аккаунтов. Клиентская часть обеспечивает связь с серверной, передает ей текущее значение выделенного для данного соединения адреса, обеспечивает некоторые дополнительные настройки.
Как уже говорилось, клиентская часть служит для передачи на сервис текущего значения IP-адреса. Но иногда возникают ситуации, что клиент вначале обнаруживает локальный IP-адрес компьютера и пытается передать на сервис его, а не тот адрес, который выдает провайдер. Для того чтобы избежать подобной ситуации, нужно внести локальный адрес в список игнорируемых адресов при настройке клиента.
Динамическое обновление IP-адресов.
Клиентская часть сервиса есть для таких платформ, как Windows 9x/NT/2000/XP, Mac OS, Mac OS X, Linux, FreeBSD, Solaris, Unix.
Бесплатный сервис обеспечивает поддержку таких алиасов, как ftp, mail, www и иных, привязанных к одному и тому же адресу. А платный сервис позволяет связывать любые поддомены с различными IP-адресами (например, если ваш веб-сервер и почтовый сервер размещены на различных компьютерах, имеющих раздельное подключение к Интернету).
Поддержка протокола SSL.
В то время, когда вы подключены к сервису, позволяет перенаправлять пользователей, запрашивающих вашу страницу, на любой другой сайт.
Распределение нагрузки на сервер.
При большой посещаемости вашего ресурса в платной версии сервиса имеется возможность использовать технологию RoundRobin. Она заключается в создании нескольких записей доменного имени с привязкой каждой из них к отдельному IP-адресу. Таким образом, посетители будут перенаправляться на различные компьютеры в зависимости от их загрузки.
Заключение
Все компьютеpы, объединенные в Internet, pаботают над упpавлением собственных опеpационных систем, но все они общаются между собой на едином языке компьютеpных сетей ТСР/IP (пpотокол упpавления пеpедачей над пpотоколом Internet). По сути это два пpотокола TCP/IP.
IP — (Internet Protocol) — опpеделяет, как будет выглядеть инфоpмация во вpемя путешествия по суше и что с ней делать, а также опpеделяет как pаботает система адpессации.
Каждый компьютеp в сети имеет свой адpес (4 цифpы) ТСР пpотокол — для опpеделения типа инфоpмации, содеpжащейся в пакете данных, а также следует, чтобы данные обязательно дошли до адpессата.
TCP пpотокол — опpеделения типа инфоpмации, содеpжащейся в пакете данных, а также следит, чтобы данные обязательно дошли до адpессата. Имена сеpвеpов в Internet опpеделяются, как стpоки, напpимеp, jsc. nasa. gov, однако, это не является действительной частью пpотокола TCP/IP. Существует унивеpсальный внешний механизм пpеобpазования таких имен в IP адpеса, котоpые понимает TCP/IP. Этот механизм называется Системой Доменных Имен (DSN), Т.о. нет необходимости знать IP адpеса компьютеpов, к котоpым мы хотим обpатиться. Напpимеp, если компьютеp А хочет знать IP-адpес компьютеpа jsc. nasa. gov, то он делает запpос на глобальный сеpвеp DNS. Этот сеpвеp не знает IP-адpеса, но зато знает сеpвеp-DNS, котоpый знает все адpеса, заканчивающиеся на nasa. gov и пеpесылает запpос на этот локальный сеpвеp, котоpый и сообщает А необходимый IP-адpес.
Список использованной литературы
1. Информатика: Учебник/под ред. Н.В. Макаровой. — М.: Финансы и статистика, 2000. — 768 с.
2. Информатика. Базовый курс. Учебник для Вузов / под ред. С.В. Симоновича, — СПб.: Питер, 2000.
3. Денисов А., Вихарев И., Белов А. Самоучитель Интернет. — Спб: Питер, 2001. — 461 с.
4. Коцюбинский А.О., Грошев С.В. Современный самоучитель работы в сети Интернет. М.: Триумф, 2007.
5. Основы современных компьютерных технологий: Учебное пособие / под. ред. Хомоненко. — СПб.: КОРОНА, 2005.
6. Симонович С.В., Евсеев Г.А., Практическая информатика, Учебное пособие. М.: АСТпресс, 2005.
7. Савельев А.Я., Сазонов Б.А., Лукьянов Б.А. Персональный компьютер для всех. Хранение и обработка информации. Т.1 М.: Высшая школа, 2001.
8. Тюрин Ю.Н., Макаров А.А. Статистический анализ данных на компьютере. Под ред.В.Э. Фигурнова. М.: ИНФРА-М, 1998.
9. Фигурнов В.Э. IBM PC для пользователя. М.: Инфра-М, 2001 г.
10. Фролов А.В., Фролов Г.В. Глобальные сети компьютеров. Практическое введение в Internet, E-Mail, FTP, WWW и HTML. М.: Диалог-МИФИ, 2006.
Наконец-то Internet приобретает человеческие черты. Сегодня любой желающий по- лучает от сети не только услуги электронной почты , но и полный доступ практически ко всем ресурсам Сети. К сожалению, в большинстве случаев используется так называемое "типовое PPP-подключение", реализуемое без приложения мысленных усилий с использо- ванием Windows95 и броузера WWW Explorer или Netscape.
Почему к сожалению? Дело в том, что использование "простейших" средств, как правило, приводит к получению простейших же результатов. Я уже писал о том, что исполь- зование более перспективной операционной системы Linux [1] позволяет повысить реальную пропускную способность арендуемого коммутируемого канала (телефонной линии) почти вдвое! Но и это не предел. В упомянутой мною публикации выигрыш достигался исключи- тельно за счет эффективной работы ядра операционной системы Linux, которая изначально ориентировалась на работу в сетях TCP/IP. Но этим возможности организации эффективной работы в сети никоим образом не исчерпываются! Возьмем хотя бы службу DNS.
Задача, казалось бы, тривиальная: таблица из двух полей и большого количества строк – нашел значение в одном поле, взял из второго, и все в порядке. Но на практике и разработчики, и пользователи столкнулись с несколькими препятствиями. Во-первых, не- прерывно растущая сеть постоянно увеличивает количество использованных IP-адресов, что приводит к разбуханию нашей таблицы соответствий до, прямо-таки скажем, просто непри- личных размеров. Во-вторых, информация в этой таблице подвержена непредсказуемым изменениям: узлы появляются и исчезают, меняют свои адреса и имена и так далее. И, нако- нец, самый неприятный момент – Internet не является однородной системой, управляемой чьей-либо "железной рукой" и раздача адресов IP (и присвоение им доменных имен) проис- ходит если и не совсем хаотично, то, во всяком случае, децентрализовано.
Выход из создавшейся ситуации "прогрессивно мыслящее человечество" усмотрело в создании глобальной информационной системы, обеспечивающей пользователей DNS- информацией "по запросу". При этом в сети одновременно функционирует достаточно большое количество серверов DNS, каждый из которых отвечает за свой участок сети и яв- ляется для этого участка "авторитетом". Наряду с авторитетными серверами в сети разме- щено огромное количество кэширующих серверов, каждый из которых копирует наиболее часто использующуюся информацию от авторитетов. Поскольку любая информация имеет тенденцию к устареванию, для каждой из кэшированных записей устанавливается опреде- ленный срок ее достоверности, по истечении которого сервер повторно запрашивает авто- ритетный сервер соответствующего домена.
Конечные пользователи, как правило, подключаются к DNS-серверам своих провай- деров, которые работают в режиме авторитетного сервера для своих пользователей и осуще- ствляют кэширование всех остальных запросов. С точки зрения пользователя Windows эта проблема по-другому и не решается, но как только вы переходите в UNIX и начинаете гово- рить с Internet на общем языке, у вас появляются весьма интересные возможности.
Одной из них является создание собственного локального кэширующего DNS-сервера.
В самом деле, при каждом обращении к удаленному узлу вам приходится запрашивать у провайдера IP-адрес. Клиентов, подобных вам, у провайдера несколько десятков , и на обслуживание вашего запроса уходит драгоценное время, которое, как вы можете заметить, если будете внимательно разглядывать строку состояния в Netscape Navigator или Explorer может составлять 30-40 секунд на каждом обращении к DNS . А при установке собственного сервера вы сможете: ? обеспечить максимальный уровень привилегий в обслуживании запросов DNS – вы ведь единственный и любимый пользователь; ? создать базу данных DNS узлов, к которым постоянно обращаетесь, и узнать из полученной информации немало интересного (подробнее об этом написано в [2]); ? ускорить процедуру установления соединения с серверами Internet.
Поскольку авторитетом для вашего IP-адреса (безразлично, статического или дина- мического) является ваш провайдер, вам достаточно установить простой кэширующий сер- вер. К счастью, программа сервера DNS – bind, едина для всех типов серверов (включая но- мер версии – 4.9.3), а конкретный режим работы определяется только параметрами настрой- ки. Сам же сервер входит в обязательном порядке во все дистрибутивы Linux, и нередко встречается в исходных текстах. Есть только одна неувязочка, о которой стоит предупредить заранее. Пакет c DNS-сервером и в RedHat и в Slackware называется bind (какой-нибудь вер- сии), но исполняемая программа сервера имеет совершенно другое название – named! По- этому, проверяя, не установлен ли сервер DNS в вашей системе, вам придется воспользо- ваться следующими командами: ps -ax " grepnamed Скорее всего, named в системе не установлен, но лучше все же проверить. Связано это с режимом последующего запуска сервера: первоначальный запуск осуществляется с помощью команды named, а перезапуск, при работающем сервере – командой named.restart. В любом случае, если в вашей изолированной системе уже запущен сервер DNS, его необхо- димо отключить, или, говоря на языке UNIX – "убить" соответствующий процесс .
Теперь необходимо проверить настройку сетевого интерфейса TCP/IP. Для того чтобы локальные серверы вашей системы могли обслуживать запросы локальных же клиентских программ, в TCP/IP предусмотрен специальный адрес IP, называемый localhost, который имеет значение 127.0.0.1.
Расхожее мнение гласит, что этот адрес в любом компьютере является синонимом адреса текущего компьютера и может использоваться наряду с обычным адресом при обра- щении к локальным ресурсам. Действительность же оказывается более суровой. Адрес localhost не может использоваться внешними пользователями для обращения к вашим ре- сурсам, поскольку при таком обращении любой компьютер начинает опрашивать только свои собственные ресурсы. В остальном адрес localhost подчиняется всем правилам, уста- новленным для адресов IP. А это означает, что вы должны не забыть прописать его в файле /etc/hosts, а также подключить маршрут доступа к этому файлу. Как ни странно, но довольно часто именно отсутствие этих двух простых настроек делает невозможным работу с серве- рами и клиентами TCP/IP. Но давайте по порядку.
Во-первых, база данных хостов сети /etc/hosts. Не отвлекаясь на исторические под- робности, отметим, что localhost прописан в ней обычно первой же строкой. За подробно- стями по содержанию этого файла отсылаю вас к статье [1] и к руководствам пользователя.
В случае если таблица маршрутизации, формируемая программой route, оказывается пуста, вам необходимо добавить в инициализационный файл настройку маршрута доступа к локальному узлу. Сделать это можно двумя способами: добавив целую подсеть: 127.0.0.0 или один только localhost. Я предпочитаю использовать более предсказуемый по своим по- следствиям второй путь: route add 127.0.0.1 Вообще говоря, для многозадачных и многопользовательских систем, к которым Linux можно отнести с куда большим основанием, чем нашумевшую Windows95 применимо одно важное правило: нужно вводить только те установки среды и конфигурации, которые необходимы для решения конкретных, текущих задач. Ну да ладно, после того, как мы включили в маршрут доступа (и в инициализационный файл) наш localhost, можно присту- пать к настройке собственно сервера DNS. Перегружать компьютер не нужно! Во-первых, мы еще не закончили, а во-вторых, все изменения вступают в силу немедленно после вы- полнения соответствующих утилит , и вы должны лишь позаботиться о том, чтобы необхо- димые настройки устанавливались при последующих запусках системы.
Итак, приступим к конфигурированию named. При загрузке сервер DNS осуществляет считывание собственного инициализационного файла, который обычно имеет имя /etc/named.boot. Вы, безусловно, можете изменить и каталог, и имя инициализационного файла, но для этого вам придется самостоятельно перекомпилировать named из исходных текстов, самостоятельно заменив указанное имя файла на альтернативное. Сложного в этом процессе ничего нет, но мы отвлекаться на это не будем.
Поскольку мы предполагаем реализовать только простейший, кэширующий сервер DNS, то и особых проблем с настройкой сервера пока не предвидится. Вот типовое содер- жание файла named.boot: ; ; Загрузочный файл кэширующего сервера DNS ; directory /var/namedcache .
root.cache В этом файле вы указываете компьютеру на два обстоятельства: ? Все остальные конфигурационные файлы сервера DNS размещаются в каталоге /var/named. Это традиционный каталог для их размещения, но если вам больше нравится, вы можете создать для этих целей подкаталог, например, в /etc.
? Сервер осуществляет только кэширование, при этом кэшированию подлежат все доменные имена (поскольку в поле домена указана точка – корень для любого доменного имени), а в файле /var/named/root.cache будет помещен набор корневых серверов сети, откуда named будет извлекать всю необходимую информацию.
Теперь самое время взглянуть на содержимое root.cache. В приведенном ниже при- мере помещено содержимое рабочего конфигурационного файла с моего компьютера. Не стоит мудрствовать, просто создайте такой же и пользуйтесь. Единственное замечание: все строки заполняются с первого символа – никаких пробелов "для красоты"! И не забудьте о точках в конце имен серверов.
; ; Список серверов DNS, являющихся конечными авторитетами ; для корня доменной системы имен (последние инстанции) ; .
Читайте также: