Налаштування DNS-сервера локальної мережі

Вступ

Тема налаштування системи доменних імен (DNS надалі) вибрана не випадково, на даному етапі розвитку Інтернету та нових технологій DNS є важливою складовою. Система доменних імен служить для перетворення імен серверів, сайтів, або користувача комп’ютерів в IP — адреси.

До появи служби DNS, системні адміністратори використовували службу WINS, яка також дозволяла перетворювати імена в IP — адреси, але тільки всередині локальної мережі, інакше кажучи, не можна було використовувати ім'я свого комп’ютера в глобальній мережі (наприклад, Інтернет).

До глобальної мережі Інтернет підключено безліч комп’ютерних одиниць. Як же керувати цими комп’ютерами, якщо вони відносяться до різних країн, мережам або групам? Для цього існують кілька елементів мережевої інфраструктури: система доменних імен (Domain Name System, DNS), яка збирає інформацію про імена й адреси комп’ютерів, і система IP — адрес з подальшою маршрутизацією, для контролю з'єднань між комп’ютерами.

Курсова робота присвячена налаштуванню DNSсервера.

Ця система створена для перетворення доменних імен комп’ютерів в IP — адреси, і навпаки IPадреси в імена комп’ютерів. Так як користувачам набагато зручніше працювати з іменами комп’ютерів, ніж з цифрами IPадрес, в той час як мережеве обладнання може працювати тільки з цифрами.

Крім організації перетворення імен DNS займається маршрутизацією електронної пошти, і організації доступу до сайтів Інтернету.

Мета курсового проекту розглянути теоретичні та практичні аспекти DNSсервера, зробити висновки.

Об'єкт дослідження — DNSсервер.

DNS складається з ресурсних записів зберігають відомості про комп’ютери, які автоматично можуть запитувати дані один про одного, а також обмінюватися інформацією.

З клієнтської частини для використання DNSсервера в налаштуваннях мережевої карти потрібно встановити IPадресу сервера DNS, після чого у разі DNS-запиту клієнтом якого або імені комп’ютера, він буде автоматично відправляти запит на DNS-сервер для впізнання адреси цього комп’ютера.

Доменне ім'я може складатися тільки з обмеженого набору ASCII символів, дозволяючи набрати адресу домену незалежно від мови користувача.

ICANN затвердив засновану на Punycode IDNA систему, перетворюючу будь-який рядок в кодуванні Unicode в допустимий DNS набір символів.

Домен — вузол в дереві імен, може складатися з ід доменів, доменне ім'я читається зліва направо від молодших доменів до доменів вищого рівня.

Першим йде кореневої домен, за ним йде домен першого рівня (наприклад, RU або COM), потім домени другого рівня, третього і т.д.

У роботі були розглянуті наукові праці Макина Дж.С.Лі К., У них описується принципи роботи DNS-сервера, його встановлення і налаштування, були приведені класифікації серверів імен.

Мета курсового проекту розглянути теоретичні та практичні аспекти DNSсервера, зробити висновки.

Якщо новий DNS-сервер встановлений не на контролері домена, як правило, необхідно виконати певні завдання для його налаштування.

Створити зону прямого і (якщо необхідно) зворотного перегляду.

Визначити, чи будуть дозволені на сервері динамічні оновлення, включаючи небезпечні оновлення.

Визначити, чи пересилатимуться запити і на які сервери.

Щоб настроїти новий DNSсервер за допомогою засобів інтерфейсу Windows

Відкрийте диспетчер DNS.

При необхідності додайте потрібний сервер в оснащення, потім підключитеся до нього.

У дереві консолі клацніть необхідний DNSсервер.

У меню Дію виберіть команду Конфігурація DNSсервера.

Наслідуйте інструкції майстра налаштування DNSсервера.

1. База даних DNS

DNS — це розподілена база даних. Така структура дає можливість локально керувати окремими сегментами загальної бази, а також дозволяє зробити дані кожного сегмента доступними всій мережі за допомогою використання механізму «клієнт-сервер». Надійність і адекватна продуктивність, заснована на реплікації і кешуванні.

База даних домену являє собою набір зон, які створює вручну системний адміністратор на головному сервері DNS. У свою чергу в елементах званих зона, створюються ресурсні записи.

1.1 Типи зон

Основна зона — зберігає ресурсні записи для всіх доменів в зоні. Резервна копія бази даних зони може створюватися у додатковій зоні. В основній зоні можна створювати і видаляти ресурсні записи, проте видалення запису з основної зони вплине на видалення цього запису з додаткових зон.

Додаткова зона — резервна зона для основної зони або інших додаткових зон. Записи з додатковою зоною можна тільки прочитати, видалення або створення записів в даному типі зон не доступний.

Зона — заглушка (розміщується на сервері) — копія зони, що містить тільки записи ресурсів повноважних DNSсерверів головної зони (майстер зони).

1.2 Ресурсні записи

Існують різні типи ресурсних записів, в основному використовуються близько 10 типів. З появою стандарту IPv6 додалося ще кілька типів ресурсних записів (Таблиця 2).

Ресурсні записи умовно можна поділити на чотири групи:

* Записи зони — містять записи про домени і серверах імен;

* Базові запису — містять записи для перетворення імен в IP — адреси і для маршрутизації пошти;

* Записи аутентифікації - містять записи, що зберігають дані про аутентифікації, підписах і делегування;

* Допоміжні запису — надають додаткову інформацію.

