Dns сервер курсовая работа

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

СОДЕРЖАНИЕ

Введение

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

.1 DNS-сервер

.2 Иерархия DNS

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

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

.5 Серверы DNS

.6 Ответы DNS сервера

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

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

.9 Типы
записеи DNS

.10 Серверы
имен DNS

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

.1 VIEW

.2 Программа named

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

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

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

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

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

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

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

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

Заключение

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

Приложение А

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

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

BIND (The Berkeley Internet Name Domain) — сервер имен
Internet.(Fully Qualifed Domain Name) — полностью определённое имя домена.

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

RTT (roundtrip time) — Время отклика(ransmission Control Protocol) — протокол управления передачей(User Datagram Protocol) —
протокол пользовательских датаграмм.

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

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

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

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

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

ВВЕДЕНИЕ

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

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

1.1    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 <#»657071.files/image001.jpg»>

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

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

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если
провести аналогию с файловой системой Linux, система доменных имен имеет похожую
структуру, за тем исключением, что разделитель в файловой системе — слэш, а в
DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к
имени хоста) в отличии от пути в файловой системе Linux. Доменное имя
начинается с точки (корневого домена) и проходит через домены первого, второго
и если нужно третьего и т.д. уровней и завершается именем хоста. Таким образом,
доменное имя полностью отражает структуру иерархии DNS. Часто, последняя точка
(обозначение корневого домена) в доменном имени опускается (то есть в браузере
мы вводим не ius.name., а ius.name). (англ. 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 <#»657071.files/image003.jpg»>

Рисунок 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 бывают следующего типа:

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

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

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

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

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

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

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

1.7 Схема работы 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-серверов и серверов в 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
<#»657071.files/image005.gif»>

Рисунок 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: 127.0.0.1#53authoritative answer:: mysite.ru: 192.168.43.216

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

2.      Интернет
ресурс:#»657071.files/image010.jpg»>

Рисунок 10 —

Рисунок 11 — benchmark

Рисунок 12 —

Образцы страниц

Содержание

Введение

Фрагмент работы для ознакомления

Список литературы [ всего 23]

Доменное имя состоит, по меньшей мере, из двух частей (меток), разделенных точками. Нумерация меток ведется справа налево. Если объяснить на конкретном примере, то в адресе hosting.web-3.ru суффикс ru является доменом первого уровня. Все последующие метки — поддомены, т.е. hosting — поддомен домена web-3, а web-3 — домена ru.Условно подобное деление может растянуться на 127 уровней. Любая метка может состоять (максимально) из 63 символов, но длина доменного имени не может быть больше 254 знаков, включая точки. Впрочем, действительность и теория, как известно, — разные вещи, посему регистраторы доменов часто устанавливают собственные лимиты.Серверы DNS находятся в определенном порядке, который организует иерархическая система DNS. Всякий поддомен или домен поддерживается несколькими авторизованными серверами DNS, содержащими о нем все необходимые сведения. Следует сказать, что наблюдается тождество соподчинения доменов и серверов DNS.Система DNS работает следующим образом: Пользователь набирает в web-обозревателе адрес hosting.web-3.ru. Для передачи данных посредством стека протоколов TCP/IP необходимо знать IP-адрес указанного сервера, но тот, как правило, имеет лишь сведения об адресе сервера DNS (обычно интернет-провайдер предоставляет адрес одного основного и одного резервного DNS-сервера). В результате запрос об IP-адресе hosting.web-3.ru задается указанному DNS серверу. Тот, в свою очередь, запрашивает информацию у центрального сервера, например 195.42.0.3 (все IP-адреса приведены в качестве примера и могут отличаться от действительных). Сервер отвечает, что не обладает информацией о требуемом адресе, однако, знает, что доменной зоной .ru занимается сервер 214.74.142.1 (прим. ред. Это так называемый авторитетный сервер). В этом случае сервер DNS запрашивает информацию у 214.74.142.1. Ответом может быть: «web-3.ru занимается сервер 247.142.130.234». Этот третий по счету сервер возвращает браузеру IP-адрес нужного сайта (прим. ред. Очень часто рекурсивный подход заменяется запросами к буферу сервера. Если неавторитетный сервер недавно получал запрос на IP адрес hosting.web-3.ru, то вместо обращения к следующему DNS серверу он выдаст результат из буфера. Для реагирования на запрашиваемую информацию DNS-протокол применяет UDP- или TCP-порт 53. Обычно запросы и готовая информация по ним посылаются в форме UDP-датаграммы. А TCP остается для AXFR-запросов или ответов весом более 512 байт. Для того чтобы узнать IP-адрес интересующего вас сайта, необходимо воспользоваться командой ping. Если вы пользуетесь операционной системой Windows XP, нажмите «Пуск»- «Выполнить» (прим. ред. Сочетание клавиш win+r) и наберите в строке команду cmd. Появится окошко командной строки. В ней наберите команду ping и имя сайта, например, ping hosting.web-3.ru. В строчках, которые появятся после нажатия Enter увидите группу чисел 87.242.76.88 — это и есть IP-адрес сайта hosting.web-3.ru. Важно помнить, что IP-адрес не равен имени хоста и наоборот. Один компьютер может иметь большое количество web-сайтов, а это говорит о возможности хоста с определенным IP-адресом владеть целым списком имен. Подобно этому одно иметь может быть соотнесено с разными хостами. Так достигается регуляция нагрузки. С целью увеличения стабильности системы в работу вводят определенное число серверов, которые вмещают в себя одинаковые сведения. Так, в мире насчитывается 13 подобных серверов. Каждый имеет отношение к какой-либо территории. Данные о них имеются во всякой операционной системе, поскольку такие серверы не изменяют первоначального адреса. Эти сервер называют корневыми, потому что на них держится вся сеть Интернет. Теперь поговорим об обратном DNS-запросе. Помимо перекодировки символьных имен в IP-адреса DNS выполняет обратную работу. Поскольку с записями DNS можно соотнести данные разных форматов, включая символьные. Известно доменное имя in-addr.arpa, данные которого служат для реконструирования IP-адреса в имя из символов. Приведем пример: чтобы выяснить имя известного адреса (предположим, 12.13.14.15) допустимо сделать запрос в следующем виде: 51.41.31.21.in-addr.arpa. Результатом окажется должное символьное имя. Чем можно это объяснить? Тем, что в IP-адресах биты, расположенные у корня, стоят в начале, а в DNS-именах – в конце. Что касается записей DNS, то выделяют несколько категорий:

Address record (запись А) служит для связи адреса IP и хоста.

Canonical name record (сокращенно CNAME, каноническая запись имени) – инструмент переадресации на альтернативное имя.

Mail exchange (МХ, почтовый обменник) ссылается на сервер обмена почтой для представленного домена.

PTR (pointer, или запись указателя) соединяет имя хоста с его установленным (каноническим) именем.

NS (name server) называет DNS-сервер представленного доменного имени.

SOA (start of authority record) – запись, ссылающаяся на тот сервер, который содержит стандартные сведения о представленном домене.

Необходимо сказать о зарезервированных доменах (Reserved Top Level DNS Names). Документ RFC 2606 указывает на те имена доменов, которые нужно применять в роли модели (что особенно важно в документации) и при тестировании. В качестве примера можно привести test.com, test.org, test.net, а также invalid, example и т.д. В разговоре о доменных именах стоит упомянуть о том, что они могут состоять из небольшой комплектации ASCII символов. Это делает возможным набор доменного адреса вне зависимости от того языка, на котором говорит пользователь. Потому такие имена – интернациональные. ICANN ратифицировал систему IDNA, базирующуюся на Punycode. Она способна конвертировать всякую фразу в кодировке Unicode в тот набор знаков, который будет возможен для корректной работы DNS.Некоторые способы действия приложения DNS применяются в BIND (Berkeley Internet Name Domain), MaraDNS NSD (Name Server Daemon), DJBDNS (Daniel J. Bernstein’s DNS), PowerDNS Microsoft DNS Server (в серверных вариантах операционных систем Windows NT).Чтобы узнать, кто владеет каким-либо доменом или IP-адресом достаточно использовать возможности сетевого протокола whois (от англ. who is — «кто?»). Первоначальной идеей, положившей начало созданию данной системы, было стремление не позволять системным администраторам находить данные иных администраторов IP-адресов и доменов. Ныне доменное имя признается незарегистрированным на определенное имя, пока нельзя найти общедоступные сведения о нем в этом сервисе.

Компьютер, подключающийся к сети Интернет, независимо от существующих на нем настроек, видится всем остальным по некоторому IP-адресу. Этот адрес может быть постоянным, прописанным в настройках компьютера и не изменяющийся при подключении к Сети, а может быть динамическим, присваиваемым ему на текущий сеанс связи провайдером. Во втором случае этот адрес при каждом подключении может оказываться отличным от предыдущего. Если же вы хотите, чтобы к вашему компьютеру могли обращаться ваши друзья или иные посетители, его IP-адрес должен быть постоянным.

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

Один способ — приобрести у провайдера постоянный адрес и использовать его. Весьма простая ситуация, но не бесплатная. За такое «удовольствие» придется выкладывать вполне ощутимую сумму. Но в последние годы появились иные возможности обеспечить доступ к компьютеру из Интернета, не требующие при этом обращения к провайдеру. Появившиеся службы (Dynamic DNS сервисы) позволяют это делать для динамически выделяемых адресов. Базовые услуги ими, как правило, предоставляются бесплатно, а вот за дополнительные возможности придется платить.

Сервис DDNS состоит из двух компонент. Первая — специальное ПО, работающее на удаленном компьютере. Вторая — клиентская программа, устанавливаемая на рабочее место. Первая компонента отвечает за взаимодействие со своим DNS, настройкой и поддержкой пользовательских аккаунтов. Клиентская часть обеспечивает связь с серверной, передает ей текущее значение выделенного для данного соединения адреса, обеспечивает некоторые дополнительные настройки.

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

Небольшое отступление. Такой вариант оказывается очень удобным при наличии ADSL-подключения, когда у компьютера долгое время остается один и тот же адрес, а переподключения бывают весьма редкими. При подключении к Сети с помощью модема ситуация несколько усложняется тем, что смена IP-адреса бывает намного чаще, к тому же, в промежутках между подключениями связанный с доменом адрес будет выдаваться кому-либо иному. В результате посетители домена будут получать сообщение о том, что искомая страница не найдена. Но на такие издержки приходится идти, если используется только модемное соединение.

Размещая интернет-сервисы на своем домашнем компьютере, нельзя забывать о необходимости его защиты. Как только вы предоставите возможность доступа извне, к вам начнут «заходить» не только посетители, но и любители легкой наживы, распространители троянов, вирусов и прочих гадостей. Поэтому в обязательном порядке необходимо устанавливать как антивирусное ПО, так и файрволы. Но в этом случае потребуется дополнительная настройка. Вам придется открыть для доступа порты, к которым вы привяжете свои сервисы. Это могут быть как стандартные порты (например, порт 80 для веб-сервера), так и нестандартные (прежде чем назначать нестандартные, порты убедитесь, что сервис DDNS поддерживает перенаправление запросов со стандартных портов на нестандартные). Наиболее часто переназначение стандартного порта требуется в случае установки почтового сервера. Провайдеры, как правило, запрещают доступ к 25 порту, поэтому его приходится переназначать на другой порт.

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

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

Рассмотрим, какие услуги и возможности предлагают DDNS-сервисы. Возьмем, к примеру, сервис Dynu.com.

Поддержка доменов

Бесплатный сервис обеспечивает поддержку поддоменов в доменах dynu.com и dynu.net. Домены в зонах *.com, *.net, *.biz, *.co.jp, *.de и других поддерживаются в платном сервисе.

Динамическое обновление IP-адресов

Клиентская часть сервиса есть для таких платформ, как Windows 9x/NT/2000/XP, Mac OS, Mac OS X, Linux, FreeBSD, Solaris, Unix.

Поддержка поддоменов (алиасов) зарегистрированного домена

Бесплатный сервис обеспечивает поддержку таких алиасов, как ftp, mail, www и иных, привязанных к одному и тому же адресу. А платный сервис позволяет связывать любые поддомены с различными IP-адресами (например, если ваш веб-сервер и почтовый сервер размещены на различных компьютерах, имеющих раздельное подключение к Интернету).

Поддержка протокола SSL

Перенаправление HTTP-порта

Позволяет перенастроить стандартный HTTP-порт (80) на любой другой. Ваш веб-сервер, соответственно, должен быть настроен на нужный порт.

Онлайн-перенаправление

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

Распределение нагрузки на сервер

При большой посещаемости вашего ресурса в платной версии сервиса имеется возможность использовать технологию RoundRobin. Она заключается в создании нескольких записей доменного имени с привязкой каждой из них к отдельному IP-адресу. Таким образом, посетители будут перенаправляться на различные компьютеры в зависимости от их загрузки.

Другим популярным сервисом считается DNS2Go. Большинство предоставляемых услуг являются бесплатными. По своей функциональности сервис очень близок к сервису Dynu.com, а вот бесплатных возможностей дает несколько больше. Но, к примеру, получить домен второго уровня на этом сервисе можно только на платной основе. Кроме уже перечисленных возможностей, DNS2Go предоставляет услуги по перенаправлению электронной почты (услуга — платная). Она включает защиту от вирусов и спама, перенаправление почты, пересылку на иной адрес, хостинг почтового сервера. Услуга может быть полезной тем, кто не может держать установленный на домашнем компьютере почтовый сервер, постоянно подключенный к Интернету.

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

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

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

Компьютеры в сети общаются между собой, используя IP-адреса — числовые имена, имеющие такой вид: 217.107.217.21. IP-адрес можно сравнить с номером телефона — чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.

В интернете роль записной книжки играет DNS — Domain Name System, система доменных имен. Каждый сайт в сети имеет свое доменное имя (например, www.jino.ru), которое система DNS связывает с IP-адресом сервера — компьютера, на котором расположен этот сайт. И когда в адресной строке браузера вы вводите какой-либо домен, он автоматически преобразовывается в IP-адрес, и уже используя его, ваш компьютер связывается с сервером. Сама схема определения IP-адреса по имени домена (см. рисунок) довольно сложна и многоступенчата, и именно из-за этого возникает большинство проблем при регистрации и переносе доменов.

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

Компьютеры в сети общаются между собой, используя IP-адреса — числовые имена, имеющие такой вид: 217.107.217.21. IP-адрес можно сравнить с номером телефона — чтобы один компьютер мог обратиться к другому, ему необходимо знать его IP-адрес. Однако у IP-адресов есть два недостатка: во-первых, их существует лишь ограниченное количество (что нам сейчас не очень важно), а во-вторых, что важнее, IP-адрес очень трудно запомнить человеку. Продолжая аналогию с телефонными номерами, помните ли вы номера телефонов всех своих друзей и знакомых? Вероятно, нет. Но вы всегда можете воспользоваться записной книжкой.

В интернете роль записной книжки играет DNS — Domain Name System, система доменных имен. Каждый сайт в сети имеет свое доменное имя (например, www.jino.ru), которое система DNS связывает с IP-адресом сервера — компьютера, на котором расположен этот сайт. И когда в адресной строке браузера вы вводите какой-либо домен, он автоматически преобразовывается в IP-адрес, и уже используя его, ваш компьютер связывается с сервером. Сама схема определения IP-адреса по имени домена (см. рисунок) довольно сложна и многоступенчата, и именно из-за этого возникает большинство проблем при регистрации и переносе доменов.

После набора имени домена в браузере ваш компьютер связывается с DNS-серверами провайдера доступа в интернет, запрашивая IP-адрес, к которому привязан этот домен (шаг 1 на схеме). DNS-серверы провайдера ищут в своем кэше необходимую пару домен — IP-адрес и, если находят ее, выдают вам этот IP (сразу переходим к шагу 6). Если в кэше ничего не нашлось, DNS-сервер провайдера делает запрос к одному из корневых DNS-серверов, которых всего несколько по всему миру (шаг 2). Корневой сервер, в свою очередь, ищет в своей базе данных адреса DNS-серверов хостера, к которому привязан домен (NS-серверы домена), и сообщает их DNS-серверу провайдера (шаг 3). (На самом деле, здесь все немного сложнее, но для простоты мы опустим некоторые подробности.)

Получив адреса NS-серверов, провайдер делает запрос к одному из них, получает в ответ искомый IP-адрес (шаги 4–5), запоминает его в кэше (чтобы впоследствии не обращаться каждый раз к корневому DNS-серверу) и передает вашему браузеру. Браузер, наконец, запрашивает сайт у хостера и показывает его вам (шаги 7–8).

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

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

А во-вторых, если вы или кто-то другой из клиентов вашего провайдера недавно заходил на нужный вам сайт, его IP запоминается в DNS-кэше провайдера и хранится там некоторое время. Если за это время IP сайта изменится (при переносе на другой хостинг), DNS-система провайдера об этом не узнает, пока не обновится кэш, и будет выдавать вам неверный IP-адрес. При этом у большинства других пользователей интернета — тех, кто в последнее время не заходил на ваш сайт, он будет работать нормально и открываться с нового сервера.

Обычно, эти проблемы решаются сами собой в течении нескольких часов — после обновления базы данных DNS и кэша провайдера. Поэтому, если после регистрации или переноса домена (смены NS-серверов), сайт сразу не стал работать, не волнуйтесь — просто подождите некоторое время

После набора имени домена в браузере ваш компьютер связывается с DNS-серверами провайдера доступа в интернет, запрашивая IP-адрес, к которому привязан этот домен (шаг 1 на схеме). DNS-серверы провайдера ищут в своем кэше необходимую пару домен — IP-адрес и, если находят ее, выдают вам этот IP (сразу переходим к шагу 6). Если в кэше ничего не нашлось, DNS-сервер провайдера делает запрос к одному из корневых DNS-серверов, которых всего несколько по всему миру (шаг 2). Корневой сервер, в свою очередь, ищет в своей базе данных адреса DNS-серверов хостера, к которому привязан домен (NS-серверы домена), и сообщает их DNS-серверу провайдера (шаг 3). (На самом деле, здесь все немного сложнее, но для простоты мы опустим некоторые подробности.)

Получив адреса NS-серверов, провайдер делает запрос к одному из них, получает в ответ искомый IP-адрес (шаги 4–5), запоминает его в кэше (чтобы впоследствии не обращаться каждый раз к корневому DNS-серверу) и передает вашему браузеру. Браузер, наконец, запрашивает сайт у хостера и показывает его вам (шаги 7–8).

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

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

А во-вторых, если вы или кто-то другой из клиентов вашего провайдера недавно заходил на нужный вам сайт, его IP запоминается в DNS-кэше провайдера и хранится там некоторое время. Если за это время IP сайта изменится (при переносе на другой хостинг), DNS-система провайдера об этом не узнает, пока не обновится кэш, и будет выдавать вам неверный IP-адрес. При этом у большинства других пользователей интернета — тех, кто в последнее время не заходил на ваш сайт, он будет работать нормально и открываться с нового сервера.

Обычно, эти проблемы решаются сами собой в течении нескольких часов — после обновления базы данных DNS и кэша провайдера. Поэтому, если после регистрации или переноса домена (смены NS-серверов), сайт сразу не стал работать, не волнуйтесь — просто подождите некоторое время.

скачать

Министерство образования Российской Федерации

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ)

Кафедра ИКТ

Курсовая работа

по дисциплине:

«Сети ЭВМ и телекоммуникации»

на тему: «Настройка ДНС сервера BIND для нужд организации».

Выполнил:

Студент группы С-65

Пашинцев И.

Проверил:

Орлов П.

Москва 2009

Оглавление

Техническое задание

Настройка ДНС сервера BIND для нужд организации. Прописывание прямых и обратных зон, почтовых и Интернет-серверов, кеширование.

Цель работы

Обеспечение функционирования авторитетного DNS-сервера.

Анализ ТЗ

В качестве домена, для которого настраивается DNS сервер, был выбран тестовый домен mydns.dn. Настройка проводилась в домашней сети на ОС FreeBSD (в нее уже включен DNS сервер BIND). Основная задача настройки – внести необходимые нам изменения в конфигурационные файлы named.conf, которые определяют параметры функционирования сервера, описание прямой и обратной зоны, обеспечивает перенаправление и кеширование запросов.

Что такое DNS?

Определение

DNS (^ — система доменных имён) — распределённая система (распределённая база данных), способная по запросу, содержащему доменное имя хоста (компьютера или другого сетевого устройства), сообщить IP адрес или (в зависимости от запроса) другую информацию. DNS работает в сетях TCP/IP.

DNS важна для работы Интернета, ибо для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла HOSTS, который составлялся централизованно и обновлялся на каждой из машин сети вручную. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы описано в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменили спецификацию DNS и отменили RFC 882 и RFC 883 как устаревшие. Некоторые новые RFC дополнили и расширили возможности базовых протоколов.

Структура системы доменных имен

Система доменных имен (DNS) – это иерархический протокол, работающий по сети Internet аналогично протоколам маршрутеризации. Несколько «корневых серверов», географически расположенных по всей сети Internet для обеспечения надежности и избыточности, поддерживается корпорацией Network Solutions, Inc. и другими организациями. Каждое доменное имя строится в обратном порядке, начиная с корневой зоны, причем суффикс домена – ru, com, gov и т.д. – определяет корневую зону. После каждого из суффиксов (которые обычно называют доменами верхнего уровня – top-level domains или TLD) следуют имена доменов, определяемы обычно не корневыми серверами, а отдельными хостами DNS в сети Internet.

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

Корневые сервера сами не поддерживают никаких авторитетных данных службы DNS. Они содержат только записи хостов, которые указывают на авторитетные серверы имен в каждом домене. Корневые серверы возвращают запрашивающему ответ DNS, содержащий ссылку на авторитетные сервера имен домена, к которому обращался клиент. Этот сервер, в свою очередь, возвращает запрашиваемые данные DNS локальному серверу DNS, который передает ее клиенту.

Локальный сервер DNS может сохранить результат поиска в своем кэше на период времени, указанный авторитетным сервером имен. Это ускоряет обработку запросов, позволяя локальным клиентам получать непосредственные ответы на свои запросы DNS от локального сервера, без передачи информации по Internet. Это, однако, означает, что изменения в записях DNS на авторитетном сервере DNS домена не будут доступны клиенту до завершения периода устаревания. До этого времени доступная клиенту информация DNS «заморожена» и потенциально неверна.

Схема работы DNS

Типы записей 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
• ^ (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя
• Запись MX(mail exchange) или почтовый обменник указывает серверы обмена почтой для данного домена.
• Запись 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 сессии.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и взаимодействия DNS-серверов.

Типы DNS-серверов

По выполняемым функциям DNS-серверы делятся на несколько групп, в зависимости от конфигурации конкретный сервер может относиться к нескольким типам;

• авторитативный DNS-сервер — сервер, отвечающий за какую-либо зону.
  
  • Мастер или первичный сервер
  • Слейв или вторичный сервер, не имеющий права на внесение изменений в данные зоны и получающий сообщения об изменениях от мастер-сервера. В отличие от мастер-сервера их может быть неограниченное количество. Слейв так же является авторитативным сервером (и пользователь не может различить мастер и слейв, разница появляется только на этапе конфигурирования/внесения изменений в настройки зоны).
• Кэширующий DNS-сервер — сервер, который обслуживает запросы клиентов, (получает рекурсивный запрос, выполняет его с помощью нерекурсивных запросов к авторитативным серверам или передаёт рекурсивный запрос вышестоящему DNS-серверу)
• Локальный DNS-сервер; используется для обслуживания DNS-клиентов, исполняющихся на локальной машине. Фактически, это разновидность кэширующего DNS-сервера, сконфигурированная для обслуживания локальных приложений.
• Перенаправляющий DNS-сервер; (forwarder, внутренний DNS-сервер) сервер, перенаправляющий полученные рекурсивные запросы вышестоящему кэширующему серверу в виде рекурсивных запросов. Используется преимущественно для снижения нагрузки на кэширующий DNS-сервер.
• Корневой DNS-сервер — сервер, являющийся авторитативным за корневую зону. Общеупотребительных корневых серверов в мире всего 13, их доменные имена находятся в зоне root-servers.net и называются a.root-servers.net, … , g.root-servers.net. В определённых конфигурациях локальной сети возможна ситуация настройки локальных корневых серверов.
• Регистрирующий DNS-сервер. Сервер, принимающий динамические обновления от пользователей. Часто совмещается с DHCP-сервером.

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

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

BIND

BIND (^ , до этого: Berkeley Internet Name Daemon) — это открытая и наиболее распространённая реализация DNS-сервера, обеспечивающая выполнение преобразования DNS-имени в IP-адрес и наоборот. Система BIND (сокращение от Berkeley Internet name Domain) состоит из основной программы-демона (named), набора библиотек разрешения имен позволяющих выполнять поиск имен, и ряда административных средств.

Существует множество версий пакета. До самого недавнего времени наиболее распространенной была версия 4 и ее модификации. В настоящее время все работы по ней приостановлены. Рекомендуемой к использованию является версия 9, которая существует в своей наиболее свежей ипостаси, как BIND 9.2.1. Часто используются и 8-ые версии пакета.

Автор BIND Paul Vixie рекомендует пользоваться 9-ой версией программы, которая является абсолютно новым продуктом, разработанным для функционирования в агрессивной среде современного Интернета. По его утверждению все версии BIND до 8-ой включительно опирались на код, который написали аспиранты Berkeley. Последние выпуски 8-ой версии исчерпали все возможности по улучшению кода, что и привело к появлению 9-ой версии программы, которая была полностью переписана профессионалами с применением методов «контрактного» проектирования.

VIEW

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

Файлы BIND

• /usr/sbin/named. Демон сервера имен. Он прослушивает 53 порт ожидая поступления запросов поиска системы DNS.
• /etc/namedb. Все файлы конфигурации и файлы текущего состояния системы BIND, включая файлы определения зон, находятся в этом каталоге (или в созданных администратором подкаталогах).
• /etc/namedb/named.conf. Основной файл конфигурации системы BIND. Из него система BIND «узнает», какими доменами управляет и как работать с каждым и них.

Пример файла «named.conf»

acl clients {10.239.0.0/16; 127.0.0.1; };

options {

version «1.0.a»;

listen-on { 10.239.0.209; 127.0.0.1; };

forward first;

forwarders { 213.234.192.8; };

allow-recursion { clients; };

};

zone «.» {

type hint;

file «named.root»;};

zone «localhost» {

type master;

file «master/localhost.rev»;};

zone «0.0.127.in-addr.arpa» {

type master;

file «master/localhost.rev»;};

zone «mydns.dn» {

type master;

file «master/mydns.dn/mydns.dn»;};

zone «0.239.10.in-addr.arpa» {

type master;

file «master/mydns.dn/0.239.10.in-addr.arpa»; };

Система BIND позволяет ограничить доступ с помощью списков контроля доступа (Access Control List – ACL). Список указывается в операторе acl, задающем имя списка и содержащем критерии включенных хостов в список. Элементами списка контроля доступа также могут быть IP-адреса, адреса сетей в формате CIDR или оператор key (используется для защищенных транзакций).

Структура options — описывает глобальные параметры для сервера, а структуры zone – описывают доменные зоны.

—listen-on — позволяет указать на какие сетевые интерфейсы будет «вешаться» демон.

—version — строка, которая будет выдаваться на запрос определения версии DNS-сервера

—forward — этот параметр позволяет указать каким образом сервер обрабатывает запрос клиента. first — это означает что сервер сначала перенаправит запрос выше и если не получит положительного результата, то посмотрит в своем кэше. Если указать only — то у себя смотреть не будет

—forwarders — а тут указывается, куда перенаправлять запросы клиентов.

named.root – в файле named.root описаны корневые DNS сервера.

—type — тип зоны

Добавим две структуры: прямую зону – mydns.dn и реверсивную — 0.239.10.in—addr.arpa.

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

В файле зоны задаются соответствия имен хостов и IP-адресов в пределах домена или зоны. Формат файла зоны (который часто называют главным файлом зоны – Master Zone File) весьма сложен и строг, хотя и допускает определенные послабления. Ниже приведен пример файлы прямой и обратной зоны для mydns.dn.

Прямая зона

mydns.dn. IN SOA dns.mydns.dn. admin.mydns.dn.(

2009051304 ; Serial

10800 ; Refresh 3 hours

3600 ; Retry 1 hour

3600000 ; Expire 1000 hrs

86400 ) ; Min 24 hours

mydns.dn. IN NS ns.mydns.dn.

@ IN A 10.239.0.209

mail.mydns.dn. IN A 10.239.0.210

@ IN MX 10 mail.mydns.dn.

www.poisk.ru IN CNAME google.ru.

www.mydns.dn. IN CNAME www.corbina.ru.

Обратная зона

@ IN SOA ns.mydns.dn. admin.mydns.dn. (

2009051303 ; Serial

10800 ; Refresh 3 hours

3600 ; Retry 1 hour

3600000 ; Expire 1000 hrs

86400 ) ; Min 24 hours

;

IN NS ns.mydns.dn.

@ IN NS ns1.mydns.dn.

208 IN PTR ns.mydns.dn.

210 IN PTR mail.mydns.dn.

209 IN PTR mydns.dn.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$TTL 3600

@ IN SOA ns.mydns.dn. admin.mydns.dn. (

20070909 ; Serial

3600 ; Refresh

900 ; Retry

3600000 ; Expire

3600 ) ; Minimum

IN NS ns.mydns.dn.

1 IN PTR localhost

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

Проверка работы BIND сервера

# dig mydns.dn

; <<>> DiG 9.3.3 <<>> mydns.dn

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36762

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;mydns.dn. IN A

;; ANSWER SECTION:

mydns.dn. 86400 IN A 10.239.0.209

;; AUTHORITY SECTION:

mydns.dn. 86400 IN NS ns.mydns.dn.

;; Query time: 0 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Wed May 13 18:12:10 2009

;; MSG SIZE rcvd: 78

# dig PTR 208.0.239.10.in-addr.arpa

; <<>> DiG 9.3.1 <<>> PTR 208.0.239.10.in-addr.arpa

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38502

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:

;208.0.239.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:

208.0.239.10.in-addr.arpa. 86000 IN PTR ns.mydns.dn.

;; AUTHORITY SECTION:

0.239.10.in-addr.arpa. 86000 IN NS ns.mydns.dn.

;; Query time: 13 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Mon Jun 01 01:05:12 2009

;; MSG SIZE rcvd: 200

# nslookup mydns.dn

Server: 127.0.0.1

Address: 127.0.0.1#53

Name: mydns.dn

Address: 10.239.0.209

# nslookup mail.mydns.dn

Server: 127.0.0.1

Address: 127.0.0.1#53

Name: mail.mydns.dn

Address: 10.239.0.210

Заключение

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

Список литературы

• Paul Albitz, Cricket Liu «DNS and BIND, 5th Edition»
• Интернет ресурс: http://ru.wikipedia.org/
• Интернет ресурс: http://rubsd.org/doc/dns/

	Студент группы С-65
Дата	23.01.2012
Размер	129 Kb.
Тип	Курсовая, Образовательные материалы

1. Базовая конфигурация 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

Файл 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/.

— Если в вашей системе установлена программа dig, вы можете задать команду dig @a. root-servers.net . ns > named, са. Эта команда копирует файл, содержащий список корневых серверов, и присваивает ему имя named. са.

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

Получив файл со списком корневых серверов, скопируйте его в каталог /var/named. Кроме того, вам следует убедиться в том, что ссылка на этот файл присутствует в конфигурационном файле /etc/named, conf.

BIND осуществляет преобразование имен одним из трех описанных ниже способов:

1. Если пакет BIND настроен для поддержки запрошенного имени, сервер возвращает адрес, указанный в его конфигурационном файле;

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

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

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

Источник

Для системного администратора

Установка и настройка DNS-сервера в Windows Server 2008

Как многим из вас, наверное, известно, DNS (англ.— Domain Name System — Система доменных имён) стала системой разрешения имён, используемой в Windows. Без неё компьютерам бы требовалось гораздо больше времени, чтобы соединиться друг с другом. Однако многие администраторы для преобразования имён в локальных сетях до сих пор применяют Windows Internet Name Service (WINS) и имеют мало (либо вообще не имеют) опыта работы с DNS. Если вы относитесь к данной категории, эта статья для вас. В ней рассказано, как установить, настроить и устранять неисправности в работе DNS-сервера на Windows Server 2008.

Установка DNS-сервера.

Установить DNS-сервер можно из Панели управления (Control Panel) или при преобразовании рядового сервера в контроллер домена, как показано на изображении A. Во время преобразования, система, не обнаружив DNS-сервер, предложит установить его.

Изображение A. Контроллер домена

Для установки DNS-сервера из Панели управления (Control Panel):

• В меню Пуск (Start) выберите Панель управления (Control Panel )| Администрирование (Administrative Tools) | Управление сервером (Server Manager).
• Раскройте вкладку и выберите объект Роли (Roles) (изображение B).
• Нажмите Добавить роли (Add Roles) и следуйте указаниям мастера, выбрав в качестве роли сервера DNS-сервер (DNS-server) (изображение C).
• Для того, чтобы установить DNS-сервер на ОС Windows Server 2008 нажмите Установить (Install) (изображение D).

Изображение B. Раскройте вкладку и выберите объект Роли (Roles)

Изображение C. Роль: DNS-сервер

Изображение D. Установка DNS

Консоль DNS и настройка

По завершению консоль управления DNS-сервером можно будет найти в меню Пуск (Start) | Программы (All Programs) | Администрирование (Administrative Tools) | DNS. В Windows 2008 встроен мастер настройки DNS-сервера
Для конфигурирования DNS-сервера понадобятся узнать значения следующих терминов:

1…Зона прямого просмотра (Forward lookup zone)
2…Зона обратного просмотра (Reverse lookup zone)
3…Типы зон (Zone types)

Зона прямого просмотра отвечает за преобразование имён хостов в IP-адреса. Зона обратного просмотра отвечает за распознавание DNS-сервером DNS-имени хоста, то есть, по сути, это антипод зоны прямого просмотра. Наличие зоны обратного просмотра не обязательно, но она легко настраивается и обеспечивает полную функциональность DNS в Windows Server 2008 Server.

При выборе типа зоны DNS даны следующие варианты: Active Directory (AD) Integrated (Интегрированная в AD), Standard Primary (Основная), и Standard Secondary (Дополнительная). Зона «AD Integrated» хранит информацию о распределённой базе данных в AD и позволяет осуществлять безопасное обновление файла базы данных. Эта опция доступна только при соответствующей настройке AD. Если выбрать её, AD будет хранить и тиражировать файлы зоны.

Основная зона (Standard Primary) хранит базу данных в текстовом файле, доступ к которому могут получить другие DNS-серверы, также хранящие информацию в текстовых файлах. Наконец дополнительная зона (Standard Secondary) создаёт копию существующей базы данных другого DNS-севера. Это нужно для выравнивания нагрузки.

Чтобы открыть мастера настройки DNS-сервера:

1…Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
2…Выделите имя вашего компьютера и нажмите Действие (Action) | Конфигурация DNS-сервера (Configure a DNS Server), чтобы запустить Мастера настройки DNS-сервера.
3…Нажмите Далее (Next) и выберите объект настройки: зона прямого просмотра (forward lookup zone), зоны прямого и обратного просмотра (forward and reverse lookup zone ), только корневые ссылки (root hints only) (изображение E).
4…Нажмите Далее (Next) и потом Да (Yes) для того, чтобы создать зону прямого просмотра (изображение F).
5…Отметьте желаемый тип зоны (изображение G).
6…Нажмите Далее (Next) и введите имя создаваемой зоны.
7…Нажмите Далее (Next) и потом Да (Yes) для того, чтобы создать зону обратного просмотра.
8…Повторите шаг 5.
9…Выберите протокол зоны обратного просмотра: IPv4 или IPv6 (изображение H).
10… Нажмите Далее (Next) и ведите идентификатор зоны обратного просмотра (изображение I).
11…Можно создать новый или использовать копию уже существующего файла DNS (изображение J).
12…В окне Динамические обновления (Dynamic Update), выберите способ обновления DNS: безопасный (secure), небезопасный (nonsecure), неполучать динамических обновлений (no dynamic updates).
13…При желании можно включить перенаправляющий DNS-сервер в окне Перенаправление (Forwarders) (изображение K).
14…Нажмите Готово (Finish) (изображение L).

Изображение E. Настройка

Изображение F. Зона прямого просмотра

Изображение G. Желаемая зона

Изображение H. IPv4 или IPv6

Изображение I. Зона обратного просмотра

Изображение J. Новый или существующий файл DNS

Изображение K. Окно «Перенаправление»

Изображение L. Завершение

Управление записями DNS

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

• Запись SOA (Start of Authority) — Начальная запись зоны
• Запись NS (Name Server) — Сервер имён
• Запись A (Host) — Запись узла
• Запись PTR (Pointer) — Указатель
• Запись CNAME (Canonical Name) или Alias — Каноническая запись имени (Псевдоним)
• Запись MX (Mail Exchange) — Почтовый обменник

Начальная запись зоны (SOA)

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

Изображение M. Изменение конфигурации

Серверы имён (name servers)

Записи Серверов имён (Name Servers) определяют имена серверов для конкретного домена. С их помощью устанавливаются все имена первичных и вторичных серверов.

Чтобы создать запись NS:

• Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
• Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone).
• Щёлкните правой кнопкой на требуемом домене и выберите пункт меню Свойства (Properties) (изображение N).
• Перейдите на вкладку Серверы имён (Name Servers) и нажмите Добавить (Add).
• Введите Имя FQDN-сервера (FQDN Server name) и IP-адрес (IP address) добавляемого DNS-сервера.

Изображение N. Сервер имён

А-запись

Запись A связывает имя хоста с IP-адресом. С их помощью серверы распознаются в зоне прямого просмотра, а выполнение запросов в средах с несколькими зонами происходит значительно лучше. Также можно создать запись указателя (PTR), которая связывает IP-адрес хоста с его именем.

Чтобы создать новый хост:

• Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
• Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone) и щёлкните на папке, представляющей ваш домен.
• Из меню Действие (Action) выберите команду Создать узел (New Host).
• Введите имя и IP-адрес создаваемого узла (изображение O).
• Отметьте параметр Создать соответствующую PTR-запись (Create Associated Pointer (PTR) Record), если параллельно хотите создать запись указателя (PTR). Либо вы можете создать её позже.
• Нажмите кнопку Добавить узел (Add Host).

