нашому прикладі повне доменне ім'я буде виглядати 1.2.168.192.IN-ADDR.ARPA. Як звичайно, інформація про ім'я поточної зони єдина на кожну зону. Тому для заведення записів PTR потрібно вводити додаткову зону NNN.IN-ADDR.ARPA, створювати для неї весь набір записів (SOA, NS, PTR). Ще один набір записів доводиться створювати для зони локального госта 127.IN-ADDR.ARPA.
Між записами А та PTR повинна бути повна однозначна відповідність.
Запис MX призначено для переадресування електронної пошти. Формат запису:
ім'я_адресата [час] [клас] MX пріоритет ім'я_переспрямування
Пріоритет записують цілим числом від 0 до 65535. Повідомлення спрямовують у першу чергу відповідно до записів з меншим пріоритетом.
Приклад використання записів формату MX:
NWC.COM MX 10 NTAS
MX 21 SPARCI
NTAS MX 10 NTAS
MX 20 SPARCI
SPARCI MX 10 SPARCI
MX 20 NTAS
Тут наведено три машини nwc.com, ntas, sparci. Записи з вищим пріоритетом 10 задають поштовий сервер за замовчуванням. Якщо цей сервер недоступний, то пошта надходить на сервер з меншим пріоритетом.
Додаткові записи
Запис CNAME дає змогу визначати для гостів мнемонічні імена, використовувати декілька варіантів імен для одного госта.
Запис HINFO відображає виробника та модель комп'ютера. Запис WKS визначає сервісні програми, які пропонує гост. Запис ТХТ. Довільний текст.
Головне призначення служби імен DNS - це надання IP-адрес на підставі символьного доменного імені госта. Для невеликих мереж це завдання вирішують з використанням текстового файлу hosts або Imhosts на кожній робочій станції.
Фактично DNS має значно більші можливості, ніж просте відображення адрес. DNS -це база даних про стан госта, яка є прообразом служби каталогів мережі, хоч і не містить усіх потрібних у службі каталогів функцій.
Програмна реалізація. Систему DNS називають ще й BIND (Berkeley Internet Name Domain). Ця назва склалася історично та відображає місце створення системи.
Сервер імен. Демон сервера імен називають named. Для виконання перетворення імен звертаються до бібліотечних функцій gethostbyname та gethostbyaddr. Крім програми-демона, сервер імен може мати низку конфігураційних текстових файлів. Це такі файли:
файл початкового завантаження;
кеш-файл;
файл даних зони (для головного сервера);
додаткові файли (файл кореневих серверів).
Найважливішим є файл початкового завантаження. Демон named під час початкового завантаження системи читає його. Формат файлу etc/named.boot:
Directory ім'я_каталогу
cache. ім'я_файлу
primary зона ім'я_файлу
secondary зона IP-адреса ім'я_файлу
forwarders список ІР-адрес
xfrnets список IP-адрес
bogusns список ІР-адрес
Розглянемо окремі директиви цього файлу.
directory визначає каталог, у якому містяться всі файли, зазначені у наступних командах.
cache визначає назву кореневого домену (.) та назву файлу (/etc/named.ca), який містить адреси серверів кореневого домену. Адреси кореневих серверів зазначені явно та використову-ються для отримання інформації тоді, коли база даних та кеш порожні.
primary визначає, що це є головний сервер для зазначеної зони, а також ім'я файлу, у якому містяться дані цієї зони.
secondary визначає, що цей сервер використовують як допоміжний для зазначеної зони, IP-адресу головного сервера, ім'я кеш-файлу, у якому зберігаються дані допоміжного сервера. На відміну від файлу головного сервера, ці дані формуються не вручну, а автоматично демоном named шляхом їхнього узгодження з головним сервером. В одному файлі конфігурування може бути декілька команд primary та secondary, оскільки сервер може бути одночасно пер-винним для однієї зони, а вторинним - для іншої.
forwarders визначає список так званих пересильників. Пересильники - це сервери імен, які кешують запити. Вони можуть бути зовнішніми щодо конкретної мережі. У цьому випадку сервер імен, отримавши запит, переглядає свою базу та кеш. Якщо відповіді не знайдено, то він звертається до пересильників. Отже, пересильники - це сервери імен для серверів імен. Як звичайно, завдяки обслуговуванню багатьох запитів серверів вони мають багато інформації в кеші. Тому їхнє використання розвантажує мережу. Якщо відповіді від пересильника не отримано, то сервер виконує зовнішній запит сам.
xfrnets перераховує у списку адреси мереж та гостів, яким дозволено через зонні пере-силання отримувати інформацію з вашої БД DNS.
bogusns визначає список адрес серверів імен, інформацію з яких треба ігнорувати.
Клієнт (визначник). Головним файлом конфігурування клієнта є /etc/resolv.conf. Він визначає назву доменів, у яких відбуватиметься шукання, а також адреси серверів імен.
У директиві search зазначено перелік назв доменів, якими доповнюють неповністю визначене ім'я перед звертанням до сервера імен.
Спочатку звертаються до першого сервера у списку. Якщо через визначений час тайм-ауту відповіді не отримано, то звертаються до наступного і т. д. Кожен сервер опитують чотири рази. З кожним новим опитуванням значення тайм-ауту збільшується. Отже, процедура опи-тування у разі недосяжності серверів може тривати довго.
Звичайно кожен з серверів, до яких звертається визначник, є рекурсивним, оскільки визначник не опрацьовує відсилань.
Налагодження і тестування. Демон named може бути запущений у декількох режимах налагодження. Рівні налагодження - від 0 до 11. Рівень 0 означає без налагодження, рівні 1 та 2 можна використати для перевірки коректності налаштування, файлів бази даних; рівень 4 і далі використовують системні програмісти для налагодження самого коду демона. Під час роботи демона у режимі налагодження всі службові повідомлення розміщуються у файлах реєстрації системи syslog. Надсилаючи демону системні сигнали, можна змінювати рівень налагодження у процесі його роботи.
Роботу та параметри DNS з консолі оператора можна аналізувати, якщо використовувати утиліти nslookup та dig, можна також переходити між серверами імен, читати записи з їхніх баз даних, зазначаючи їхній тип.
Нові версії DNS
Найпоширенішою на практиці версією DNS є BIND v. 4.9. Консорціум з програмних засобів Internet (Internet Software Consortium) припинив розробку версії 4 та рекомендує пере-ходити до версії BIND 8. Порівняно з попередньою ця версія забезпечує:
динамічне оновлення БД DNS;
повідомлення прозміну змісту БД (Notify, RFC 1996);
підтримку IPv6;
більшу продуктивність
поліпшені засоби безпеки
BIND