Таблиця 1 — Типи ресурсних записів

Крім записів наведених вище, існують і інші, але використовувані набагато рідше, або застарілі. В основному ресурсні записи створюються вручну, але в деяких випадках можливе створення ресурсні записів в базі даних DNS автоматично, як приклад: налаштування служби DHCP (протокол динамічної конфігурації хоста, Протокол динамічної конфігурації вузла) у зв’язці з DNSсервером. У такому випадку в записі будуть створюватися автоматично по мірі присвоєння комп’ютера IPадреси за допомогою DHCPсервера.

Файл зони — це місце, де визначені відображення імен хостів та IPадрес всередині домену, це також місце, де зазвичай допускається більшість помилок в конфігурації BIND.

Файл зони містить у собі ресурсні записи, інформацію про зону, та інше. Для кожного домену, і піддомена, повинен бути створений окремий файл зони. Це можна застосовувати тільки при налаштуванні сервера DNS на UNIX подібних операційних системах.

Запис SOA (Start влади — початок повноважень), використовується для ведення «історії» зони, тобто веде кількість змін, що відбулися на зоні. Запис SOA містить у собі ім'я зони, адресу адміністрації зони, порядковий номер, а також дані про оновлення на зоні. Необхідна для звірки версій при реплікації між основним і вторинним сервером (основної та додаткової зони). У кожній зоні міститься тільки один запис SOA.

Нижче показаний приклад запису SOA, на основі служби BIND9, FedoraLinux:

;Початок зони для домену cs.company.com

@ IN SOA ns.cs.company.com. hostmaster.cs.company.com. (

20 072 223 100;Порядковий номер 7200;Період оновлення 1800;Інтервал між спробами 604 800;Інтервал застарівання 7200);Мінімальний час життя Період оновлення задає періодичність оновлення даних. Заданий час вказує, як часто додаткові сервери повинні зв’язуватися з головним сервером і звіряти, чи не змінити порядковий номер. У разі якщо база даних головного сервера змінилася, то порядковий номер змінитися (стане більше), в такому випадку додаткові сервери звернуться до головного сервера з запитом на оновлення зони. Найчастіше час на період частоти оновлення ставлять від одного до шести годин.

Крім оновлення зони по закінченню періоду поновлення, існує параметр «Повідомити «, у разі якщо цей параметр не вимкнений і правильно налаштований, головний сервер буде сам відправляти повідомлення підлеглим серверам про відбулися оновленнях. У разі високого навантаження мережі сповіщення про оновлення може бути втрачено. Другий елемент: «Інтервал між спробами «діє в ситуації, якщо підлеглий сервер звернувся до головного сервера, а той не відповів, в такому випадку підлеглий сервер повторить свій запит по закінченню цього періоду. Значення має бути менше значення виставленого на «Період оновлення», найчастіше значення варіюється від 20 до 60 хвилин. Третій елемент: «Інтервал застарівання», якщо головний сервер довгий час не відповідає на запити від підлеглих серверів, то підлеглі сервери будуть намагатися оновити дані бази даних таким чином «засмічуючи «мережа непотрібними пакетами. Відповідно по закінченню періоду застарівання, підлеглі сервера перестануть звертатися до головного сервера за оновленнями. Рекомендоване значення від тижня до місяця. Мінімальний час життя визначає інтервал застарівання записи в базі даних DNS. Якщо клієнтом DNSсервера був портативний комп’ютер, який використовував дану базу даних тільки один раз, то після закінчення періоду запис про цей комп’ютер буде видалена.

1.3 Категорії записів

Записи NS (сервер імен — сервер імен) містять в собі дані про сервери імен (DNSсерверах), які авторитетні для зони (головні і підлеглі сервера). Записи IN NS зазвичай стоять після запису IN SOA.

Формат записів NS:

Зона [TTL] IN NS імя_хоста приклад:

cs.company.com. У NS ns1.cs.company.com.

cs.company.com. У NS ns2.cs.company.com.

cs.company.com. У NS nc1.cs.company.com.

У разі якщо ім'я зони збігається з ім'ям запису SOA, тоді поле «Зона «можна опустити:

У NS ns1.cs.company.com.

У NS ns2.cs.company.com.

У NS nc1.cs.company.com.

Таким чином, ці рядки, будуть еквіваленти наведеним вище.

записи Записи (адреса — адреса), складають основну частину бази даних DNS. Вони займаються наданням інформації при перетворенні імен комп’ютерів в IP — адреси. Раніше ця інформація містився локально на кожному комп’ютері у файлі / і т.д. / хости. Як правило, для кожного мережевого інтерфейсу існує один запис у А.

Формат запису:

імя_хоста [TTL] в IP — адресу приклад:

comp1 в 192.168.0.74

У разі якщо у комп’ютера кілька IPадрес, то можна прив’язати всі IPадреси до одного запису, або створити для кожного IPадреси окремий запис.

записи PTR

Записи PTR (Pointer — покажчик) забезпечує зворотний переклад IPадрес в імена. На кожен мережевий інтерфейс, також як і в записах в, створюється окремий запис IN PTR.

Формат запису PTR:

адреса [TTL] IN PTR імя_хоста приклад:

74 у comp1.cs.company.com PTR

Важливо, щоб записи в збігалися із записами IN PTR. У випадках невідповідності і відсутності останніх приводить до помилок роботи DNSсервера, в результаті чого продуктивність сервера може бути знижена.

записи MX