Изображение O. Запись A

Обратная запись (PTR).

Для выполнения обратных запросов указатели (PTR) создают соответствующие входящие сообщения в зоне обратного просмотра. Как видно на изображении H, при создании хоста можно также создать и запись PTR. Если вы не воспользовались этой опцией в тот момент, создать указатель можно будет в любое время.

Для создания записи PTR:

• Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
• Выберите зону обратного просмотра, где будет создан указатель.
• Из меню Действие (Action) выберите команду Новый указатель (New Pointer) (изображение P).
• Введите IP-адрес узла (Host IP Number) и Имя узла (Host Name).
• Нажмите OK.

Изображение P. Новый указатель

Каноническое имя (CNAME) или псевдоним

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

Для создания псевдонима:

• Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
• Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone) и выделите папку, представляющую ваш домен.
• Из меню Действие (Action) выберите команду Новый псевдоним (New Alias).
• Введите каноническое имя (Alias Name) (изображение Q).
• Введите полное имя домена (Fully qualified domain name, FQDN).
• Нажмите OK.

Изображение Q. Каноническое имя

MX-запись

Данная запись указывает почтовые серверы обмены почтой в базе данных DNS внутри зоны. С её помощью можно назначить приоритеты и отслеживать размещение всех почтовых серверов.

Для создания записи MX:

