Простір імен dns
Простір імен DNS є ієрархічним (рис. 1). Кожний вузол супроводжує символьна позначка. Коренем дерева є вузол із позначкою нульової довжини. Доменне
ім'я будь-якого вузла дерева — це список позначок, починаючи із цього вузла
(зліва направо) і до кореня, розділених символом «крапка». Наприклад, доменне ім'я виділеного на рис. 1 вузла буде «www.kn.toloka.org.». Доменні імена мають бути унікальними.
Доменом (domain) називають піддерево ієрархічного простору імен. Для позначення домену (яке ще називають суфіксом домену) використовують доменне ім'я кореня цього піддерева: так, хост www.kn.toloka.org. належить домену із суфіксом kn.toloka.org., той, у свою чергу, - домену із суфіксом toloka.org. і т. д.
Доменне ім'я, що завершується крапкою, називають повним доменним іменем
(Fully Qualified Domain Name, FQDN). Якщо крапка наприкінці імені відсутня,
вважають, що це ім'я може бути доповнене (до нього може бути доданий суфікс
відповідного домену). Такі імена можуть використовуватись у рамках домену.
Наприклад, ім'я mail можна використати для позначення хоста всередині домену kpi.kharkov.ua., повне доменне ім'я для цього хоста буде mail.kpi.kharkov.ua..
У застосуваннях крапку наприкінці доменних імен хостів звичайно не ставлять (посилаються на www.kpi.kharkov.ua замість www.kpi.kharkov.ua.), ми теж далі цього не робитимемо.
Серед доменів верхнього рівня (суфікс для яких не містить крапок, окрім кінцевої) виділяють усім відомі com, edu, org тощо, а також домени для країн ( ua для України). Є спеціальний домен агра, який використовують для зворотного перетворення ІР-адрес у DNS-імена.
Розподіл відповідальності
Розподіл відповідальності за зони DNS-дерева - найважливіша характеристика
доменної системи імен. Немає жодної організації або компанії, яка б керувала відображенням для всіх позначок дерева. Є спеціальна організація (Network Information Center, NIC) , що керує доменом верхнього рівня і делегує відповідальність іншим організаціям за інші зони. Зоною називають частину DNS-дерева, що адмініструється окремо. Прикладом зони є домен другого рівня (наприклад, toloka.org). Багато організацій розділяють свої зони на менші відповідно до доменів наступного рівня (наприклад, kn.toloka.org, deb.toloka.org тощо), аналогічним чином делегуючи відповідальність за них.
У цьому разі зоною верхнього рівня вважають частину домена, що не включає виділені в ній зони. Після делегування відповідальності за зону для неї необхідно встановити кілька серверів імен (як мінімум два - основний і резервний). Під час розміщення в мережі нового хоста інформація про нього повинна заноситься у базу даних основного сервера відповідної зони. Після цього інформацію автоматично синхронізують між основним і резервним серверами.
Отримання ip адрес
Якщо сервер імен не має необхідної інформації, він її шукає на інших серверах.
Процес отримання такої інформації називають ітеративним запитом (iterative query).
Розглянемо ітеративний запит отримання IP-адреси для імені www.kn.toloka.org. Спочатку локальний сервер зв'язується із кореневим сервером імен (root
name server), відповідальним за домен верхнього рівня ( . ) . Станом на 2004 рік
в Інтернеті було 13 таких серверів, кожен із них мав бути відомий усім іншим серверам імен. Кореневий сервер імен зберігає інформацію про сервери першого рівня.
Отримавши запит на відображення імені, він визначає, що це ім'я належить не до його зони відповідальності, а до домену .org, і повертає локальному серверу інформацію про адреси та імена всіх серверів відповідної зони. Далі локальний сервер звертається до одного із цих серверів з аналогічним запитом. Той сервер містить інформацію про те, що для зони toloka.org є свій сервер імен, у результаті локальний сервер отримує адресу цього сервера. Процес повторюють доти, поки запит не надійде на сервер, відповідальний за домен kn.toloka.org, що може повернути коректну ІР-адресу.
Кешування IP адрес
Кешування IP-адрес дозволяє значно зменшити навантаження на мережу. Коли
сервер імен отримує інформацію про відображення (наприклад, IP-адресу, що
відповідає доменному імені), він зберігає цю інформацію локально (у спеціальному кеші). Наступний аналогічний запит отримає у відповідь дані з кеша без звертання до інших серверів. Інформацію зберігають у кеші обмежений час. Зазначимо, що, коли для сервера не задана зона, за яку він відповідає, кешування є його єдиним завданням. Це поширений сервер кешування (caching-only server).
Тип DNS ресурсів
Елемент інформації у базі даних DNS називають ресурсним записом (Resource
Record, RR ). Кожний такий запис має клас і тип. Для записів про відображення
IP-адрес класом завжди є IN.
Розглянемо деякі типи DNS-ресурсів. Найважливішим із них є А-запис, що
пов'язує повне доменне ім'я з IP-адресою. Саме на основі таких записів сервери
імен повертають інформацію про відображення. У конфігураційному файлі сервера імен bind для домену toloka.org А-запис для www.toloka.org задають так:
www IN A 188.190.96.145
Ще одним типом запису є CNAME-запис, що задає аліас доменного імені. Одній
і тій самий IP-адресі (А-запису) може відповідати кілька таких аліасів. Аліаси
dev.toloka.org і kn.toloka.org задають так:
dev IN CNAME WWW
ftp IN CNAME WWW
Опис програмної реалізації
Отже нам потрібно налаштувати на DNS сервер на операційні системі Debian 6.0. Для цього ми використаємо програмний продукт Bind 9 версії.
Для початку встановим Bind 9 на нашу операційну систему. Для кращого контролю програмним забезпеченням Bind я використовую WebMin. Також для роботи нам будуть потрібні такі компоненти як apache та perl ці модулі ми також встановлюєм.
Отже приступимо до встановлення Bind 9 для цього нам потірбно зайти в будь який емулятор CMD хай це буде UXTERM. Далі приступаєм до встановлення BIND.
В командній стрічці вводим:
apt-get install bind9
після даної команди автоматично встановиться BIND9.
Далі ми приступаєм до налаштування нашого ДНС серверу.
Перейдемо в папку з основними налаштуваннями
cd /etc/bind/
Далі нам потрібно відкрити файл named.conf.local в якому записані налаштування доменних імен локльної мережі. Відкриєм його і відредагуєм
nano named.conf.local
додаємо в кінець наступне:
zone "toloka.org" {
type master;
file "/var/lib/bind/vasya.com";
};
Тепер розберемся що кожна стрічка значить. Перша стрічка є початком налаштування зони Toloka.org. Друга – тип зони. Тип master означає, що сервер який транслює доменне імя є його творцем. Третя стрічка вказує на те де будуть зберігаються детальні налаштування доменної зони. Імя файлу може бути довільним, але для зручнішої роботи рекомендується в назві файлу використовувати назву доменної зони. Як бачите, всі параметри доменної зони записані в скоби, а після кожного параметру стоїть крапка з комою.
Сама по собі зона не працює, потрібно виконати її детальне налаштування і визначити якій IP адресі вона належить. Для цього нас потрібно створити файл налаштувань зони, який ми вказали для неї в файлі named.conf.local. Перйдіть в папку і створіть потрібний файл.
cd /var/lib/bind/
touch vasya.com
Файл створений, відкриєм його для редагування.
nano toloka.org
Відкривається файл для редагування. Вписуєм туда такі налаштування
$TTL 1D
@ IN SOA localhost. admin.localhost. (
2012022901
12H
180
1W
3H
)
@ IN NS localhost.
@ IN A 192.168.1.1
Тепер розберемся що кожна стрічка означає. Перша стрічка $TTL 1D означає час життя доменного імені, в нашому випадку це один день. Друга описує джерело доменного імені це localhost і електронну пошту адміністратора.
Далі відкривається скобка і ми бачим 5 числових записів. Перший запис (Serial) 2012022901 є серійним номером. Зазвичай задається він по такому принципу – перших 8 цифр це дата, а два іних це просто числа. При зміні налаштувань доменної зони потрібно зразу міняти і серійний номер. Якщо зміни відбуваються декілька раз день - потрібно міняти останні дві цифри, якщо ні просто дату. При оновлені мережевого вузла звіряють серійний номер і якщо він більший – то оновлюють всі налаштування даної зони.
Наступне число 12H відповідає за час, через який другорядні DNS сервера будуть намагатись оновити доменну зону. Рекомендується виставляти час від 1200 до секунд (якщо) дані часто міняються. До 12 годин якщо дані міняються рідко.
Далі іде 180 (retry). Число в секундах, яке вказує скільки часу буде очікувати другорядний сервер, якщо не вдалось отримати запис після спроби його оновити його.
Наступне число 1W (expiry) визначають час, після закінчення якого, другорядний DNS сервер перестане відповідати на запити по даній зоні. Це буде продовжуватись до тих пір поки, поки не буде її онволено з master сервером.
І останнє число 3H (minimum) використовується для зберігання значення TTL по замовчуванню, для старих версій Бінду. Після цього значення кругла дужка закривається.
Передостання стрічка вказує, який DNS сервер транслює доменну зону, в даній мережі. А остання – вказує якій адресі відповідає дане доменне імя.
Тепер можна зберегти і закрити файл. Перезапустим Bind, щоб зміни вступили в дію.
/etc/init.d/bind9 restart
Якщо ми не зробили помилок в config файлі, все має запуститись.
Для перевірки роботи Bind запустимо команду
host toloka.org
Контрольний приклад та аналіз результатів
Для перевірки роботоздатності нашого ДНС серверу нам потрібно набрати у консолі host toloka.org після виконання команди ми отримаєм результат який показаний на рис.2
Рис.2 Результат команди host
На рисунку показано що для домену toloka.org призначено IP адресу 192.168.1.1
Це вказує на повну роботоздатність Bind серверу.
Висновок: Під час виконання цієї розрахункової роботи я вивчив основні поняття при роботі з DNS сервером Bind9, навчився виконувати розподіл ip адрес. Дізнався про кешування IP адрес та типи DNS ресурсів.
Список використаної літератури
Конспект лекцій
В.А Шеховцов «Операційні Системи», BHV, 2006р.
http://xpk-cs103.ucoz.ua/os_kng/16.pdf
http://uk.wikipedia.org/