Записи MX (поштовий обмінник — обмін поштою) використовується для маршрутизації поштових повідомлень між поштовими серверами. Запис MX забезпечує доставку електронних повідомлень на поштові сервера одержувача.

Формат запису MX:

ім'я [TTL] IN MX пріоритет хост…

приклад:

SMTP IN MX 10 mail1.company.com.

IN MX 40 mail3.company.com.

IN MX 70 mail2.company.com.

Треба зауважити, що ім'я хоста повинно в обов’язково порядку мати власну в запис на даному сервері DNS. Записи CNAME не можуть мати власних MXзаписів.

Маршрутизація здійснюється за наступним шляхом, спочатку опитуються хости з найнижчим пріоритетом, потім у разі якщо попередній сервер не відповів, опитується хост з вищим пріоритетом (найбільш бажаний пріоритет — 0, самий небажаний — 65 535). Наприклад, пошта, адресована користувачеві [email protected] по протоколу SMTP, маршрутизироваться наступним чином: спочатку пошта спрямовується на сервер mail1, якщо mail1 не доступний, пошта буде перенаправлено на сервер mail3, якщо обидва сервера не доступні, то пошта відправиться на сервер mail2.

Налаштування пріоритетів MXзаписів необхідна у разі наявності великого парку поштових серверів, і великого обороту електронної кореспонденції щодня. Наприклад, у разі великого навантаження на пріоритетні сервера, пошта буде перенаправяется на менш пріоритетні сервера. Це дозволить зменшити загальну навантаження на сервера пошти та забезпечити її безвідмовність.

записи CNAME

Записи CNAME (канонічне ім'я — канонічне ім'я) дозволяють призначати комп’ютера додаткові імена (псевдоніми). Найчастіше псевдоніми застосовуються для позначення функції виконуваної комп’ютером, або для скорочення імені.

Формат запису CNAME:

псевдонім [TTL] IN CNAME імя_хоста приклад:

FTP IN CNAME comp1

Кіно в CNAME PC409578

Іоанна в CNAME JNicholson

Псевдоніми прив’язуються до записів у, або до інших записів CNAME, проте ланцюжок записів CNAME не повинна перевищувати восьми. Ланцюжок записів CNAME це коли запис CNAME посилається на інший запис CNAME, наприкінці ланцюжок обов’язково має бути запис A.

Як правило, деякі адміністратори взагалі не використовують записи CNAME, замінюючи їх записами А. Якщо у домену багато записів з одним IPадресою, він прописується одного разу на один хост, решта хости посилаються на цей хост записами CNAME, у разі зміни цього IPадреси (наприклад, зміна хостингу) достатньо змінити один запис А, на яку посилаються CNAMEзаписи, і їх значення автоматично зміняться.

Записи LOC використовуються для визначення географічного розташування і в деяких випадках фізичний розмір об'єкта DNS. На даний момент використання записів LOC не є обов’язковим, вони носять скоріше статистичний характер для організацій, що займаються мережевим аналізом.

Рідке використання даного типу записів пояснюється, так само тим, що більшість адміністраторів не хочуть викладати територіальне місцезнаходження своїх серверів, щоб зберігати анонімність.

Формат запису LOC:

ім'я [TTL] у ВХ широта довгота [висота [розмір [горіз_точн [верт_точн]]]]

приклад:

company.org. У ВХ 37 55 07 N 113 18 29 W 100 м 20 м 35 м 18 м Широта і довгота вказуються в градусах, хвилинах і секундах (розділяються пробілами), після яких іде позначення N (північ — північ), S (південь — південь), E (схід — схід), або W (захід — захід). Допускається писати тільки градуси.

Записи SRV визначають місцезнаходження служб, в межах домену. Широко використовуються для знаходження яка служба, на якій комп’ютері виконується. До появи цих записів адміністраторам доводилося працювати навмання, наприклад щоб знайти FTPсервер, адміністратори б сподівалися, що за традицією створена запис CNAME для імені «FTP «.

Записи SRV трохи схожі на записи MX, так як в них так само можна розподілити пріоритети, і навантаження.

Формат запису SRV:

служба.протокол.імя [TTL] в СРВ пріоритет вага порт сервер Приклад (узятий з документів RFC2052 і RFC2782):

_ftp._tcp SRV 0 0 21 FTPserver. cs1.company.com.