• Выберите объект DNS из папки Администрирование (Administrative Tools), чтобы открыть консоль управления DNS-сервером.
• Раскройте вкладку Зоны прямого просмотра (Forward Lookup Zone) и выделите папку, представляющую ваш домен.
• Из меню Действие (Action) выберите команду Создать почтовый обменник (New Mail Exchanger).
• Введите имя Узла (Host) или Домена (Domain) (изображение R).
• Введите Имя почтового сервера (Mail Server Name) и установите Приоритет почтового сервера (Mail Server Priority).
• Нажмите OK.

Изображение R. Узел или домен

Другие новые записи

Вы можете создавать и другие виды записей. Для подробного описания в окне консоли DNS выберите из меню Действие (Action) команду Другие записи (Other New Records) (изображение S). Выберите любую запись и прочтите её описание.

Изображение S. Создание записей в консоли DNS

Устранение неполадок в работе DNS-серверов

Лучший помощник в устранении неисправностей DNS-серверов — утилита nslookup. Это гибкая и простая в применении утилита командной строки, входящая в состав Windows 2008. С её помощью можно протестировать запросы DNS-серверов, что помогает выявить причины проблем преобразования имён и других связанных с этим неполадок. Запустить nslookup (изображение T) можно прямо из консоли управления DNS.

