сервера iton.edu;
сервер iton.edu збереже адресу cepBepaCf.iton.edu.
Якщо наявний файл конфігурування DNS, то шукання імен спочатку відбувається на серверах DNS, а якщо їх там не знайдено, то у файлі hosts. Для збільшення швидкості роботи ліпше звертатися до абонента безпосередньо за ІР-адресою.
Програму, яка виконує функції DNS на ПК клієнта, називають клієнтом DNS. Клієнт також може взаємодіяти з сервером DNS у нерекурсивному або рекурсивному режимах.
Нехай клієнт звертається з запитом до сервера DNS щодо визначення IP-адреси. Якщо сервер відшукає потрібну інформацію у власній зоні або в кешованих даних, переданих іншими серверами, то він надсилає відшукану адресу. Якщо адреси не виявлено, то сервер надсилає адресу сервера DNS, що розміщений ближче до домену, стосовно якого сформовано запит. Клієнт DNS сам зробить запит до цього домену. Такий порядок роботи називають нерекур-сивним. У рекурсивному режимі запит до іншого сервера DNS виконує не клієнт, а сервер DNS, який одержав запит клієнта.
Найчастіше використовують нерекурсивний режим, оскільки в цьому разі менше завантажений сервер DNS, а також можна ліпше простежити за проходженням запитів.
Налаштування DNS зберігаються у файлах/etc/resolv.conf (UNIX), etc\resolv.cfg (DOS), sys:etc\resolv.cfg (Netware), ay WNTTaW95, 98-уреєстрі.
Формат файлу resolv.conf:
domain firm1.kyiv.ua
name_s1 143.150.180.1
name_s2 143.150.180.4
Кількість рядків - не більше трьох. Звичайно першим зазначають вторинний сервер, потім первинний (для розвантаження).
База даних DNS — це набір текстових файлів, які створює та супроводжує адміністратор. Ця база даних складається з записів різних типів (RFC 882, 1035, 1183). Формат запису:
[назва] [час] [клас] тип дані,
де назва - ім'я комп'ютера або домену, для якого визначено цей запис. Якщо група записів має однакові імена, то всі імена, починаючи з другого, можна пропустити. Можна використовувати як повністю, так і неповністю визначені імена. До неповністю визначених імен додають ім'я локального домену;
час — час, протягом якого запис можна тримати у кеші;
клас - тип мережі, де діє служба. За замовчуванням приймають IN (Internet);
тип — тип запису, що характеризує його призначення;
дані - список параметрів, формат яких окремий для кожного типу запису.
Усі записи умовно розділяють на три групи:
зонні записи. Визначають домени, їхні сервери, а також межі дії наступних записів;
головні записи. Ці записи зіставляють імена та адреси, а також перемаршрутизовують
додаткові записи. Містять додаткову інформацію.
У файлі БД, як звичайно, спочатку записують зонні записи, а потім інші. У цьому разі їхній порядок можє бути довільним.
Зонні записи
Запис SOA визначає параметри зони. Зонний запис діє доти, доки у файлі не виявлено запису для іншої зони. Параметри запису найліпше розглянути на такому прикладі:
@ IN SOA ns.cs.colorado.edu admin.cs.colorado.edu
1001 ;Serial
21600 ;Refresh, 6 hours
1800 ;Retry, 30 min
1209600 ;Expire, 2 weeks
432000 ;Minimum 5 days
Символ @ використовують для скороченого позначення поточної зони. Поле ns.cs.colorado.edu визначає ім'я головного сервера імен зони. Поле admin.cs.colorado.edu - це адреса електронної пошти у форматі користувач.ім'я домену. Поле Serial ідентифікує номер версії файлу БД. З кожним оновленням файлу це число повинно збільшуватися. Часто як таке число використовують дату модифікації. Цей номер керує оновленням інформації на допоміжних серверах. Поле Refresh - це інтервал оновлення даних допоміжними серверами. Поле Retry задає період поновного звертання допоміжного сервера до головного, якщо попередня спроба не була успішною. Поле Expire визначає час, протягом якого допоміжні сервери будуть обслуговувати домен у разі недоступності головного сервера. Поле Minimum визначає час чинності записів. Зі збільшенням цього часу зменшується навантаження на систему DNS, однак збільшується час опрацювання змін у конфігурації.
Запис NS. Ці записи визначають головні та допоміжні сервери зони. Як звичайно, вони йдуть після записів SOA. Формат запису:
[Зона] [час] [клас] NS ім'я_госта
Поле Зона є необов'язковим і може бути відчитане з попереднього запису SOA.
Приклад:
cf.iton.edu. IN NS ns1.cf.iton.edu.
cf.iton.edu. IN NS ns2. cf.iton.edu.
cf.iton.edu. IN NS add_s. cf.iton.edu.
У записах зазначають тільки головні та допоміжні (авторитетні) сервери. Водночас тип сервера не специфікований. Записи типу NS фактично не використовують у межах локальної зони. Однак вони визначають сервери імен для зовнішніх користувачів. Зовнішні користувачі можуть бачити тільки сервери імен, специфіковані в NS. Бувають також внутрішні сервери, приховані від зовнішнього світу.
Головні записи
Запис А використовують для перетворення імені (доменної адреси) машини в ІР-адресу.
Наприклад:
Lion IN A 196.168.2.1
Неповне ім'я доповнюють іменем локального домену.
Запис PTR призначено для перетворення IP-адреси в доменне ім'я госта. Щодо цього запис PTR виконує протилежну до запису А функцію.
Значна кількість програм користується сервісом PTR. Як звичайно, вони отримують з мережі деяку IP-адресу і повинні знайти відповідне їй ім'я для порівняння зі списками імен у своїх файлах конфігурації. До таких програм належать netstat, sendmail, syslog, XWindow, ftp, finger, rlogind та ін.
Формат запису:
адреса [час] [клас] PTR ім'я_госта
Форма наведення адреси госта в цьому запису неординарна. Адресу записують справа наліво. У кінці адреси не ставлять крапки. Наприклад, адресу 192.168.2.1 буде записано так: 1.2.168.192
Це роблять з метою використання як для прямого, так і для зворотного перетворень одного програмного модуля. У разі прямого перетворення доменне ім'я починається з найменш значущої частини. Тому і для зворотного перетворення потрібно починати адресу з найменш значущої частини.
Такий підхід зумовлює додаткові ускладнення. Відомо таке: якщо доменне ім'я наведене у скороченому вигляді, то перед звертанням до DNS воно буде доповнене ім'ям локального домену. Адреса у записі PTR з формального погляду також неповна і повинна бути доповнена. Для цього ввели позначення спеціального фіктивного домену NNN.IN-ADDR.ARPA, де ННН - перший байт IP-адреси. Отже, у