(- '.' Ім'я сервера) доступ до служби Finger закрито

_finger._tcp SRV 0 0 79.

;Одна чверть сполук обслуговується старим комп’ютером,

;А три чверті - новим

_ssh._tcp SRV 0 22 січня старих повільних box. cs1.company.com.

SRV 0 22 березня нових швидких box. cs1.company.com.

;Основний сервер доступний через порт 80,

;А резервний — через порт 8000 на новому комп’ютері

_http._tcp SRV 0 0 80 WWWserver. cs1.company.com.

SRV 10 0 8000 новий швидкий box. cs1.company.com.

;В адресному рядку можна вказувати як http://www.cs1.company.com,

;Так і http://cs1.company.com

_http._tcp SRV 0 0 80 WWWserver. cs1.company.com.

SRV 10 0 8000 новий швидкий box. cs1.company.com.

;Всі інші служби блоковані

*. _tcp SRV 0 0 0.

*. _udp SRV 0 0 0.

записи TXT

Записи TXT використовується для додавання в базу даних DNS довільний текст.

TXT Формат запису:

ім'я [TTL] IN TXT інформація…

приклад:

випробування в TXT «Тестовий запис «

Усі інформаційні дані повинні бути укладені в лапки, це може бути одна або кілька рядків, кожна з яких була взята в лапки. У разі неправильної постановки лапок, частина тексту може мимоволі піти.

Також деякі адміністратори використовують записи TXT, для використання в них записів SPF (Sender Policy Framework — Структура політики відправника), за допомогою яких можна визначати і видаляти повідомлення шкідливого або рекламного характеру («спам «).

Приклад використання в записах SPF TXT:

mailsite.com. У TXT «V = spf1 ip4: 179.238.23.65 ip4: 98.224.134.83 ip4: 210.234.62.81 ip4: 177.234.68.14 ~ все»

test.com. У TXT «V = spf1 MX PTRвсе «

У першому прикладі перераховуються IPадреси поштових серверів домену mailsite.com, якщо електронне повідомлення нібито прийшло від домену mailsite.com, але IPадреса не збігається ні з однією IP-адресою перерахованому в списку SPF, лист віддалиться.

У другому прикладі, потрібно, щоб поштовий сервер, з якого надіслано електронне повідомлення, мав відповідні його домену запису MX і PTR.

Запис АААА використовується для перетворення імен комп’ютерів в IP — адресу версії IPv6. IPадреси версії IPv6 були створені для запобігання кризи IPадрес версії IPv4 які широко використовуються на даний момент, але з використанням протоколу CIDR, і доцільним розподілом IPадрес, IPv6 поки не отримав широкого застосування.

Формат запису AAAA:

ім'я [TTL] IN AAAA IPадреса приклад:

test.com. У AAAA 232:40: a021: 1b: 21:04 BFF: 2d24

Зворотне перетворення IPадреси версії IPv6 виконує запис PTR, і зберігається в домені верхнього рівня ip6.arpa.

Команди для роботи з DNS

Служба доменних імен (Domain Name Service, DNS) — це магічний протокол, який дозволяє вашому комп’ютеру перетворювати імена доменів на зразок www.slackware.com в IP — адреси на зразок 64.57.102.34. Комп’ютери не можуть визначити маршрут пакетів до www.slackware.com, однак вони можуть визначити маршрут до IPадресою цього домену. Так забезпечується зручний спосіб запам’ятовування машин.

Для цього використовується декілька дуже корисних утиліт для роботи з доменними іменами, вони все встановлюються разом з пакетом BIND: господар, Nslookup і Dig.

господар — призначена для виконання запитів і отримання короткої інформації від DNS серверів (є тільки в UNIX подібних ОС).

приклад:

$ HOST www.tkh.local

www.tkh.local 192.168.153.129

Nslookup — інтерактивна утиліта для формування запитів з серверу імен (існує як в Windows, так і UNIX подібних ОС).

приклад:

Nslookup

Smtp.tkh.local

Сервер: ТКН — dns001.tkh.local

Адреса: 192.168.153.129

Номери для авторитетну відповідь:

Ім'я: ТКН — mail001.tkh.local

Адреса: 192.168.153.111

Синоніми: smpt.tkh.local

Dig — (інформація про домен Groper) дозволяє здійснювати запити до DNS-сервера, є більш функціональним аналогом Nslookup, при цьому також надає інтерактивний інтерфейс в командному рядку.

приклад:

$ [email protected] tkh. local MX;

DiG 9.3.2 @ 192.168.153.129 tkh. local MX;

(1 сервер знайдене);

Глобальні опції: printcmd;

Отримав відповідь:

HEADERAdministrative Сервіс — > DNS;

На головній сторінці консолі управління DNS сервером, видно ім'я DNSсервера (Рис. 1.1):

ТКН — DNS001

Зону прямого перегляду (Зони прямого перегляду):

tkh.local

Зону зворотного перегляду (Зони зворотного перегляду):

192.168.153.x

Рис. 1.1 — Консоль управління сервером DNS

база данні команда сервер Якщо перейти в зону прямого перегляду tkh. local, можна побачити ресурсні записи (Рис 1.2):

SOAзапис говорить нам про те, що в зоні tkh. local з моменту її встановлення сталося тільки 8 змін;

NSзапис повідомляє, що сервером імен є ТКН — dns001.tkh.local;

MXзапис, займається маршрутизацією пошти на сервер ТКН — mail001.tkh.local з пріоритетом 10, але так як MXзапис в нашій зоні одна, пріоритет не грає ніякої ролі;

CNAMEзаписи Лондоні і SMTP, це символічні імена на Азапису ТКН — dns001.tkh.local і ТКН — mail001.tkh.local відповідно.

Aзаписи, повідомляють, що ім'я ТКН — dns001 і ТКН — mail001 мають IPадреси 192.168.153.129 і 192.168.153.111 відповідно, а також DNSсуфікс: tkh. local

Рис. 1.2 — Ресурсні записи зони прямого перегляду Далі треба перейти у вкладку зона зворотного перегляду 192.168.153.x підмережі (Рис. 1.2).

В основному зона зворотного перегляду містить PTR запису, тобто зворотні «А» записам, але також тут присутні SOA і NS записи, для реплікації між серверами DNS.

PTR запису, повідомляють про те, що за IP адресами 192.168.153.111 і 192.168.153.129 доступні відповідні комп’ютери з іменами ТКН — mail001.tkh.local і ТКН — dns001.tkh.local.

Рис. 1.3 — Ресурсні записи зони зворотного перегляду Створення ресурсних записів Ресурсні записи на DNS — сервері, можуть створюватися кількома способами:

1. Вручну, шляхом створення ресурсних записів

2. автоматично

DNSклієнти реєструють самі себе на DNS — сервері

б. DHCP сервер передає інформацію про своїх клієнтів на DNSсервер

C. Контролер домену передає інформацію про комп’ютери, що вступили в домен на DNSсервер Для автоматичної реєстрації DNS клієнтами самих себе на DNSсервер, необхідно, щоб в налаштуваннях зони було дозволено небезпечне оновлення зони (Рис. 1.4).

Зона Властивості - > Загальні - > Динамічні поновлення -> Номери безпечний і безпечний Рис. 1.4 — Налагодження динамічного оновлення DNS сервера З боку DNS клієнта також необхідно провести ряд налаштувань, після яких DNS клієнт зможе самостійно створювати і оновлювати запис про себе на DNSсервері.

Типово DNSклієнти зі статичними IPадресами та відповідними доменними суфіксами намагаються реєструвати й обновляти запису ресурсів, А і PTR, звертаючись до основного сервера DNS. А клієнти, які отримують адресу у DHCPсервера, реєструють і оновлюють через основний DNS сервер тільки записи. В останньому випадку запису ресурсів PTR оновлюються DHCP сервером при виділенні IPадреси в оренду.

Для клієнтів для Windows, які не підтримують динамічне оновлення, наприклад DNSклієнтів під управлінням Windows Me або Windows NT 4, обох типів, А і PTR може від їхнього імені виконувати відповідним чином налаштований сервер DHCP. Щоб налаштувати DNSклієнта на виконання динамічних оновлень в DNS, необхідно встановити прапорець «Регістр адреси цього підключення в DNS» (Рис. 1.5) На вкладці DNS вікна Додаткові параметри TCP / IP Settings [2, c.143].

Рис. 1.5 — Налаштування параметрів TCP / IP

DNSклієнт стане реєструвати й обновляти повне ім'я комп’ютера (основний доменне ім'я). Якщо визначений DNS суфікс для підключення, можна також налаштувати DNSклієнт на динамічну реєстрацію і оновлення повного імені FQDN, заснованого на цьому суфіксі: Для цього потрібно відзначити прапорець «Використовувати суфікс цього підключення в DNS Реєстрація «(Рис. 1.5). Після чого в меню Advanced TCP / IP Settings треба натиснути кнопку OK, для застосування налаштувань.

