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

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

Вступ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. База даних 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. (

;Порядковий номер 7200;Період оновлення 1800;Інтервал між спробами 604800;Інтервал застарівання 7200);Мінімальний час життя

Період оновлення задає періодичність оновлення даних. Заданий час вказує, як часто додаткові сервери повинні зв'язуватися з головним сервером і звіряти, чи не змінити порядковий номер. У разі якщо база даних головного сервера змінилася, то порядковий номер змінитися (стане більше), в такому випадку додаткові сервери звернуться до головного сервера з запитом на оновлення зони. Найчастіше час на період частоти оновлення ставлять від одного до шести годин.

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

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

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

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

Зона [TTL] IN NS імя_хоста

приклад:.company.com. У NS ns1.cs.company.com..company.com. У NS ns2.cs.company.com..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 - адресу

приклад:в 192.168.0.74

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

записи PTR

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

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

адреса [TTL] IN PTR імя_хоста

приклад:

у comp1.cs.company.com PTR

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

записи MX

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

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

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

приклад:IN MX 10 mail1.company.com.MX 40 mail3.company.com.MX 70 mail2.company.com.

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

Маршрутизація здійснюється за наступним шляхом, спочатку опитуються хости з найнижчим пріоритетом, потім у разі якщо попередній сервер не відповів, опитується хост з вищим пріоритетом (найбільш бажаний пріоритет - 0, самий небажаний - 65535). Наприклад, пошта, адресована користувачеві user@company.com по протоколу SMTP, маршрутизироваться наступним чином: спочатку пошта спрямовується на сервер mail1, якщо mail1 не доступний, пошта буде перенаправлено на сервер mail3, якщо обидва сервера не доступні, то пошта відправиться на сервер mail2.

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

записи CNAME

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

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

псевдонім [TTL] IN CNAME імя_хоста

приклад:IN CNAME comp1

Кіно в CNAME PC409578

Іоанна в CNAME JNicholson

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

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

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

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

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

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

приклад:.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 FTP- server.cs1.company.com.

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

_finger._tcp SRV 0 0 79.

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

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

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

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

_http._tcp SRV 0 0 80 WWW- server.cs1.company.com.10 0 8000 новий швидкий box.cs1.company.com.

;В адресному рядку можна вказувати як #"785898.files/image001.gif">

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

база данні команда сервер

Якщо перейти в зону прямого перегляду tkh.local, можна побачити ресурсні записи (Рис 1.2):запис говорить нам про те, що в зоні tkh.local з моменту її встановлення сталося тільки 8 змін;запис повідомляє, що сервером імен є ТКН - dns001.tkh.local;запис, займається маршрутизацією пошти на сервер ТКН - mail001.tkh.local з пріоритетом 10, але так як MX- запис в нашій зоні одна, пріоритет не грає ніякої ролі;-записи Лондоні і SMTP, це символічні імена на А -запису ТКН - dns001.tkh.local і ТКН - mail001.tkh.local відповідно.-записи, повідомляють, що ім'я ТКН - dns001 і ТКН - mail001 мають IP- адреси 192.168.153.129 і 192.168.153.111 відповідно, а також DNS- суфікс: tkh.local