Установка и настройка первичной зоны

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

Введение

1. Общие сведения

1.1 DNS-сервер

1.2 Иерархия DNS

1.3 Регистрация доменов

1.4 Обратное преобразование имен

1.5 Серверы DNS

1.6 Ответы DNS сервера

1.7 Схема работы DNS сервера

1.8 Режимы работы DNS сервера

1.9 Типы записеи DNS

1.10 Серверы имен DNS

2. Конфигурация BIND сервера

2.1 VIEW

2.2 Программа named

2.3 Файлы настройки named

2.4 Расшифровка полей файлов зон

2.5 Создание файла зоны localhost.

3. Практическая реализация настройки сервера DNS

3.1 Программное обеспечение

3.2 Настройка DNS сервера BIND

3.3 Настройка зоны для домена

4. Проверка работоспособности системы

Заключение

Библиографический список

Приложение А

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

DNS (Domain Name System) - система доменных имён.

BIND (The Berkeley Internet Name Domain) - сервер имен Internet.

FQDN (Fully Qualifed Domain Name) - полностью определённое имя домена.

TLD (Top level domain) - Домен первого уровня

RTT (roundtrip time) - Время отклика

TCP (ransmission Control Protocol) - протокол управления передачей

UDP (User Datagram Protocol) - протокол пользовательских датаграмм.

SOA (State Of Authority) - сведения об ответственности.

UNIX (юникс) - семейство переносимых, многозадачных и многопользовательских операционных систем.

Linux (линукс) - общее название Unix-подобных операционных систем на основе одноимённого ядра, библиотек и системных программ, разработанных в рамках проекта GNU, а также другого программного обеспечения.

Ubuntu (убунту) - операционная система, использующая ядро Linux и основанная на Debian. Основным разработчиком и спонсором является компания Canonical.

ОС - операционная система

TCP/IP - transmission control protocol / internet protocol (протокол управления передачей)

ВВЕДЕНИЕ

Под системой доменных имен мы можем понимать такую систему, которая способна по запросу, содержащему доменное имя хоста сообщить IPадрес и/или какую либо другую информацию. В качестве домена, для которого настраивается DNS сервер, был выбран тестовый домен mysite.ru. Настройка проводилась в домашней сети на ОС Ubuntu. Основная задача настройки - внести необходимые нам изменения в конфигурационные файлы named.conf, которые определяют параметры функционирования сервера, описание прямой и обратной зоны, обеспечивает перенаправление и кэширование запросов.

1. Общие сведения

1.1 DNS сервер

DNS (Domain Name System, система доменных имён) - иерархическая, распределенная в сети система баз данных, предоставляющая пользователям сети Интернет дополнительный сервис (технически реализованный на компьютерах - DNS-серверах, на которых запущено специальное программное обеспечение) по автоматическому преобразованию запросов, оформленных в удобном для человека текстовом формате (например, www.amursu.ru) в цифровой IP-адрес компьютера (например, 192.1.1.1), где находится искомый ресурс. DNS была разработана Полом Мокапетрисом в 1983 году.

Другими словами, Служба Доменных Имен предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.

Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.

1.2 Иерархия DNS

Иерархию DNS чаще всего представляют в виде древовидной структуры, состоящую из узлов, зон, доменов, поддоменов и др. элементов. В основе этого дерева находится корневой домен "." (root). Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). За доменами первого уровня не закреплено никаких IP-адресов, они предназначены для создания на их основе (в их зонах) доменов второго уровня с последующим закреплением за ними IP-адресов.

Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные).

Зона -- это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для большего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (делегирование) за эту ветвь другому лицу или организации. На рисунке 1, примеры зон выделены синим градиентом (зона name., зона ius.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами).

В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит всю информацию о зоне, за которую он отвечает.



Домен -- это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы.

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Разница между зоной (zone) и доменом (domain) состоит в следующем: домен hogwarts.edu затрагивает все машины в школе hogwarts, в то время как зона hogwarts.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе астрологии. Хост в отделе обществознания принадлежат другой зоне, а именно social.hogwarts.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе -- слэш, а в DNS -- точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Таким образом, доменное имя полностью отражает структуру иерархии DNS. Часто, последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не ius.name., а ius.name).

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) -- это имя домена,однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Наглядно это можно рассмотреть на примере имени домена mail.ius.name:

Рисунок 2- Структура FQDN

Различие между FQDN и обычным доменным (не FQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.ius.name.). Максимальный размер FQDN -- 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это -- подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен ius является поддоменом домена name, а name, в свою очередь -- поддоменом корневого домена.

1.3 Регистрация доменов

Регистрация доменов -- это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть, в TLD зоны ru, com или др.),записи о новом доменном подимени.

Регистратор доменных имён -- это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:

корневой домен

· все домены первого уровня (TLD)

· некоторые домены второго уровня (например, com.ru или co.uk)

Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs….), необходимо получить аккредитацию ICANN.

Правила регистрации в международных (gTLD -- com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD -- ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.

Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например kurs4.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS хостера.

1.4 Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратным преобразованием имен или обратным отображением. Так как записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type -- PTR, а в поле Data -- FQDN-имя соответствующее данному IP.



Рисунок 3- Структура домена arpa

На схеме представлена структура домена arpa. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

1.5 Серверы DNS

Главный сервер DNS (он же первичный, он же master, он же primary) -- это авторитетный сервер, который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер -- тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный -- загружает (получает) настройки зон -- с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы не авторитетны, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (так называемый «невидимый»), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

1.6 Ответы DNS сервера

Ответы DNS бывают следующего типа:

· Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.

· Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Ответ DNS обычно содержит следующую информацию:

· Запись заголовка -- служебную информацию о запросе.

· Запись запроса -- повторяет отправленный запрос.

· Запись ответа -- собственно, сам ответ.

· Записи авторитетных серверов -- информацию об авторитетных серверах, хранящих информацию по текущему запросу.

· Дополнительную информацию -- дополнительные записи, например адреса NS-серверов.

1.7 Схема работы DNS сервера

DNS работает в режиме вопрос/ответ. Допустим, Вы ввели в строке своего браузера "amursu.ru".

Ваш браузер об IP-адресе amursu.ru ничего не знает и с запросом IP-адреса через специальную программу-resolver обращается к локальному серверу имен. Локальный DNS-сервер - это сервер имен Вашей локальной сети или DNS-сервер Вашего интернет-провайдера. При настройках сетевого подключения Вы прописываете IP-адреса DNS-серверов (предпочитаемого и/или альтернативного), один из которых будет отвечать на запросы, посылаемые Вашим браузером через resolver - это и есть локальный или местный сервер Вашей сети. Вы всегда можете посмотреть IP-адрес Вашего локального DNS-сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на Вашем компьютере.

Запрос на IP-адрес amursu.ru доходит до местного сервера имен. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов "." (root).

Корневой сервер отдает локальному серверу IP-адрес сервера, который поддерживает зону .ru.

Далее по полученному адресу локальный сервер имен обращается к DNS-серверу, который поддерживает .ru.

Этот DNS-сервер, в свою очередь, по полученному запросу отдает IP-адрес сервера, который поддерживает зону amursu.ru.

Местный DNS-сервер с запросом IP-адреса amursu.ru обращается к DNS-серверу зоны amursu.ru.

Локальный сервер имен получает IP-адрес amursu.ru. от DNS-сервера зоны amursu.ru.

Получив адрес amursu.ru, локальный DNS-сервер сообщает его Вашему браузеру.

1.8 Режимы работы DNS-сервера

DNS-сервер, выполняющий запрос клиента может работать в одном из трёх режимов:

· режим форвардинга (передачи) запросов другому DNS-серверу -- в этом случае запрос почти не отличается от запроса DNS-клиента. (Такая схема используется при использовании кеширующих DNS-серверов и серверов в DMZ).

· режим самостоятельного выполнения рекурсивного запроса.

· режим обслуживания зоны (в этом случае запросы на посторонние (неавторитативные) зоны не принимаются, вместо этого возвращаются адреса корневых серверов).

Во многих версиях BIND запрос к другим DNS-серверам исходил с 53-го порта (порта, по которому принимаются запросы DNS, как TCP, так и UDP), в отличие от клиентских приложений, использующих произвольный порт отправителя (из незарегистрированного диапазона).

1.9 Типы записей DNS

· Запись A (address record) или запись адреса связывает имя хоста с адресом IP. Например, запрос A-записи на имя referrals.icann.org вернет его IP адрес -- 192.0.34.164

· Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернет его IPv6 адрес -- 2001:7fd::1

· Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя. Мнемонические имена, или псевдонимы, широко применяются для связывания с хостом какой-либо функции, либо просто для сокращения имени. Реальное имя иногда называют каноническим. Например:

ius.ru. A 192.168.0.1

Если для хоста есть запись типа CNAME, которая содержит его мнемонические имена, другие записи для данного хоста должны ссылаться на его реальное (каноническое) имя, а не на мнемоническое. Когда программы DNS встречают запись CNAME, они прекращают свои запросы по мнемоническому имени и переключаются на реальное имя. Кроме того, если данное имя использовано в качестве псевдонима, то на него нельзя занести записи любого другого типа. Например:

ftp.ius.ru. CNAME ius.ru.

mail.ius.ru. CNAME ius.ru.

ssh.ius.ru. CNAME ius.ru.

Записи CNAME дают возможность доступа к Вашему домену через адреса ftp.ius.ru, mail.ius.ru, и т.д.. Без таких записей CNAME Вы не сможете подключиться к Вашему серверу по таким адресам.

· Запись MX(mail exchange) или почтовый обменник указывает серверы обмена почтой для данного домена. Приоритет: определяет значение приоритетности почтового сервера. Чем меньше число, тем выше приоритет почтового сервера (0 означает самый высокий приоритет, 65535 - самый низкий). Таким образом, почтовый сервер с более высоким приоритетом является основным, а почтовые серверы с более низкими приоритетами будут второстепенным и вступят в работу в том случае, если все более приоритетные серверы по каким-либо причинам недоступны или неработоспособны. Если Вы меняете запись MX таким образом, что почта будет обрабатываться другим сервером, все Ваши текущие аккаунты POP3, переадресации, почтовые роботы, и списки рассылки останутся без работы, то есть почта на них поступать не будет.

· Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP хоста в reverse форме вернёт имя (FQDN) данного хоста. Например, для IP адреса 192.0.34.164: запрос записи PTR 164.34.0.192.in-addr.arpa вернет его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии. Записи типа PTR (Pointer - указатель) служат для выполнения обратного преобразования IP-адресов в имена хостов. Для каждого сетевого интерфейса хоста рекомендуется создать запись PTR. Записи типа PTR, как правило, имеет смысл вносить только в обратные зоны Например, чтобы адресу 192.168.0.1 соответствовало www.ius.ru, запись должна выглядеть так:

1.0.168.192.in-addr.arpa PTR www.ius.ru.

· Запись NS (name server) указывает на DNS-сервер для данного домена. Количество записей типа NS в файле зоны должно точно соответствовать количеству DNS-серверов, обслуживающих домен и включать все DNS-серверы, указанные в домене. Для доменов второго уровня это DNS-серверы, указанные в полях "nserver".

· Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS-серверов.

1.10 Серверы имен DNS

§ BIND (Berkeley Internet Name Domain)

§ djbdns (Daniel J. Bernstein's DNS)

§ MaraDNS

§ NSD (Name Server Daemon)

§ PowerDNS

§ OpenDNS

§ MyDNS

2 КОНФИГУРАЦИЯ BIND СЕРВЕРА

В качестве DNS сервера использовалась система BIND версии 9.

BIND (Berkeley Internet Name Domain, до этого:Berkeley Internet Name Daemon) -- это открытая и наиболее распространённая реализация DNS-сервера, обеспечивающая выполнение преобразования DNS-имени в IP-адрес и наоборот. Система BIND состоит из основной программы-демона (named), набора библиотек разрешения имен позволяющих выполнять поиск имен, и ряда административных средств. Сервер имен - это сетевой сервис, который позволяет клиентам давать имена ресурсам или объектам и обмениваться этой информацией с другими объектами сети. Таким образом, достигается распределенная система баз данных для объектов в компьютерной сети. Сервер BIND работает в фоновом режиме, обслуживая запросы на известном сетевом порту. Стандартный порт для UDP и TCP описывается в /etc/services.

Определитель - это набор программ находящихся в системной библиотеке, обеспечивающей интерфейс, который могут использовать программы для доступа к сервисам имен домена.

Для решения вопроса какому из корневых серверов наш DNS-сервер отправит запрос, DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Файлы BIND:

· /usr/sbin/named. Демон сервера имен. Он прослушивает 53 порт ожидая поступления запросов поиска системы DNS.

· /etc/namedb. Все файлы конфигурации и файлы текущего состояния системы BIND, включая файлы определения зон, находятся в этом каталоге (или в созданных администратором подкаталогах).

· /etc/namedb/named.conf. Основной файл конфигурации системы BIND. Из него система BIND «узнает», какими доменами управляет и как работать с каждым и них.

2.1 VIEW

DNS сервер BIND 9-й версии позволяет работать с представлениями (VIEW) , что позволяет, например, разместить внутренний и внешний DNS на одном компьютере. Предположим, некая компания IUS поддерживает внутренний домен ius.ru и внешний домен ius.ru. Файл зоны внутреннего домена содержит имена внутренних компьютеров и их IP-адреса, а внешний домен имеет отдельный файл зоны, содержащий имена внешних компьютеров и их IP-адреса. Обычный DNS-сервер смог бы использовать лишь один файл зоны для домена ius.ru. BIND 9 позволяет единственному DNS работать с несколькими файлами зон для одного и того же доменного имени. Такой DNS умеет отличать внутренних клиентов от внешних по их IP-адресам и использовать для ответов соответствующие файлы зон.

2.2 Программа 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 у провайдеров, поддерживающих такую распределенную систему.

Любой сервер является кэширующим сервером. И primary, и secondary серверы запоминают на некоторое время, в своем буфере (cache) соответствие между именами и IP-адресами любой зоны, если к ней хоть раз обращались, и была выполнена процедура разрешения адреса. Это позволяет сократить обмен запросами между серверами и обеспечить более быстрое разрешение адреса для часто используемых ресурсов.

Организация на базе named только кэширующего сервера основано на том предположении, что primary и secondary серверы зоны могут быть перегружены запросами (типичный случай для большой организации). В этих условиях время на разрешение имени может быть довольно значительным. Кэширующий сервер на вашей вычислительной установке позволит несколько сократить это время если происходит постоянное обращение к одним и тем же хостам. Ждать придется только при первом обращении, когда будет выполняться стандартная процедура разрешения адреса, все последующие обращения будут удовлетворяться вашим кэширующим сервером.

Если число зон, к которым происходит обращение не очень велико, то для них имеет смысл сделать secondary server. При этом ни у кого регистрировать secondary server не надо. В этом случае для указанных зон просто создается долговременный кэш, который обслуживает только эту зону.

домен имя сервер программный

2.3 Файлы настройки named

Всего существует три типа файлов настройки программы named, или базы данных домена. К ним относятся:

· файл начальной загрузки буфера (cache);

· описания базы данных, он называется named.boot;

· файлы описания "прямой" и "обратной" зон.

В литературе по named принято начинать с файла описания базы данных named - named.boot. Этот файл named использует для своей настройки и первичной загрузки базы данных домена. Это первое, что ищет named при своем запуске. В случае отсутствия файла named.boot программа named не будет запущена.

В файле named.boot для описания настроек named используются следующие команды:

· directory - адрес директории в файловой системе компьютера, на котором запускается named.

· primary - определяет зону, для которой данный сервер является primary server, и имя файла базы данных этой зоны. Файл размещается в директории, которая указана в команде directory.

· secondary - определяет зону, для которой данный сервер является secondary server, а также определяет адреса других серверов для этой зоны, обычно primary server, и имя файла где будет вестись копия базы данных этой зоны. Файл размещается в директории, указанной в команде directory.

· cache - определяет имя кэш-файла. Обычно в кэш-файле описаны адреса и имена корневых серверов, которые данный сервер будет использовать для получения адресов удаленных серверов доменных имен.

· forwarders - данная команда определяет адреса серверов доменных имен куда следует отправлять не разрешенные запросы.

· slave - заставляет сервер отправлять все запросы на серверы, которые определены командой forwarders.

Фактически, forwarders и slave определяют какая из процедур разрешения запроса (рекурсивная или нерекурсивная) будут применяться на сервере. Если в файле named.boot есть команда slave, то определена рекурсивная процедура разрешения запроса, так как в этом случае named будет отсылать все запросы на серверы указанные в команде forwarders и от них получать адреса или имена удаленных хостов. В этом случае серверы из forwarders будут опрашивать корневые и удаленные серверы доменов. Если эти серверы также содержат команду slave, то поиск адреса или имени будут осуществлять серверы, которые определены в их файлах named.boot как forwarders.

В качестве сервера, на который осуществляется пересылка всех запросов, используется сервер всего домена. При этом с корневыми серверами общается только этот сервер, серверы зон самостоятельно на корневые серверы запросов не отправляют. Если число машин за пределами данного домена, с которыми общаются пользователи данного домена, не очень велико, и все они компактно расположены в других доменах, то центральный сервер домена быстро заполнит свой кэш необходимой для разрешения запросов информацией. При этом такой кэш будет только один, а работать он будет с той же скоростью, как если бы каждый из серверов зон создавал его у себя.

С точки зрения самого домена в любом случае сервер зоны обращается к серверу домена за адресами из другой зоны, если только сервер другой зоны не указан в файлах базы данных named.

2.4 Расшифровка полей файлов зон

Каждая зона должна включать запись типа SOA (State Of Authority, сведения об ответственности). В этой записи определяются основные временные и административные параметры домена, в том числе электронный адрес лица, ответственного за домен (администратора) и серийный номер зоны.

-2009051304 ; serial - серийный номер версии таблицы. Самый лучший формат - ГГГГММДДNN, где NN - номер изменения таблицы за текущий день

-108000 ; refresh - время в секундах, указывающее как часто необходимо проверять таблицу мастер-сервера на необходимость update-а

-3600 ; retry - время в секундах, которое сервер ожидает при ошибочном сеансе refresh-а чтобы начать его заново

-3600000 ; expirу - максимальный предел в секундах времени хранения таблицы, по его истечении таблица считается устаревшей и скачивается заново.

-86400 ; ttl - параметр time-to-live. Время в секундах, которое указывает серверу сколько хранить в кэше данные таблицы. По его истечении сервер перечитывает таблицу заново.

-NS - указывает name-серверы для данной зоны

-MX - указывает на почтовые серверы домена, очередность - 0,10,20,

-A - "прямая" запись ресурса (имя-адрес)

-PTR - "реверсивная" запись (адрес-имя)

-CNAME - псевдоним

Точка в конце некоторых названий означает, что не нужно дописывать название доменной зоны. Если ее не ставить, то сервер автоматически допишет название домена для которого данная таблица и составляется.

2.5 Создание файла зоны localhost

Для правильной работы необходимо создать специальный файл зоны localhost (0.0.127.in-addr.arpa). В каталоге /etc/namedb имеется сценарий make-localhost, помогающий создать такой файл. Сценарий читает шаблон (PROTO.localhost.rev) и заполняет его введенной администратором информацией.

Сгенерированный файл зоны localhost.rev

$TTL 3600

@ IN SOA ns.mysite.ru. admin.mysite.ru. (

20070909 ; Serial

3600 ; Refresh

900 ; Retry

3600000 ; Expire

3600 ) ; Minimum

IN NS ns.mysite.ru.

IN PTR localhost

Сервер запускается командой named.

3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ НАСТРОЙКИ DNS СЕРВЕРА

3.1 Программное обеспечение

Работа собственной библиотекой BIND дает дополнительные преимущества, так как, во-первых, можно будет работать с "умным" resolver, а, во-вторых, можно будет использовать новые относительно RFC-1034 и RFC-1035 возможности DNS.

BIND адаптирован для большинства современных компьютерных платформ. Практическая работа с системой доменных имен (администрирование серверов) тесно связана с практикой применения BIND.

Преимущества:

· Безопасность DNS (DNSSEC, TSIG)IPV6

· Улучшения в протоколе DNS (IXFR, DDNS, Notify, EDNSO)

· Более полное соответствие процедурам, описанным в протоколах

· Мультипроцессорная поддержка

· Улучшенная переносимость

· Поддержка подсхем пространства доменных имен

3.2 Настройка DNS сервера BIND

Чтобы не писать sudo для каждой команды запустим консоль от имени рута:

sudo -s

Затем установим сам DNS сервер bind:

apt-get install bind9

Судя по документациям и советам многих системных администраторов, bind настоятельно рекомендуют запускать в chroot среде. Для этого сначала остановим bind:

/etc/init.d/bind9 stop

Чтобы показать серверу, что он должен запускаться в chroot среде нужно отредактировать файл /etc/default/bind9:

nano /etc/default/bind9

Изменив в нем строку OPTIONS="-u bind" на OPTIONS="-u bind -t /var/lib/named"

Теперь нужно создать все необходимые для работы bind в croot среде директории:

mkdir -p /var/lib/named/etc

mkdir /var/lib/named/dev

mkdir -p /var/lib/named/var/cache/bind

mkdir -p /var/lib/named/var/run/bind/run

Далее перемещаем все текущие файлы конфигурации bind в созданный каталог:

mv /etc/bind /var/lib/named/etc

Чтобы Ubuntu могла найти файлы bind, например для обновления, создадим со старого места конфигов симлинк на новые:

ln -s /var/lib/named/etc/bind /etc/bind

в chroot-каталоге создадим null и random девайсы и установим права на директории:

mknod /var/lib/named/dev/null c 1 3

mknod /var/lib/named/dev/random c 1 8

chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random

chown -R bind:bind /var/lib/named/var/*

chown -R bind:bind /var/lib/named/etc/bind

Теперь нужно удалить настройку bind из apparmor, так как apparmor становится ненужным, при запуске bind в chroot окружении

rm /etc/apparmor.d/usr.sbin.named

Перезапускаем apparmor:

/etc/init.d/apparmor restart

и запускаем bind9:

/etc/init.d/bind9 start

3.3 Настройка зоны для домена

Самое время приступить к настройке зоны для нашего домена mysite.ru

Создадим файл конфигурации зон:

nano /var/lib/named/etc/bind/zones.conf

со следующим содержанием:

Рисунок 5- Создание файла конфигурации зон

и установим его владельца:

Chown bind:bind /var/lib/named/etc/bind/zones.conf

Отредактируем файл конфигурации bind, чтобы он цеплял конфигурацию зон:

nano /var/lib/named/etc/bind/named.conf

добавим в него строку include "zones.conf";

Получим:



Рисунок 6- Редактирование файла конфигурации

Осталось лишь создать файл нашей зоны mysite.ru :

nano /var/lib/named/etc/bind/mysite.ru

со следующим содержанием:

Рисунок 7- Создание файла зоны

После сохранения файла выставляем его владельца:

Chown bind:bind /var/lib/named/etc/bind/ mysite.ru

Все готово. Теперь осталось обновить конфигурацию bind командой

service bind reload

и проверить работу сервера:

Nslookup mysite.ru 127.0.0.1

Все работает верно, получаем такой ответ:

Server: 127.0.0.1

Address: 127.0.0.1#53

Non-authoritative answer:

Name: mysite.ru

Address: 192.168.43.216

4. ПРОВЕРКА РАБОТОСПОСОБНОСТИ СИСТЕМЫ

Выполним запросы подтверждающие работоспособность настроенного сервера:

Рисунок 8 - Тестирование сервера командой dig



Рисунок 9 - Тестирование сервера командой ping

ЗАКЛЮЧЕНИЕ

В ходе работы был изучен принцип работы DNS сервера и получены практические знания по установке и настройке DNS BIND. Я рассмотрела иерархическую структуру базы данных DNS, а так же процессы взаимодействия клиентов и серверов DNS, разновидности серверов DNS.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Paul Albitz, Cricket Liu «DNS and BIND, 5th Edition»

2. Интернет ресурс:http://ru.wikipedia.org/

3. Интернет ресурс: http://rubsd.org/doc/dns/

4. Интернет ресурс: http://help.ubuntu.ru

5. Интернет ресурс: http://linuxsoid.ucoz.com

6. Интернет ресурс: http://habrahabr.ru

7. Интернет ресурс: http://citforum.ru

8. Интернет ресурс: http://site-helper.ru

ПРИЛОЖЕНИЕ А

Измерение (benchmark) производительности полученной системы

Размещено на http://www.allbest.ru/

Рисунок 10 -



Размещено на http://www.allbest.ru/

Рисунок 11 - benchmark



Размещено на http://www.allbest.ru/

Рисунок 12 -

Размещено на Allbest.ru