Рис. 1.6 — Налаштування параметрів TCP / IP

Щоб DNS клієнт став реєструвати, А і PTR запису безпосередньо на DNSсервері необхідно виконати команду (Рис. 1.7): IPCONFIG / registerdns

Рис. 1.7 — Виконання команд у командному рядку Це може зайняти деякий час.

Створення ресурсних записів вручну Для створення Записи, А вручну, необхідно відкрити консоль DNS, вибрати зону, в меню Дія, вибрати New Host (A). И Після чого необхідно заповнити відповідні поля, створення інших ресурсних записів здійснюється подібним способом.

У разі створення Aзаписів, при установки галочки в полі «Створити відповідну покажчика (PTR) Рекорд «, автоматично буде створена зворотна PTR запис, у відповідній зони зворотного перегляду. Якщо зворотної зони відповідної прямої зоні не існує, то PTR запис створений не буде.

2. Практична частина

2.1 Налаштування DNS

По завершенню консоль управління DNSсервером можна буде знайти в меню Пуск |Програми|Адміністрування|DNS. У Windows 2008 вбудований майстер налаштування DNSсервера Для конфігурації DNSсервера знадобляться дізнатися значення наступних термінів:

1. Зона прямого перегляду

2. Зона зворотного перегляду

3. Типи зон Зона прямого перегляду відповідає за перетворення імен хостів в IPадреси. Зона зворотного перегляду відповідає за розпізнавання DNSсервером DNSімені хоста, тобто, по суті, це антипод зони прямого перегляду. Наявність зони зворотного перегляду не обов’язково, але вона легко настроюється і забезпечує повну функціональність DNS в Windows Server 2008 Server.

При виборі типу зони DNS дані наступні варіанти: Інтегрована в AD, Основна і Додаткова. Зона «AD Integrated «зберігає інформацію про розподіленої базі даних в AD і дозволяє здійснювати безпечне оновлення файлу бази даних. Ця опція доступна тільки при відповідній настройці AD. Якщо вибрати її, AD буде зберігати і тиражувати файли зони.

Основна зона зберігає базу даних у текстовому файлі, доступ до якого можуть отримати інші DNSсервери, також зберігають інформацію в текстових файлах. Нарешті додаткова зона створює копію існуючої бази даних іншого DNSпівночі. Це потрібно для вирівнювання навантаження.

Щоб відкрити майстер налаштування DNSсервера:

1. Відкрийте консоль Диспетчер сервера (Рисунок 2.1).

2. Розгорніть послідовно вузли Ролі, DNS-сервер і DNS, після чого клацніть на ім'я серверу DNS (Рисунок 2.2).

3. У меню Дія виберіть пункт Налаштувати DNS-сервер (Рисунок 2.3).

4. На сторінці привітання майстра налаштування серверу DNS клацніть на кнопці Далі (Рисунок 2.4).

5. Виберіть перемикач Створити зони прямого і зворотного перегляду

(рекомендується для великих мереж) і клацніть на кнопці Далі (Рисунок 2.5).

