Огляд доменної служби імен dns

Як працює DNS

Системи іменування мережевих об'єктів діляться на "плоскі" і ієрархічні (доменні).

Недоліки такої схеми почали проявлятися досить швидко: з переходом від великих машин до персональних і з ростом Internet. Трафік, пов'язаний з оновленням інформації при додаванні комп'ютерів в Internet, погрожував забити всі лінії зв'язку. Крім того, кожне ім'я в мережі має бути унікальним, а зробити це стає все важче і важче. Тому до середини 80-х років з'явилася інша, більш гнучка система іменування - система імен доменів (Domain Name System, DNS).







DNS реалізує ієрархічне простір імен. Одиницею вимірювання є домен (територія, область). Поняття домену DNS не треба плутати з доменом Windows NT або доменом NIS. Вони не мають один до одного ніякого відношення.

У DNS вся мережа представляється у вигляді єдиного ієрархічного дерева. На вершині розташовується кореневої домен (позначається символом "."). Нижче знаходяться домени першого рівня. Оскільки Internet розвивався в першу чергу в США і за рахунок американських платників податків, це викликало певний крен при формуванні доменів першого рівня: Internet як би виявився поділеним між США і рештою світу.

Найбільш відомі домени першого рівня: com - комерційні організації (головним чином в США); edu - навчальні заклади США; gov - урядові установи США; mil - військові установи США; net - різні мережеві агентства і Internet-провайдери; int - міжнародні організації; org - некомерційні установи; код країни - двобуквений код для позначення держави (ru - для Росії, ua - для України та т.п.). Нижче доменів першого рівня розташовуються домени другого рівня і так далі аж до хостів. Для доменів першого рівня, що позначають держави, доменами другого рівня часто бувають міста або області (наприклад, kiev - для Києва або dp -Дніпропетровськ область), а доменами третього рівня - підприємства та організації.

Допустимими символами є букви англійської мови, цифри і знак дефіса "-" (знак дефіса не може стояти на початку або кінці мітки). Регістр букв значення не має, т. Е. Company1.krcrme.dp.ua. і COMPANY1.KRCRME.DP.UA. позначають один і той же домен.

У повному доменному імені кінцеву точку можна не ставити, оскільки зазвичай програмне забезпечення TCP / IP має на увазі, що складене доменне ім'я (тобто коли присутні більше двох міток) позначає FQDN. Таким чином, company1.krcrme.dp.ua. і company1.krcrme.dp.ua суть одне і те ж.

Домени знаходяться в ієрархічному підпорядкуванні один одному, причому домени є вузлами дерева доменів, а хости - листям. Поняття домену досить ємне і в той же час гнучке. Воно не обмежується якимись фізичними кордонами, наприклад межами IP-мережі або сегмента Ethernet. Доменом DNS може бути і країна, і підприємство, і відділ банку. Один домен може включати як безліч мереж, так і тільки частина однієї мережі або навіть підмережі.

Однак функції DNS цим не обмежуються. DNS дозволяє отримати наступну інформацію:

Існує і ряд інших, рідше використовуваних параметрів.