Этот пост May 28, 2008 at 1:51 pm опубликовал molse в категории DNS. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Источник

Практическая работа 6-1-2. Настройка сетевых сервисов DNS, DHCP и Web

Наша задача состоит в том, чтобы настроить Server1 как DNS и Web—сервер, а Server2 как DHCP сервер. Напомню, что работа DNS-сервера заключается в преобразовании доменных имен серверовв IP-адреса. DHCP сервер позволяет организовывать пулы для автоматического конфигурирования сетевых интерфейсов, то есть, обеспечивает автоматическое распределение IP-адресов между компьютерами в сети. Иначе говоря, в нашем случае компьютеры получают IP-адреса благодаря сервису DHCP Server2 и открывают, например, сайт на Server1.

Настраиваем IP адреса серверов и DHCP на ПК

Войдите в конфигурацию PC1 и PC2 и установите настройку IP через DHCP сервер рис. 6.6.

Рис. 6.6.Настройка IPна PC1

Задайте в конфигурации серверов настройки IP: Server1 – 10.0.0.1 ( рис. 6.7), Server2 – 10.0.0.2 ( рис. 6.8). Маска подсети установится автоматически как 255.0.0.0.

Рис. 6.7.

Рис. 6.8.

Настройка служб DNS и HTTP на Server1