6. Виберіть варіант Так, створити зону прямого перегляду зараз (рекомендується) і клацніть на кнопці Далі (Рисунок 2.6).

7. Вкажіть, зону якого типу потрібно створити, в даному випадку вибравши варіант Основна зона, і клацніть на кнопці Далі. Якщо сервер є контролером домену з доступом для запису, для вибору буде також доступний прапорець Зберегти зону в Active Directory. (Рисунок 2.7).

8. У разі збереження зони в Active Directory виберіть область реплікації і клацніть на кнопці Далі.

9. Введіть повністю певне доменне ім'я зони (FQDN) у полі Ім'я зони і клацніть на кнопці Далі. (Рисунок 2.8).

10. На цьому етапі у разі утворення не интегрируемой з AD зони можна або створити новий текстовий файл для зони, або імпортувати вже існуючий. У даному випадку виберіть варіант Створити новий файл з таким ім'ям і залиште пропоновані за умовчанням параметри, після чого для продовження клацніть на кнопці Далі. (Рисунок 2.9).

11. На наступній сторінці буде запропоновано дозволити або заборонити прийом динамічних оновлень сервером DNS. У розглянутому прикладі заборонимо DNS-сервера приймати динамічні оновлення, вибравши перемикач Заборонити динамічні обновлення, і клацніть на кнопці Далі. (Рисунок 2.10).

12. На наступній сторінці пропонується створити зону зворотного перегляду. У даному випадку виберіть перемикач Так, створити зону зворотногперегляду зараз і клацніть на кнопці Далі. (Рисунок 2.11).

13. Вкажіть, що зона зворотного перегляду повинна являти собою основну зону, вибравши перелючателя Основна зона, і клацніть на кнопці Далі. (Рисунок 2.12).

14. У разі збереження цієї зони в Active Directory виберіть область реплікації і клацніть на кнопці Далі.

15. Залиште вибраним пропонований за замовчуванням варіант Зона зворотного перегляду IPv4 і клацніть на кнопці Далі. (Рисунок 2.13).