Програмне забезпечення, яке спілкується з серверами імен, називають клієнтом DNS (Resolver DNS). Клієнт DNS виконує роль посередника між мережевими додатками і серверами імен. При цьому він, як правило, прихований від користувача програм. Мережеві додатки використовують клієнт DNS найчастіше неявно, через функції стека TCP / IP. Однак додаток nslookup дозволяє отримати будь-яку інформацію з бази DNS. Клієнт DNS входить до складу програмного забезпечення TCP / IP. Але стек TCP / IP, по-мимо DNS, підтримує і "плоску" систему іменування (через файл hosts). Це дозволяє забезпечити працездатність мережевих пристроїв при проблемах з DNS (наприклад при відсутності зв'язку з сервером імен). Клієнт DNS може функціонувати як на окремому комп'ютері, так і на сервері імен.

Сервер імен насправді відповідає не за домен, а за так звану зону управління (Zone of Authority). в яку можуть входити кілька суміжних доменів. Більш того, сервер імен здатен керувати кількома, причому не обов'язково суміжними, зонами одночасно.

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

Кешування дозволяє зменшити трафік в мережі, а також знизити навантаження на сервери імен.

Сервери імен бувають декількох типів. Первинний сервер імен (Primary Name Server) зберігає на своїх дисках головні файли (master files). в яких міститься вся інформація про зонах управління даного сервера. Ці файли завантажуються в пам'ять сервера імен при його запуску.

Вторинний сервер імен (Secondary Name Server) використовується як дублікат первинного сервера, що забезпечує відмовостійкість DNS. Він завантажує інформацію з первинного сервера і потім періодично її оновлює, посилаючи первинного серверу запити.

Сервери "тільки для кешування" (Cache-Only Server) записують в кеш інформацію, отриману від інших серверів імен. Найчастіше вони використовуються в великих мережах для розвантаження первинного сервера.

Це, однак, ще не всі типи серверів імен, але залишилися (сервери Forwarder і Slave Forwarder) мають лише незначні відмінності в обробці інформації DNS.

Оновлення вмісту інших серверів імен даної зони відбуватиметься в міру старіння вмісту їх кеш-пам'яті. Ці сервери самі повинні надсилати запит первинного сервера на оновлення інформації щодо зони.

Серверів імен інших зон передається тільки конкретна інформація (а не дані по всій зоні) і тільки за їх запитами.

Сервери імен можуть працювати в двох режимах: нерекурсівние і рекурсивном.

Таким чином, в нерекурсівние режимі клієнт сам здійснює всі запити до серверів імен.

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

Щоб працювати в рекурсивном режимі, сервер і клієнт повинні бути налаштовані відповідним чином. Однак в більшості випадків користувач не має можливості змінювати налаштування режиму роботи клієнта, оскільки вона "зашита" в програмне забезпечення TCP / IP.

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

Сервіси DNS в AIX

Всі сервіси доменного іменування повністю реалізовані в AIX. Підтримуються наступні типи серверів імен:







1. Первинний сервер імен;
2. Вторинний сервер імен;
3. Сервер "тільки для кешування";
4. Сервер Forwarder;
5. Віддалений сервер.

Клієнт DNS в AIX, gethostbyaddr () і gethostbyname (), намагається визначити імена ис-пользуя наступну процедуру:

Якщо файл /etc/resolv.conf не існує, клієнт DNS вважає, що в мережі використовується плоска система іменування. Тоді він використовує для визначення імен файл / etc / hosts.

У зворотному випадку, клієнт DNS вважає локальну мережу доменної мережею і намагається використовувати для визначення імені нижченаведені джерела в показаному нижче порядку:

1. Сервер DNS;
2. Локальний файл / etc / hosts.

Хост AIX конфигурируется для використання сервера імен використовуючи наступні кроки:

Порядок записів серверів імен має значення для визначення порядку виклику серверів: спочатку найперший сервер імен зі списку, далі другий і т. Д.

Зазвичай першим вказують найближчий вторинний сервер імен даного домену, а потім - первинний. Це дозволяє знизити навантаження на первинний сервер.

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

2. Створіть файл /etc/named.boot для визначення імені та типу локального демона named.

3. Створіть файли /etc/named.* для визначення необхідних для демона даних. Формат цих файлів повинен відповідати формату записів стандартних ресурсів (Standard Resource Record Format).

Демон named в AIX також підтримує записи ресурсів для пошти типу MB (mailbox domain name), MR (mail rename domain name), MG (mail group member), MINFO (mailbox or mail list information) і MX (mail exchange).

Додатки користувача AIX / 6000 включає в себе програми host і nslookup. У AIX / 6000 також можна скористатися програмою dig для запитів до серверів імен.

Налаштування клієнтської частини

Як вже було зазначено, програмне забезпечення TCP / IP одночасно підтримує і клієнта DNS, і файл hosts. Вміст файлу /etc/resolv.conf ми розглянули вже вище. Файл hosts відповідає за "плоску" систему іменування. Місцезнаходження цього файлу залежить від операційної системи (AIX - / etc / hosts, DOS і Windows - ETC \ HOSTS, NetWare - SYS: \ ETC \ HOSTS).

Зверніть увагу, що файл hosts може містити імена в доменному форматі.

Налаштування сервера імен

стандарти DNS

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

У загальному випадку порядок запуску серверів імен наступний: спочатку створюються файли бази DNS (безпосередньо або через адміністративні утиліти), а потім запускається сервіс DNS (в AIX - демон named).

Формат записів у файлах бази DNS

У файлах бази DNS серверів імен використовується так званий формат запису стандартних ресурсів (Standard Resource Record Format). Виглядає цей формат наступним чином:

Кожна складова тут є полем записи і відділена від інших пробілами або знаками табуляції.

- ім'я описуваного ресурсу. Воно залежить від поля і може позначати домен, зону управління, ім'я хоста і т. д. Якщо поле пусте, то в якості нього використовується останнім заданий поле (В попередніх записах).

- час життя (в секундах). Визначає, як довго клієнт DNS буде зберігати запис в кеш-пам'яті. Якщо дане поле пусте, то в якості береться значення поля , задається в запису SOA (див. нижче).

опис класу використовуваних протоколів. Для Internet (TCP / IP) значення цього поля - IN. Якщо поле пусте, то в якості нього використовується останній заданий клас.

- поле, що задає тип ресурсу записи. Можливі значення цього поля наведені в розділі "Типи ресурсів".

Наступні символи в записах мають спеціальне значення (нижче перераховані деякі з цих символів).

Окремо стоїть крапка в поле позначає поточний домен.

@ Окремо стоїть символ "@" в поле позначає поточний вихідний домен.

() Дужки використовуються для розміщення поля на декількох рядках (коли поле займає кілька рядків).

* Метасимвол. Замінює будь-який набір символів.

Примітка. Слід знати, що в записах ресурсів доменне ім'я, не закінчується точкою, вважається відносним. При обробці воно додається до поточного домену. Тому, коли задається повне ім'я, його необхідно закінчувати точкою.

типи ресурсів

Тип ресурсу задається в поле записи ресурсу. Типів ресурсів безліч. Повний їх список можна дізнатися у відповідних RFC (див. "Додаткову інформацію"). Нижче наводяться найбільш використовувані типи.

Розглянемо кожен з цих типів.

SOA (початок повноважень)

Запис з ресурсом типу SOA позначає початок зони управління сервера імен. Зона управління діє до наступного запису SOA.

ПРИКЛАД ЗАПИСУ SOA

тут поле є складовим і включає поля , , і т.д.

Позначає ім'я домену зони управління.

Ім'я первинного сервера імен зони.

Номер версії зони. Коли проводяться зміни в зоні, то це число необхідно збільшити. Саме по даному полю орієнтується вторинний сервер імен, визначаючи необхідність оновлення інформації по зоні.

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

Час в секундах для повторного звернення вторинного сервера зони, якщо раніше спроба звернення до первинного сервера була невдалою.

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

Значення TTL в записах ресурсів даної зони за замовчуванням, т. Е. Коли поле пусте.

NS (сервер імен)

Запис з ресурсом типу NS позначає ім'я хоста, що є первинним сервером імен для домену.

ПРИКЛАД ЗАПИСУ NS

позначає домен, а - ім'я сервера імен. У прикладі показується, що сервери srv1.komtek.dp.ua і srv2.komtek.dp.ua є сервери імен домену komtek.dp.ua.

ПРИКЛАД ЗАПИСУ A

[] [] [] A

sri-nic.arpa. A 10.0.0.51

CNAME (канонічне ім'я)

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

ПРИКЛАД ЗАПИСУ CNAME

HINFO (інформація про хості)

Запис з ресурсом типу HINFO служить для зберігання інформації про вузол, зокрема про апаратній платформі і операційній системі комп'ютера.

поле позначає доменне ім'я хоста, - апаратну платформу, - ОС хоста. значення полів і стандартизовані, їх слід брати з RFC 1700.

ПРИКЛАД ЗАПИСУ HINFO

MX (поштовий шлюз)

ПРИКЛАД ЗАПИСУ MX

Якщо адміністратор визначає кілька записів MX, то для вказівки порядку опитування поштових шлюзів використовується число (в прикладі - 10) першим опитується шлюз з меншим числом.

PTR (покажчик)

Ресурси з записом типу PTR служать для відображення цих спеціальних доменних імен в звичайні. поле позначає спеціальне доменне ім'я (в домені IN-ADDR.ARPA), а поле - офіційне доменне ім'я хоста.

ПРИКЛАД ЗАПИСУ PTR ДЛЯ хостів

ПРИКЛАД ЗАПИСІВ PTR І A ДЛЯ шлюз

Специфікація BIND

Як уже зазначалося, стандартом de facto в описі складу файлів DNS і порядку їх завантаження на сервер імен є специфікація BIND. Вона підтримується у всіх Unix-системах, в NetWare (програмні продукти Novell NFS Services, FTP Services, NetWare / IP) і ряді інших систем.

Відповідно до даної специфікації існує файл завантаження бази DNS. В Unix-системах зазвичай це файл /etc/named.boot, в NetWare - SYS: ETC \ NAMED.CFG, який загру-жается при запуску сервісу DNS на сервері імен.

Файл завантаження бази DNS є текстовим і складається з окремих записів. Найбільш часто використовуються такі записи:

1. directory Встановлює каталог зберігання файлів бази DNS, якщо не вказані абсолютні шляхи до файлів. Приклад: directory / etc

2. domain Визначає домен за замовчуванням для даного сервера імен. Приклад: domain komtek.dp.ua

3. primary Показує, що сервер імен є первинним для домену і що база домену зберігається в файлі . Приклад: primary komtek.dp.ua /usr/named.data

Приклад реалізації DNS в локальній мережі

Вже згадана локальна мережа складається з двох IP-мереж класу C: 194.170.12.0 і 194.170.13.0. Припустимо, ці мережі утворюють один домен komtek.dp.ua.

В домені є первинний сервер імен srv1 (194.170.12.2) і вторинний сервер імен srv2 (194.170.13.3), а також ряд хостів: host1, host2, host3.

Хост mail (194.170.13.2) є поштовим шлюзом для всього домену, до того ж у нього є псевдонім host4.

Нижче представлені склад і вміст бази DNS для первинного сервера імен srv1.komtek.dp.ua і для вторинного сервера srv2.komtek.dp.ua.

СКЛАД І ЗМІСТ БАЗИ DNS НА ПЕРВИННОМУ СЕРВЕР SRV1

СКЛАД І ЗМІСТ БАЗИ DNS НА ВТОРИННОМУ СЕРВЕР SRV

Як для первинного, так і для вторинного сервера імен, в разі якщо локальна мережа не має виходу в Internet, слід прибрати рядок cache в файлі /etc/named.boot і видалити файл /etc/named.ca.

Допоміжний домен 0.0.127.in-addr.arpa, а також хост localhost (127.0.0.1) в кожній із зон необхідні для створення локальної "петлі" TCP / IP.

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







Схожі статті