В конфигурации Server1 войдите на вкладку DNS и задайте две ресурсные записи (Resource Records) в прямой зоне DNS.

Новый термин

Зона DNS — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на сервере доменных имен (DNS-сервере). В зоне прямого просмотра на запрос доменного имени идет ответ в виде IP адреса. В зоне обратного просмотра по IP мы узнаем доменное имя ПК.

Сначала в ресурсной записи типа A Record свяжите доменное имя компьютера server1.yandex.ru с его IP адресом 10.0.0.1 и нажмите на кнопку Add (добавить) и активируйте переключатель On – рис. 6.9.

Рис. 6.9.Ввод ресурсной записи типа A Record

Далее в ресурсной записи типа CNAME свяжите название сайта с сервером и нажмите на кнопку Add (добавить) – рис. 6.10.

Рис. 6.10.Ввод ресурсной записи типа CNAME

В результате должно получиться следующее ( рис. 6.11).

Рис. 6.11.Служба DNS в прямой зоне

Теперь настроим службу HTTP. В конфигурации Server1 войдите на вкладку HTTP и создайте стартовую страницу сайта ( рис. 6.12).

Рис. 6.12.Стартовая страница сайта

Включите командную строку на Server1 и проверьте работу службы DNS. Для проверки правильности работы прямой зоны DNS сервера введите команду SERVER>nslookup . Если все правильно настроено, то вы получите отклик на запрос с указанием доменного имени DNS сервера в сети и его IP адреса ( рис. 6.13).