16. Введіть ідентифікатор мережі для зони зворотнього перегляду і клацніть на кнопці Далі. (Як правило, в якості мережевого ідентифікатора вводиться перший набір октетів з IP-адреси зони. Наприклад, якщо в мережі використовується діапазон IP-адрес класу С 192.168.0.0/24, то в якості мережевого ідентифікатора можуть бути введено значення 192.168.0 (Рисунок 2.14).

17. У разі утворення не інтегріруемой з AD зони буде знову запропоновано або створити новий файл для зони, або імпортувати вже існуючий. У розглянутому прикладі виберіть перемикач Створити новий файл з таким ім'ям і клацніть на кнопці Далі. (Рисунок 2.15).

18. Після цього з’явиться запрошення вказати, чи повинні бути дозволені динамічні оновлення. Для цілей цього прикладу виберіть перемикач Заборонити динамічні оновлення і клацніть на кнопці Далі. (Рисунок 2.16).

19. На наступній сторінці буде запропоновано налаштувати параметри ретрансляторів. У розглянутому прикладі виберіть перемикач Ні, не слід переадресовувати запити і клацніть на кнопці Далі. (Рисунок 2.17).

20. На останньому екрані будуть представлені зведені відомості про обраних для внесення і додавання в базу даних DNS зміни та зонах. Клацніть на кнопці Готово, щоб внести всі ці зміни і створити потрібні зони. (Рисунок 2.18).

1. Відкрийте консоль Диспетчер сервера.

Рис. 2.1 — Відкритий консоль Диспетчер сервера

2. Розгорніть послідовно вузли Ролі, DNS-сервер і DNS, після чого клацніть на ім'я серверу DNS.

Рис. 2.2 — Відкритий консоль користувача GRAN

3. У меню Дія виберіть пункт Налаштувати DNS-сервер.

Рис. 2.3 — Вибираємо пункт Налаштувати DNS-сервер

4. На сторінці привітання майстра налаштування серверу DNS клацніть на кнопці Далі.

Рис. 2.4 — Сторінка майстра налаштування серверу DNS

5. Виберіть перемикач Створити зони прямого і зворотного перегляду (рекомендується для великих мереж) і клацніть на кнопці Далі.

Рис. 2.5 — Виберемо дію Створити зони прямого і зворотного перегляду

6. Виберіть варіант Так, створити зону прямого перегляду зараз (рекомендується) і клацніть на кнопці Далі.

Рис. 2.6 — Зона прямого перегляду

7. Вкажіть, зону якого типу потрібно створити, в даному випадку вибравши варіант Основна зона, і клацніть на кнопці Далі. Якщо сервер є контролером домену з доступом для запису, для вибору буде також доступний прапорець Зберегти зону в Active Directory.

Рис. 2.7 — Вибираємо Тип зони

8. У разі збереження зони в Active Directory виберіть область реплікації і клацніть на кнопці Далі.

9. Введіть повністю певне доменне ім'я зони (FQDN) у полі Ім'я зони і клацніть на кнопці Далі.

Рис. 2.8 — Вводимо ім'я зони (FQDN)

10. На цьому етапі у разі утворення не інтегруємої з AD зони можна або створити новий текстовий файл для зони, або імпортувати вже існуючий. У даному випадку виберіть варіант Створити новий файл з таким ім'ям і залиште пропоновані за умовчанням параметри, після чого для продовження клацніть на кнопці Далі.

Рис. 2.9 — Створюємо новий файл

11. На наступній сторінці буде запропоновано дозволити або заборонити прийом динамічних оновлень сервером DNS. У розглянутому прикладі заборонимо DNS-сервера приймати динамічні оновлення, вибравши перемикач Заборонити динамічні обновлення, і клацніть на кнопці Далі.

Рис. 2.10 — Вибираємо «Заборонити прийом динамічних оновлень сервером DNS»

12. На наступній сторінці пропонується створити зону зворотного перегляду. У даному випадку виберіть перемикач Так, створити зону зворотного перегляду зараз і клацніть на кнопці Далі.

Рис. 2.11 — Створюємо зону зворотного перегляду

13. Вкажіть, що зона зворотного перегляду повинна являти собою основну зону, вибравши перелючателя Основна зона, і клацніть на кнопці Далі.

Рис. 2.12 Вибираємо «Основну зону»

14. У разі збереження цієї зони в Active Directory виберіть область реплікації і клацніть на кнопці Далі.

15. Залиште вибраним пропонований за замовчуванням варіант Зона зворотного перегляду IPv4 і клацніть на кнопці Далі.

Рис. 2.13 — Вибираємо пропонований варіант «Зона зворотного перегляду IPv4»

16. Введіть ідентифікатор мережі для зони зворотного перегляду і клацніть на кнопці Далі. (Як правило, в якості мережевого ідентифікатора вводиться перший набір октетів з IP-адреси зони. Наприклад, якщо в мережі використовується діапазон IP-адрес класу С 192.168.0.0/24, то в якості мережевого ідентифікатора можуть бути введено значення 192.168.0.

Рис. 2.14 — Вводимо ідентифікатор мережі для зони зворотного перегляду

17. У разі утворення не інтегруємої з AD зони буде знову запропоновано або створити новий файл для зони, або імпортувати вже існуючий. У розглянутому прикладі виберіть перемикач Створити новий файл з таким ім'ям і клацніть на кнопці Далі.

Рис. 2.15 — Створюємо новий файл для зони

18. Після цього з’явиться запрошення вказати, чи повинні бути дозволені динамічні оновлення. Для цілей цього прикладу виберіть перемикач Заборонити динамічні оновлення і клацніть на кнопці Далі.

Рис. 2.16 — Вибираємо Заборонити динамічні оновлення

19. На наступній сторінці буде запропоновано налаштувати параметри ретрансляторів. У розглянутому прикладі виберіть перемикач Ні, не слід переадресовувати запити і клацніть на кнопці Далі.

Рис. 2.17 — Натискаємо Не слід переадресовувати запити Рис. 2.18 — Пошук кореневих посилань

20. На останньому екрані будуть представлені зведені відомості про обраних для внесення і додавання в базу даних DNS зміни та зонах. Клацніть на кнопці Готово, щоб внести всі ці зміни і створити потрібні зони.

Рис. 2.19 — Завершення майстра налаштування DNS-серверу

2.2 Налаштування вузлів DNS

Далі необхідно налаштувати вузли, які будуть використовувати цей DNS-сервер.

Відкрийте консоль Диспетчер сервера. Розгорніть послідовно вузли Ролі, DNS-сервер, DNS, ім'я сервера, зони прямого перегляду і виділяємо створену нами зону:

Рис. 2.20 — Диспетчер сервера Двічі клацніть на елементі «сервер імен»

Рис. 2.21 — Сервер імен Відкриється вікно властивостей створеної нами зони

Рис. 2.22 — Вікно властивостей створеної нами зони Виділяємо ім'я нашого сервера і натискаємо «змінити», відкриється вікно редагування записів:

Рис. 2.23 — Вікно редагування записів Виділяємо ім'я нашого сервера і натискаємо «Дозволити на адресу»

Рис. 2.24 — Редагуємо запис сервера імен Тиснемо «OK», «застосувати» і «OK»

Рис. 2.25 — Сервер імен Рис. 2.26 — Сервер імен Клацаємо мишкою у вікні зони, в меню, вибираємо «створити вузол А»

Рис. 2.27 — Створюємо вузол А

Тут вводимо IP-адресу де знаходиться наш сайт і натискаємо «Додати вузол»

Рис. 2.28 — Додаємо новий вузол Якщо сайт розташований не на цьому сервері може з’явиться попередження. Тиснемо OК.

Рис. 2.29 — Попередження

Висновок

Дана курсова робота складається з двох основних частин, теоретична частина і практична. Теорія складається з загальної інформації про роботу системи доменних імен, ця інформація може бути актуальна при роботі з DNS сервером на будь-якій операційній системі. Тим не менше, основні приклади, використовувані в теорії, використовувалися на основі DNS службі розгорнутої на базі операційної системи Windows Server 2008 R2.

Практична частина містить, встановлення та налаштування служби DNS на операційній системі Windows Server 2008 R2, більша частина налаштування показана на основі графічного інтерфейсу, так як в такому випадку вся настройка відбувається більш прозоро і доступно для сприйняття.

Подальше вивчення даної дисципліни дозволить вивчити роботу служби DNS на UNIX серверах, на основі BIND (Пакет для роботи зі службою DNS на UNIX — подібних операційних системах). Так як найбільші провайдери доменів в своїй основі використовують саме пакет BIND з UNIXподібної операційної системою на борту, чудово зарекомендувала себе як оптимальне рішення в питаннях відмовостійкості, використанні ресурсів та вартості.

Використання DNSсерверів внесло величезний внесок у розвиток не тільки локальної мережі окремої взятої організації, але також і інтернету в цілому. Якби не використання DNS служби, навряд чи можна було побачити інтернет таким, який він є зараз.

Список використаних джерел

1. Лі К. DNS і BIND: Науково — популярне видання / К. Лі, П. Альбітц — 5 — е видання: Пер. з англ. СПб:. Символ Плюс, 2008. — 712 с.

2. Макін Дж. С. Впровадження, управління та підтримка мережевої інфраструктури Microsoft Windows Server 2003. Навчальний курс MCSA / MCSE / Дж. С. Макін, Й. Маклін. — Пер. з англ. — М: «Російська Редакція «, 2004. — С. 108−248.

3. Немет Е. Керівництво адміністратора Linux: Науково — популярне видання / Е. Немет, Г. Снайдер, Т. Хейн. — 2 — е видання: Пер. з англ. — М:. ТОВ «. І, Вільямс», 2008. — С. 431−542.

4. ТАЙМ Б. FreeBSD 6. Повне керівництво: Пер. з англ. — М:. ТОВ «І.Д. Вільямс «, 2008. — С. 951−969.

5. Програми для роботи з DNS // Основи Slackware Linux 2006. — 12 червня [Електронний ресурс.] / Режим доступу до статті: http://jack.kiev.ua/docs/slackbook/basic-network-commands-dns.html

6. Мельников М. Двадцять найбільших DNSсерверів / / Хабрахабр. — 2007 [Електронний ресурс] / Режим доступу до статті: http://habrahabr.ru/blogs/domains/8120/

7. Мерц. Д. Іспит LPI: Domain Name System (DNS, Доменна система імен) // Росія Developerworks. — 2005. — 1 грудня [Електронний ресурс.] / Режим доступу до статті: http://www.ibm.com/developerworks/ru/edu/l-lpic2207/index.html

8. Система доменних імен // Вікіпедія. Вільна енциклопедія. — 2006. — 24 жовтень [Електронний ресурс.] / Режим доступу до статті: http://ru.wikipedia.org/wiki/DNS

9. Стан доменів в зоні SU // Акредитований реєстратор доменних імен -. 2011. — 6 жовтня [Електронний ресурс.] / Режим доступу до статті: http://stat.reg.ru/?tld=su

10. Статистика доменних імен в домені RU // Координаційний центр національного домену мережі Інтернет -. 2011. — 6 жовтня [Електронний ресурс] / Режим доступу до статті: http://cctld.ru/ru/statistics/domains.php

11. Статистика доменних імен в домені РФ // Координаційний центр національного домену мережі Інтернет -. 2011. — 6 жовтня [Електронний ресурс] / Режим доступу до статті: http://cctld.ru/ru/statistics/rfdomains.php

12. Статистика реєстрацій доменів у зоні UZ // Адміністрація доменної зони «UZ «-. 2011. — 6 жовтня [Електронний ресурс] / Режим доступу до статті: http://cctld.uz/stat/

13. Людина копати — системне керівництво // Проект OpenNet — 2004 [Електронний ресурс] / Режим доступу до статті: http://www.opennet.ru/man.shtml?topic=dig&category=1&russian=2

14. Людина господар — системне керівництво // Проект OpenNet — 2004 [Електронний ресурс] / Режим доступу до статті: http://www.opennet.ru/man.shtml?topic=host&category=1&russian=2

15. Людина Nslookup — системне керівництво // Проект OpenNet — 2004 [Електронний ресурс] / Режим доступу до статті: http://www.opennet.ru/man.shtml?topic=nslookup&category=1&russian=2

16. DNS і BIND:. Крикет Лі, Пол Альбітц — Москва, Символ-Плюс, 2008 р — 712 с.

17. FreeBSD. Від новачка до професіонала: Д.Н. Колісниченко — Санкт-Петербург, БХВПетербург, 2011 р -. 544 с.

18. Linux. Від новачка до професіонала (+ DVD):. Денис Колісниченко — Москва, БХВПетербург, 2011 р — 640 с.

19. Microsoft Exchange Server 2003. Довідник адміністратора: Уолтер Ж. Гленн, Білл Інгліш — СанктПетербург, Еком, 2007 р -. 720 с.

20. TCP / IP. Мережеве адміністрування:. Крейг Хант — Москва, СимволПлюс, 2006 р — 816 с.

21. Windows Server 2008 Server Core. Довідник адміністратора:. Мітч Таллоч — Москва, Російська Редакція, БХВПетербург, 2010 р — 392 с.

22. Windows Server 2008. Довідник адміністратора: Вільям Р. Станек — Санкт-Петербург, Російська Редакція, БХВПетербург, 2009 р -. 688 с.

23. Планування та підтримка мережевої інфраструктури Microsoft Windows Server 2003 (70−293) (+ CD — ROM): Крейг Закер, Дрю Берд — Москва, Еком, Біном. Лабораторія знань, 2006 р -. 480 с.

24. Самовчитель системного адміністратора Linux: Д. Колісниченко — Санкт-Петербург, БХВПетербург, 2011 р -. 544 с.

25. Серверне застосування Linux:. Денис Колісниченко — Москва, БХВ — Петербург, 2008 р — 528 с.

26. Мережа на LINUX. Проектування, прокладка, експлуатація. Олексій Старовойтов — Москва, БХВПетербург, 2006 р — 288 с.