Рис. 6.13.Служба DNSв прямой зоне DNSна Server1 настроена правильно

Примечание

Команда nslookup служит для определения ip-адреса по доменному имени (и наоборот).

Настройка службы DHCP на Server2

Войдите в конфигурацию Server2 и на вкладке DHCP настройте службу DHCP. Для этого наберите новые значения пула, установите переключатель On и нажмите на кнопку Save (Сохранить) — рис. 6.14.

Рис. 6.14.Настройка DHCPсервера.

Проверка работы клиентов

Войдите в конфигурации хоста PC1и PC2 и в командной строке сконфигурируйте протокол TCP/IP. Для этого командой PC> ipconfig /release сбросьте (очистите) старые параметры IP адреса ( рис. 6.15).

Рис. 6.15.Удаление конфигурации IP-адресов для всех адаптеров

Примечание

Команда ipconfig /release отправляет сообщение DHCP RELEASE серверу DHCP для освобождения текущей конфигурации DHCP и удаления конфигурации IP-адресов для всех адаптеров (если адаптер не задан). Этот ключ отключает протокол TCP/IP для адаптеров, настроенных для автоматического получения IP-адресов.

Теперь командой PC> ipconfig /renew получите новые параметры от DHCP сервера ( рис. 6.16).

Рис. 6.16.Конфигурация протокол TCP/IP клиента от DHCP сервера

Аналогично поступите для PC2 ( рис. 6.17).

Рис. 6.17.PC2 получил IP адрес от DHCP сервера Server2

Осталось проверить работу WEB сервера Server1 и открыть сайт в браузере на PC1 или PC2 ( рис. 6.18).

Рис. 6.18.Проверка работы службы HTTP на Server1

Примеры работы маршрутизатора в роли DHCP сервера

Маршрутизация (routing) – процесс определения маршрута следования информации в сетях связи. Задача маршрутизации состоит в определении последовательности транзитных узлов для передачи пакета от источника до адресата. Определение маршрута следования и продвижение IP-пакетов выполняют специализированные сетевые устройства – маршрутизаторы. Каждый маршрутизатор имеет от двух и более сетевых интерфейсов, к которым подключены: локальные сети либо маршрутизаторы соседних сетей.

Новый термин

Маршрутизатор (router, роутер) – сетевое устройство третьего уровня модели OSI, обладающее как минимум двумя сетевыми интерфейсами, которые находятся в разных сетях. Маршрутизатор может иметь интерфейсы: для работы по медному кабелю, оптическому кабелю, так и по беспроводным «линиям» связи.

Выбор маршрута маршрутизатор осуществляет на основе таблицы маршрутизации. Таблицы маршрутизации содержат информацию о сетях, и интерфейсов, через которые осуществляется подключение непосредственно, а также содержатся сведения о маршрутах или путях, по которым маршрутизатор связывается с удаленными сетями, не подключенными к нему напрямую. Эти маршруты могут назначаться администратором статически или определяться динамически при помощи программного протокола маршрутизации. Таблица маршрутизации содержит набор правил – записей, состоящих из определенных полей. Каждое правило содержит следующие основные поля-компоненты:

· адрес IP-сети получателя,

· адрес следующего узла, которому следует передавать пакеты,

· административное расстояние — степень доверия к источнику маршрута,

· метрику — некоторый вес — стоимость маршрута,

· интерфейс, через который будут продвигаться данные.

Пример таблицы маршрутизации:

Протокол DHCP представляет собой стандартный протокол, который позволяет серверу динамически присваивать клиентам IP-адреса и сведения о конфигурации. Идея работы DHCP сервиса такова: на ПК заданы настройки получения ip адреса автоматически. После включения и загрузки каждый ПК отправляет широковещательный запрос в своей сети с вопросом «Есть здесь DHCP сервер — мне нужен ip адрес?». Данный запрос получают все компьютере в подсети, но ответит на этот запрос только DHCP сервер, который отправит компьютеру свободный ip адрес из пула, а также маску и адрес шлюза по умолчанию. Компьютер получает параметры от DHCP сервера и применяет их. После перезагрузки ПК снова отправляет широковещательный запрос и может получить другой ip адрес (первый свободный который найдется в пуле адресов на DHCP сервере).

Маршрутизатор можно сконфигурировать как DHCP сервер. Иначе говоря, вы можете программировать интерфейс маршрутизатора на раздачу настроек для хостов.Системный администратор настраивает на сервере DHCP параметры, которые передаются клиенту. Как правило, сервер DHCP предоставляет клиентам по меньшей мере: IP—адрес, маску подсети и основной шлюз. Однако предоставляются и дополнительные сведения, такие, например, как адрес сервера DNS.

Поперечные профили набережных и береговой полосы: На городских территориях берегоукрепление проектируют с учетом технических и экономических требований, но особое значение придают эстетическим.

Общие условия выбора системы дренажа: Система дренажа выбирается в зависимости от характера защищаемого.

Механическое удерживание земляных масс: Механическое удерживание земляных масс на склоне обеспечивают контрфорсными сооружениями различных конструкций.

Источник

• Содержание
• Часть работы
• Список литературы
• Вопросы/Ответы

Оглавление

Обозначения и сокращения

Введение

Глава 1.Теоретические основы функционирования системы доменных имен

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

1.2. Предшествующие технологии

1.3. Иерархия доменов

1.4. Порядок записи доменных имен и формат их хранения

1.5. Функции и типы DNS-серверов

Глава 2.Конфигурация Microsoft DNS Server

2.1. Установка DNS-сервера, DHCP-сервера и службы Active Directory

2.2. Конфигурирование DNS-сервера

2.2.1.Проверка функционирования DNS-сервера

2.2.2.Зоны прямого просмотра DNS-сервера

2.2.3.Настройка свойств DNS-сервера домена

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

3.1. Установка программного пакета BIND

3.2. Конфигурирование демона «named»

3.2.1.Пример конфигурирования файла «named.conf.options»

3.2.2.Пример конфигурирования файла «named.conf»

3.2.3.Пример конфигурирования файла зоны

3.3. Применение настроек и проверка конфигурации

Заключение

Список использованной литературы.

Фрагмент для ознакомления

В случае отсутствия необходимости использования корневых ссылок, необходимо выбрать опцию «не использовать рекурсию для этого домена». В таком случае для удовлетворения запросов будет использоваться собственный кэш DNS-сервера и информация, получаемая от серверов, из списка «Домен DNS». В случае невозможности удовлетворения запроса, сервер не будет пользоваться другими средствами, и сервер произведет соответствующее уведомление клиента. При необходимости возможно ручное добавление записей о корневых ссылках, например в ситуации, когда в рамках системы ActiveDirectoryорганизации функционирует корневой DNS-сервер.Остальные вкладки окон предоставляют информацию по обеспечению аудита и настройке безопасности, и являются отдельной темой для рассмотрения. Конфигурация сервера BINDУстановка программного пакета BINDДля ознакомления с принципами настройки DNS сервером под *nix систем целесообразно выбрать наиболее часто встречающуюся реализацию named, входящую в пакет BIND, функционирующую на большинстве корневых DNS-серверов. Сервер namedимеет широкие возможности конфигурации. Его можно использовать как главный, резервный или кэширующий DNS сервер[7].Настройка программного обеспечения в *nixсистемах происходит посредством записи настроек в специальные файлы, откуда впоследствии происходит чтение параметров[8].Аналогично для настройки программы named, необходимо внести требуемые изменения в файл конфигурации в соответствии с требуемым синтаксисом. Последней версией пакета BIND является девятая версия, поэтому процесс настройки будет рассмотрен применительно к ней. При работе named используются следующие компоненты:файл начальной загрузки буфера (cache);файл конфигурации named (named.boot);файлы, содержащие описания «прямых» и «обратных» зон;Для начала использования программного пакета BIND необходимо произвести его получение из репозитория. Для этого необходимо выполнить следующую команду[4]:sudoaptitudeinstallbind9 dnsutilsКонфигурирование демона «named»После получения программного пакета и его установки можно переходить к конфигурированию. Файлы с настройками хранятся в директории /etc/bind[14]. Переход в каталог с конфигурационными файлами программного пакета BIND осуществляется следующей командой:cd /etc/bindПроцесс формирования файла настроек программного пакета BIND будет рассмотрен с точки зрения создания конфигурации основного DNS-сервера.В каталоге программного пакета создадим подкаталог, для размещения создаваемых конфигурационных файлов с именем организация. sudo mkdir masterПример конфигурирования файла «named.conf.options»Для осуществления настроек необходимо внести правки в файл named.conf.options. Пример конфигурационного файла, для рассматриваемого в курсовой работе случая может выглядеть следующим образом:options { directory «/var/cache/bind» forwarders {  99.77.55.33;  99.77.55.34;  192.168.0.1; }; allow-query { any; }; allow-transfer {  11.22.33.45;  192.168.0.2; };allow-recursion {  127.0.0.1;  192.168.0.0/24; }; notify yes; also-notify {  11.22.33.45;  192.168.0.2; }; auth-nxdomain no; listen-on-v6 { none; }; };После служебного словаforwardersосуществляется перечисление DNS серверов, используемых настраиваемым DNS-сервером при отсутствии информации в собственной базе данных или в сохраненном кэше. На практике в этот список попадают ip-адреса DNS-серверов провайдера, DNS-сервера контроллеров домена или других DNS-серверов[21]. Например возможно использование DNS-серверов компании Google, имеющих ip-адрес «8.8.8.8».Служебное слово allow-queryпозволяет ограничить список узлов, которым будут доступно посылать запросы DNS-серверу. Значение «any» в данном случае означает, что запросы может посылать любой узел. Служебное слово allow-transferподразумевает возможность задания списка DNS-серверов, которым будут отправлены обновления, в случае изменения данных о доменах в зоне ответственности настраиваемого сервера. Служебное слово allow-recursionпозволяет ограничить прием рекурсивных DNS-запросов. Прием будет производить только от узлов, указанных в качестве параметра данного служебно слова[20]. При обработке строки «notifyyes»сервер DNSпри изменении зоны, будет производить попытки оповещения зависимых от него сервером, с целью предоставления им актуальной информации, с требованием обновления необходимых записей.  Служебное слово «also-notify» позволяет произвести оповещение серверов при изменении содержимого в записях DNS-сервера, не обозначенных как подчиненные.Строка «auth-nxdomain» определяет порядок аутентификации для доступа к серверу. В данном примере аутентификация отменена, но что указывает служебное слово «no».Служебное слово «listen-on-v6» позволяет определить возможно ли осуществление работы с узлами по протоколу IPv6. В данном примере работа по протоколу IPv6 отключена, на что указывает параметр «none»[9].После внесения требуемых изменений необходимо сохранить файл и продолжить настройку сервера.Пример конфигурирования файла «named.conf»Следующим файлом, в который необходимо внести изменения является файл «named.conf». Примерный вариант фрагмента содержимого файла «named.conf» представлен ниже:include «/etc/bind/named.conf.options»;include «/etc/bind/named.conf.local»;include «/etc/bind/named.conf.default-zones»;include «/etc/bind/named.conf.zones»;В данном случае в файл добавлена строка «include»/etc/bind/named.conf.zones»;» ссылающаяся на файл, в который впоследствии будут добавлены доменные зоны для настраиваемого сервера. Далее создадим файл /etc/bind/named.conf.zones и добавим в него зону «organization.com»:zone «organization.com » { type master; file «/etc/bind/master/organization.com «;};Данная зона описана как «master». Это означает, что настраиваемый сервер является авторитетным сервером зоны, и остальные серверы зоны будут получать обновления именно от него. Пример конфигурирования файла зоныДалее необходимо перейти к созданию файла, определяющего настройки созданной зоны. Для создания файла необходимо выполнить последовательность команд:cd /etc/bind/mastersudotouchorganization.comВ файле «organization.org» должны присутствовать следующие настройки:$ORIGIN .$TTL 3600organization.com.   IN SOA ns1.domain.ru. webadmin.domain.ru. (                               2011080901 ; serial                               28800      ; refresh (8 hours)                               7200       ; retry (2 hours)                               604800     ; expire (1 week)                               86400      ; minimum (1 day)                        )                        NS ns1.domain.ru.                        NS ns2.domain.ru.                        A  192.168.0.2                        MX 10 mail.domain.ru.$ORIGIN organization.com.ftp                     A       192.168.0.51mail                    A       192.168.0.3www                     CNAME   organization.com.В данном файле при помощи служебного слова «ORIGIN» определяется корневой DNS-сервер «.».Далее указывается время жизни ресурсных записей, хранимых на сервере. Данная настройка осуществляется командой «TTL 3600». Затем следует фрагмент файла, в котором задаются временные характеристики обновлений ресурсных записей сервера.После этого, с помощью команды «NS»определяются вышестоящие DNS сервера. В данном примере вышестоящими серверами являются «ns1.domain.ru»и «ns2.domain.ru». При помощи команды «А» задается ip-адрес сервера. При помощи записи «MX 10 mail.domain.ru.» определяется почтовый сервер для данного домена. Последние три строки определяют поддомены созданного домена «ftp.organization.com», «mail.organization.com»и «www.organization.com».После внесения изменений в конфигурационный файл его необходимо сохранить и закрыть. Применение настроек и проверка конфигурацииДля того чтобы DNS-сервер named пакета BIND осуществил повторное считывание настроек из конфигурационных файлов и начал их использование необходимо выполнить следующую команду[11]: sudo rndc reloadПосле считывания и применения вновь созданной конфигурации необходимо убедиться в ее работоспособности. Для этого необходимо выполнить следующую команду, позволяющую получить от сервера по адресу «127.0.0.1»ip-адрес узла с именем organization.com[4]:nslookup organization.com 127.0.0.1Результатом выполнения данной команды является ответ сервера и предоставление инициатору запроса ip-адреса, записанного в соответствующем конфигурационном файле (в рассматриваемом примере данный адрес – 192.168.0.2).Таким же образом возможно создание других зон. Необходимо отметить, что при изменении доменных зон необходимо увеличивать серийный номер доменной зоны, для фиксации изменений в ней и предоставления DNS-серверу возможности оповещения зависимых от него DNS-серверов об изменениях[10]. ЗаключениеВ курсовой работе были рассмотрены теоретические вопросы функционирования системы DNS и их практическая реализация. В рамках рассмотрения теоретических основ функционирования системы DNS обозначены документы, регламентирующие использование протокола: серия документов IETF – RFC 1034, RFC 1035, RFC 1591, RFC4033, RFC 4035. Данные документы содержат как основные понятия, касающиеся функционирования протокола, так и детальное описание применяемых в DNS механизмах, например расширений безопасности, описанных в RFC 4035. Необходимо отметить, что приоритет при изучении литературы по данному вопросу отдавался документам IETF, так как они являются первоисточниками при рассмотрении вопросов, связанных с функционированием DNS. Практическая работа по настройке оборудования, выполняющего функции DNS-сервера была разделена на две части. В рамках первой части был рассмотрен порядок конфигурирования DNS сервера, входящего в комплект поставки операционной системы MicrosoftWindows 2003 Server.Настройка DNS-сервера в данном случае осуществлялась с учетом его функционирования в рамках домена, управление которым осуществлялось с помощью системы ActiveDirectory. Кроме системы ActiveDirectoryбыла также произведена настройка DHCP-сервера.Вторая часть освещает порядок конфигурирования DNS-сервера named, входящего в программный пакет BIND. Данный программный пакет широко распространен среди пользователей использующих *nix подобные операционные системы и добавлен в большинство репозиториев программного обеспечения. В отличие от DNS-сервера Microsoftвходящего в состав Windows 2003 ServerDNS-сервер namedне имеет графического интерфейса для конфигурирования и как следствие требует более высокой квалификации пользователя. Необходимо отметить достоинства и недостатки каждого из рассмотренных вариантов. Графическая среда, представляемая операционной системой MicrosoftWindowsпозволяет повысить удобство при конфигурировании сервера, а встроенная система справки оперативно получить системному администратору информацию по настраиваемым параметрам и рекомендуемые значения настроек в каждом конкретном случае. Однако рассматривая функциональную сторону, можно сделать вывод о значительном превосходстве в производительности и потреблении ресурсов DNS-сервера named. Высокая производительность сервера named обуславливает его широкое применение в высоконагруженных системах, об этом свидетельствует тот факт, что программный пакет BIND и DNS-сервер named функционируют на 10 из 13 корневых DNS-серверов. С другой стороны DNS-сервер named требует от системного администратора специальных навыков и, по крайней мере, базовых знаний в области работы с *nix системами. При записи информации в конфигурационные файлы возможны как синтаксические, так и логические ошибки которые могут стать причиной некорректной работы сервера. Другим весомым недостатком DNS-сервера ОС Microsoft 2003 Serverявляется обязательность установки и минимального конфигурирования служб, без которых DNS-сервер не будет установлен, например DHCP и ActiveDirectory. В заключение необходимо отметить, что в обеих реализациях DNS-серверов присутствуют функции контроля работы и протоколирования событий, связанных с функционированием DNS-серверов. Данная возможность, в случае если ей не пренебрегает системный администратор, позволяет эффективно устранять неполадки и оптимизировать работу сервера.Список использованной литературы.RFC 1034 — Доменные имена — Основные понятия. IETF. 1987.RFC 1035 — Доменные имена — Применение и спецификации. IETF. 1987.RFC 1591 — Доменные имена — Структура и делегирование IETF. 1983.RFC 4033 – DNS введение в безопасность и требования. 2005.RFC 4035 – Модификация протокола для расширений безопасности DNS. 2005.В. Олифер, Н. Олифер. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд. — Санкт-Петербург: Питер, 2010, 944 с.Дж. Буравчик. Локальная сеть без проблем: подробное иллюстрированное руководство – Москва: Лучшие книги, 2005, 224 с.У. Одом. Официальное руководство по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 – Москва: Вильямс, 2009, 664 с.Э. Немет, Г. Снайдер, Т. Хейн. Руководство администратора Linux. Установка и настройка. – Москва: Вильямс, 2011, 1072 с.К. Хант, TCP/IP — Сетевое администрирование — Москва: Cumbo, 2008, 816 c. А. Стахнов. Сеть для офиса и LINUX-сервер своими руками. — Москва: БХВ-Петербург, 207, 320 с.А. Старовойтов. Сеть на LINUX. Проектирование, прокладка, эксплуатация — Москва: БХВ-Петербург, 2010, 288 с.Т. Адельштайн, Б. Любанович. Системное администрирование в Linux. – Санкт-Петербург: Питер, 2009, 288 с.К. Ли, П. Альбитц. DNS и BIND. 5 изд. — Москва: Символ-Плюс, 2008, 712 с.Д. Колисниченко. FreeBSD. От новичка к профессионалу. — Москва: БХВ-Петербург, 2011, 544 с.М. Фленов. Linux глазами хакера. — Москва: БХВ-Петербург, 2010, 480 с.П. Шетка. Microsoft Windows server 2003. Практическое руководство по настройки сети – Москва: Наука и техника, 2006, 608 с.М. Ногл, TCP/IP. Иллюстрированный учебник. – Москва: ДМК Пресс, 2011, 480 с.Л. Досталек, А. Кабелова, TCP/IP и DNS в теории и на практике. Полное руководство. — Москва: Наука и техника, 2006 г. 608 с.Лора А. Чеппел, Эд Титтел. TCP/IP. Учебный курс. – Москва: БХВ-Петербурб, 2003, 437 c.Р. Моримото, М. Ноэл, О. Драуби, Р. Мистри, К. Амарис. Windows Server 2008 R2 Unleashed. – Москва: Вильямс, 2011, 1456 с.Свободная энциклопедия – http://ru.wikipedia.orgБаза знаний Microsoft – http://msdn.com

Список использованной литературы.

1.RFC 1034 — Доменные имена — Основные понятия. IETF. 1987.

2.RFC 1035 — Доменные имена — Применение и спецификации. IETF. 1987.

3.RFC 1591 — Доменные имена — Структура и делегирование IETF. 1983.

4.RFC 4033 – DNS введение в безопасность и требования. 2005.

5.RFC 4035 – Модификация протокола для расширений безопасности DNS. 2005.

6.В. Олифер, Н. Олифер. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 4-е изд. — Санкт-Петербург: Питер, 2010, 944 с.

7.Дж. Буравчик. Локальная сеть без проблем: подробное иллюстрированное руководство – Москва: Лучшие книги, 2005, 224 с.

8.У. Одом. Официальное руководство по подготовке к сертификационным экзаменам CCENT/CCNA ICND1 – Москва: Вильямс, 2009, 664 с.

9.Э. Немет, Г. Снайдер, Т. Хейн. Руководство администратора Linux. Установка и настройка. – Москва: Вильямс, 2011, 1072 с.

10.К. Хант, TCP/IP — Сетевое администрирование — Москва: Cumbo, 2008, 816 c.

11.А. Стахнов. Сеть для офиса и LINUX-сервер своими руками. — Москва: БХВ-Петербург, 207, 320 с.

12.А. Старовойтов. Сеть на LINUX. Проектирование, прокладка, эксплуатация — Москва: БХВ-Петербург, 2010, 288 с.

13.Т. Адельштайн, Б. Любанович. Системное администрирование в Linux. – Санкт-Петербург: Питер, 2009, 288 с.

14.К. Ли, П. Альбитц. DNS и BIND. 5 изд. — Москва: Символ-Плюс, 2008, 712 с.

15.Д. Колисниченко. FreeBSD. От новичка к профессионалу. — Москва: БХВ-Петербург, 2011, 544 с.

16.М. Фленов. Linux глазами хакера. — Москва: БХВ-Петербург, 2010, 480 с.

17.П. Шетка. Microsoft Windows server 2003. Практическое руководство по настройки сети – Москва: Наука и техника, 2006, 608 с.

18.М. Ногл, TCP/IP. Иллюстрированный учебник. – Москва: ДМК Пресс, 2011, 480 с.

19.Л. Досталек, А. Кабелова, TCP/IP и DNS в теории и на практике. Полное руководство. — Москва: Наука и техника, 2006 г. 608 с.

20.Лора А. Чеппел, Эд Титтел. TCP/IP. Учебный курс. – Москва: БХВ-Петербурб, 2003, 437 c.

21.Р. Моримото, М. Ноэл, О. Драуби, Р. Мистри, К. Амарис. Windows Server 2008 R2 Unleashed. – Москва: Вильямс, 2011, 1456 с.

22.Свободная энциклопедия – http://ru.wikipedia.org

23.База знаний Microsoft – http://msdn.com

Защита сервера DNS-Настройка безопасности

Защита сервера DNS-Настройка безопасности

Денис Колисниченко

Конфигурируя сервер, администраторы часто забывают правильно настроить службу DNS. После такой настройки DNS работает правильно: IP-адрес, разрешаются в имена компьютеров, и символов имя без проблем преобразуются в IP-адреса. На большинство администраторов и останавливаются: главное, чтобы работать. Работать-то он работает, но неправильно настроенный сервер DNS может стать огромная дыра в системе безопасности компании. Одно дело, когда сервер DNS обслуживает локальную сеть без выхода в Интернет: даже если кто-то будет пытаться «взломать» сервер, то для расчета «хакер» довольно просто. Но, в случае, если сеть предприятия подключена к Интернет, то узнать, кто же пытался взломать (или взломал) вашу сеть довольно сложно. Ущерб от взлома может обойтись компании в кругленькую сумму.

Прежде чем начать взлом в сети или отдельной системы злоумышленник (или группа злоумышленников) пытается собрать как можно больше информации: имя компьютера в сети, имя пользователя, версия установленного программного обеспечения. Всем кладовой полезной для взломщика информации будет неправильно настроена служба DNS (BIND). Рассмотрим небольшой пример: запустите утилиту nslookup и введите:

ls server.com

в Случае, если администратор забыл правильно настроить трансфер зоны, то кто угодно получит список компьютеров нашей сети:

[comp2.server.com] server.com. 323.111.200.2

server.com. server = comp1.server.com server.com. server = comp2.server.com server.com.

server = comp3.server.com почты 323.111.200.17 gold 323.111.200.22 www.ie 323.111.200.11

jersild 323.111.200.25 comp1 323.111.200.1 comp3 323.111.200.3 parasit3 323.111.200.20

www.press 323.111.200.30 comp1 323.111.200.1 www 323.111.200.2

Примечание. Чтобы не было недоразумений, не существует IP-адрес

чтобы не произошло непоправимого, разрешить перенос зоны только один компьютер — сервер, вторичный DNS вашей компании, если такие, конечно, есть. В файле конфигурации сервиса named /etc/named.конференции — изменить в разделе » параметры следующим образом:

options{

allow-transfer { 192.168.1.2; }; };

Вторичный сервер DNS, как правило, не передает никакой информации о зоне, поэтому, пожалуйста, укажите следующую строку в файл конфигурации /etc/named.конференции (в разделе options):