У цьому матеріалі будуть розібрані різні версії нотації файлу конфігурації програми named. Ми опишемо також призначення деяких директив файлів конфігурації і розберемо типові приклади для кешуючого, master і slave серверів.

У цьому матеріалі будуть розібрані різні версії нотації файлу конфігурації програми named. Ми опишемо також призначення деяких директив файлів конфігурації і розберемо типові приклади для кешуючого, master і slave серверів.

Named - це сервер доменних імен пакету BIND. Named може реалізовувати функції серверів будь-якого типу: master, slave, cache (див. Матеріал "Типи серверів доменних імен).

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

Формат файлу конфігурації для 4-ої версії програми відрізняється від того, який застосовується в 8-ій і 9-ій версіях BIND. В силу цілого ряду причин має сенс розглянути обидва формати файлу конфігурації.

Файл конфігурації BIND 4

Всього існує три типи файлів, які використовує named 4-ої версії. До них відносяться:

• файл початкового завантаження буфера (cache)
• конфігурації named (named.boot)
• файли опису "прямих" і "зворотних" зон

В літературі по named прийнято починати з файлу опису бази даних named - named.boot. Ще раз нагадаємо, що свіжіші версії named налаштовуються за допомогою файлу конфігурації, що має інше ім'я і інший формат директив.

Файл named.boot в 4-ій версії використовується програмою named для своєї настройки і первинного завантаження бази даних домену. Це перше, що шукає named при своєму запуску.

Термінологія при роботі з named з BIND 4 відрізняється від тієї, яка прийнята в даний час. Master сервер зони в даному випадку буде називатися primary сервером зони, slave сервер зони буде називатися secondary сервером зони.

У файлі named.boot для опису налаштувань named використовуються наступні команди:

• directory - адреса директорії в файловій системі комп'ютера, на якому запускається named.
• primary - визначає зону, для якої даний сервер є primary server, і ім'я файлу бази даних цієї зони. Файл розміщується в директорії, яка вказана в команді directory.
• secondary - визначає зону, для якої даний сервер є secondary server, а також визначає адреси інших серверів для цієї зони, зазвичай primary server, і ім'я файлу де буде вестися копія бази даних цієї зони. Файл розміщується в директорії, зазначеної в команді directory.
• cache - визначає ім'я кеш-файлу. Зазвичай в кеш-файлі описані адреси та імена кореневих серверів, які даний сервер буде використовувати для отримання адрес віддалених серверів доменних імен.
• forwarders - дана команда визначає адреси серверів доменних імен куди слід відправляти рекурсивні запити. Природно, що на цих серверах для хоста, на якому встановлений named, повинна бути дозволена обробка рекурсивних запитів з цього хоста.
• slave - змушує сервер відправляти всі запити на сервери, які визначені командою forwarders.

Перш, ніж розглядати приклади файлів named.boot для різних типів серверів, хотілося б звернути увагу читача на дві останні команди.

Фактично, саме вони і визначають яка з процедур дозволу запиту (рекурсивна або нерекурсівние будуть застосовуватися на вашому сервері в кожному конкретному випадку). Якщо у файлі named.boot є команда slave, то визначена рекурсивна процедура дозволу запиту, тому що в цьому випадку named буде відсилати всі запити на сервери зазначені в команді forwarders і від них отримувати адреси або імена віддалених хостів. В цьому випадку сервери з forwarders будуть опитувати кореневі сервери і віддалені сервери доменів. Якщо ці сервери також містять команду slave, то пошук адреси або імені здійснюватимуть сервери, які визначені в їх файлах named.boot як forwarders.

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

Наведемо тепер приклад файлу named.boot, в якому проілюструємо використання зазначених вище команд:

; An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru vega
primary 43.226.194.in-addr.arpa vega.rev
secondary polyn.kiae.su 144.206.130.137 144.206.192.34 polyn
secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 polyn.rev
cache. named.root

Приклад 1. Зміст файлу named.boot.

Зазвичай, файл named.boot розміщується в директорії / etc. Від цієї директорії потім йде відлік місця компонентів бази даних named. У нашому випадку цю базу даних можна представити у вигляді графа (рис.1), у якого в якості кореня виступає директорія / etc. В / etc існує піддиректорія namedb, в якій розташовуються всі інші файли.

Рис.1. Структура розміщення файлів бази даних named з прикладу 1.

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

Команда directory визначає директорію namedb як директорію розміщення файлів бази даних named (файлів опису зон). Взагалі кажучи, зовсім не так вже обов'язково розміщувати всі файли в одній директорії. Можна створити кілька директорій, наприклад, за кількістю зон. Наприклад, для кожної зони можна використовувати окрему піддиректорію в кореневій директорії named. Якщо дотримуватися цієї логіки розміщення файлів, то

; An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru v / vega
primary 43.226.194.in-addr.arpa v / vega.rev
secondary polyn.kiae.su 144.206.130.137 144.206.192.34 p / polyn
secondary 160.206.144.in-addr.arpa 144.206.130.137 144.206.192.34 p / polyn.rev
cache. named.root

Приклад 2. Зміст файлу named.boot при розміщенні файлів опису зон для primary і secondary серворов за різними тек.

У прикладі 2 в директорії namedb визначені дві піддиректорії v і p. В директорії v розміщуються файли зон vega.ru і 43.226.194.in-addr.arpa, для яких даний сервер є primary. У свою чергу в директорії p розміщуються файли опису зон polyn.kiae.su і 160.206.144.in-addr.arpa, для яких даний сервер є secondary сервером. Якщо уявити структуру файлів у вигляді графа, то вийде граф з малюнка 2.

Рис.2. Дерево файлів опису бази даних named з прикладу 2.

Взагалі кажучи, коренем опису файлів бази даних named може бути директорія відмінна від / etc. якщо програму named запустити з прапором "-f", то в якості параметра можна вказати повний шлях до файлу named.boot або до іншого файлу, який використовується замість named.boot:

/ Usr / paul> named -f /usr/paul/named.par

У цьому випадку в якості кореневої директорії для файлів опису бази даних named буде використовуватися директорія / usr / paul, а в якості файлу named.boot файл named.par з цієї директорії.

Крім того, в команді directory, як це визначено в наших прикладах, використовується, так званий, неповний шлях до директорії, де розташовані файли бази даних named. Однак можна вказувати і повний шлях, що дає можливість розташувати ці файли де завгодно в файлової системі сервера. Наприклад, якщо файли розташовані в директорії / usr / local / etc / namedb, то у файлі named.boot слід вказати наступну команду directory:

directory / usr / local / etc / namedb

Команда primary використовується для вказівки зони, яку даний сервер обслуговує як master сервера, і вказівки імені файлу, де вона (зона) описана. Формат команди primary можна описати таким чином:

primary <ім'я зони> <ім'я файлу опису зони>

У прикладах 2 і 3 використовується три команди primary. Перша описує "зворотній" зону 0.0.127.in-addr.arpa, друга команда описує "пряму" зону vega.ru і третя команда описує "зворотній" зону 43.226.194.in-addr.arpa. Наявність двох "зворотних" зон викликано тим, що пряма зона визначена на двох мережах - 194.226.43.0 і 127.0.0.0.

Мережа 127.0.0.0 - це особлива мережу, тому перша команда повинна бути на будь-якому сервері доменних імен, тому що вона служить для визначення зворотної зони 0.0.127.in-addr.arpa, яка закріплена за будь-якою машиною, на якій встановлений стек протоколів TCP / IP.

Особливе призначення цього домену випливає з особливого значення IP-адрес, які закріплені за ним. Вони позначають "петлю", тобто при відправці пакетів за адресою, наприклад, 127.0.0.1 пакети не виходять за межі одного комп'ютера і таким чином не потрапляють в реальну мережу. У деяких реалізаціях стека певне значення мають і інші адреси мережі 127, наприклад, 127.0.0.2 і 127.0.0.3 в HP-UX.

Дуже часто в прикладах опису файлу named.boot можна зустріти повторення імені зони в назві файлу:

primary 0.0.127.in-addr.arpa 0.0.127.in-addr.arpa

Це повторення означає тільки те, що в директорії файлів опису бази даних named повинен бути файл з таким ім'ям. Для тих, хто звик до того, що в файлової системі MS-DOS були дозволені тільки трьохбуквені розширення імені файлу, подібне ім'я виглядає досить дивно, але у ентузіастів Unix і користувачів сучасних версій Windows це не повинно викликати труднощів. Використання імен зон в якості імен файлів - це загальноприйнята практика. Так набагато простіше орієнтуватися серед файлів опису бази даних named.

Часто замість 0.0.127.in-addr.arpa вказують 127.in-addr.arpa. Мережа 127 - це мережа класу А (Для тих, хто звик до нотаціям CIDR рекомендуємо прочитати RFC-790 і 791). Для цієї мережі що 127, що 127.0, що 127.0.0 - суть одне і теж. Так як при вказівці зворотного зони числа в IP-адреси вказуються в зворотній послідовності, то 0.0.127.in-addr.arpa і 127.in-addr.arpa також означають одне і теж. Взагалі кажучи, обробка цієї зворотної зони згідно RFC-1035 проводиться особливим способом.

Серед фахівців з named немає єдності думок про стилі визначення прямих і зворотних зон, в тому числі, і про зони 0.0.127.in-addr.arpa. Дехто пропонував ввести "пряму" зону, яка б відповідала "зворотної" зоні 0.0.127.in-addr.arpa. Пов'язано це з доменним ім'ям, яке ставиться у відповідність адресою 127.0.0.1.

Команда secondary використовується для опису зон, де даний сервер виконує функції slave сервера, і має такий вигляд:

secondary <ім'я зони> <список IP-адрес серверів зони> <ім'я файлу опису зони>

У наших прикладах описано дві зони, для яких даний сервер є secondary сервером - polyn.kiae.su і 160.206.144.in-addr.arpa. У прикладах для кожної з цих зон вказано за два IP-адреси серверів, що підтримують зону.

Взагалі кажучи, досить вказувати адресу тільки primary сервера зони. З точки зору актуальності стану бази даних зони, для якої створюється secondary сервер, вказівка ​​одного тільки primary найбільш правильне рішення, тому що тільки primary сервер містить найбільш актуальну базу даних зони. Однак в ряді випадків, має сенс вказати кілька серверів, primary і secondary, наприклад. У разі зазначення кількох серверів, база копіюється з того, що зазначений першим, якщо він доступний. Якщо сервер не доступний, то опитується наступний у списку, до першого доступного сервера.

Файл, який вказаний останнім аргументом в команді secondary, створюється named при запуску і постійно оновлюється відповідно до опису взаємодії master і slave серверів. Редагувати вручну цей файл не має сенсу, тому що це калька з master сервера, і через постійні проміжки часу цей файл оновлюється програмою named. Таким чином, якщо хто-небудь і внесе до нього зміни, то named, створюючи нову копію бази даних зони, затре ці зміни.

На відміну від master сервера slave сервер не здатний підтримувати дозвіл запитів як завгодно довго. Як тільки закінчиться час актуальності даних в його базі даних, він намагається створити нову копію бази з бази даних master сервера. Якщо це не вдається, то сервер через деякий час перестане обслуговувати зону (див. Опис записи опису ресурсів SOA).

Головне призначення slave сервера - це підвищення надійності служби доменних імен. Опис зони named копіює з серверів, зазначених в якості аргументу команди secondary. Там вказані не тільки primary master сервер, але і інші сервери, які щодо primary master є slave серверами.

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

Команда cache служить для визначення файлу з початковими даними для запуску named. Для того, щоб почати відповідати на запити named повинна знати адреси інших серверів доменних імен, до яких можна було б звернутися із запитами на дозвіл IP-адреси по імені або імені по IP-адресою. Формат команди виглядає наступним чином:

cache <ім'я зони> <ім'я файлу cache>

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

Згідно Крег Ричмонду (Craig Richmond) різні версії named по різному використовують файл, вказаний в команді named. Одні програми завантаживши дані з цього файлу більше його не використовують, інші навпаки постійно вносять до нього зміни.

У разі стабільного файлу адміністратор системи повинен сам піклується про його актуальності. Для цього він повинен регулярно перевіряти відповідність між його файлом і файлом, який підтримується в ns.internic.net. Отримати копію файлу можна або, з ftp-сервера ftp.rs.internic.net, або по команді:

/ Usr / paul> dig @ ns.internic.net.ns> root.cache

Том Ягер (Tom Yager) рекомендує інше джерело отримання cache - ftp://nic.ddn.mil/netinfo/root-servers.txt.

Насправді cache - це опис кореневої зони доменних імен, яку, власне, і обслуговують root сервери. А куди ще накажете звертатися при запуску named?

Якщо в файл cache необхідно внести іншу інформацію, то це робиться аналогічно опису кореневих серверів. У нових версіях named (8-9ая) немає кеш-файлу, але є опис кореневої зони. З цієї причини не варто вносити в нього зміни, які не зробили на primary master кореневої зони.

Команда forwarders визначає IP-адреси серверів, на які слід відправляти рекурсивні запити. Команда має наступний вигляд:

forwarders <список IP-адрес серверів>

Випадок організації рекурсивної процедури дозволу імені з використанням цієї команди був розглянутий раніше. Однак цим випадком не обмежується коло використання команди forwarders. При реєстрації домену деякий час зовнішній щодо цього домену світ не підозрює про існування домену. Повинен пройти якийсь час, перш ніж буде закінчена процедура реєстрації домена і оновлення баз даних вищого в ієрархії DNS домену на всіх серверах як master, так і slave. Однак всередині домену все працює нормально, тому що локальний сервер запускається до офіційної реєстрації і здатний обслуговувати машини домену. Однак, він може і не знати інформації про всіх доменах Internet. Для цього потрібно самому запитувати root-сервери. Але ж можна скористатися і чужим кешем. З цієї причини завжди корисно вказати команду forwarders на сервер домену вищого щодо даного домену. Як правило, на ньому дозволено обслуговувати рекурсивні запити хостів з піддоменів.

Зазвичай вказують не один, а кілька IP-адрес серверів, які в змозі відповісти на запити клієнтів. Наприклад, для сервера зони vega.ru, який запущений, але ще не зареєстрований, можна вказати два сервера:

forwarders 144.206.136.1 144.206.130.137

Команда slave вказується тоді, коли сервер спілкується із зовнішнім світом через сервери, зазначені в команді forwarders. Параметрів у даній команди немає. Файл named.boot для того сервера, якщо він ще й primary сервер для зон vega.ru і 43.226.194.in-addr.arpa буде виглядати наступним чином:

; An Example of the named.boot
;
directory namedb
primary 0.0.127.in-addr.arpa localhost
primary vega.ru vega
primary 43.226.194.in-addr.arpa vega.rev
cache. named.root
forwarders 144.206.130.137 144.206.136.1
slave

Приклад 3. Підлеглий сервер, що працює по рекурсивної процедури дозволу запитів від resolver.

Фактично, команда slave дозволяє організувати, в деякому сенсі, "інтелектуальний" resolver.

Налаштування BIND версій 8 і 9.

Named з пакета BIND 8-ий або 9-ої версій в своєму налагодженні і управлінні має ряд відмінностей від версії 4. По-перше, файл конфігурації носить назву named.conf і розташовується за замовчуванням або в / etc (версія 9), або в / etc / namedb (версія 8). По-друге, у named відсутня зберігається на диску cache, опис кореневої зони винесено в окремий файл, і його потрібно прописувати в налаштуваннях named. По-третє, стало можливим дистанційно керувати named.

При запуску програма named читає файл named.conf і таким чином налаштовується. Раніше були розібрані формат, структура і зміст файлу налаштування програми named версій 4.х. З огляду на той факт, що "четвірка" - це вже історія, зосередимося тепер на файлі настройки більш свіжих версій named.

Основні Зміни, Які відбуліся з named, стосують Підвищення стійкості сервера до різного роду атакам, что и відбілося в налаштування. Адміністратор сервера получил можлівість Керувати копіюванням зон, обслуговування Запитів на Дозвіл імен ip-адресами (в даного випадка слово "Дозвіл" вжівається в значенні "установка відповідності", а не в СЕНСІ "дозволіті щось робити"). Власне, будь-яка рекомендація переходу на нові версії named аргументується більш високою захищеністю програми.

Зовнішнім найбільш помітним відмінністю файлу настройки версій 8.х і 9.х став інший синтаксис. Він став C-подібним (якби нову версію програми почали робити зараз, а не в 1997 році, то файл настройки отримав би напевно XML-синтаксис J).

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

Перш, ніж приступити до обговорення named.conf слід звернути увагу на місце його розташування в файлової системі. Це важливо, тому що при установці named з портів (ports, тобто установки довічних, відкомпільованих під певну платформу версій named утилітами (скриптами) установки) місце розташування цього файлу може відрізнятися від того, яке вибирається за замовчуванням, при установці з вихідних кодів.

За замовчуванням named.conf (установка з вихідних кодів) розташовується в каталозі / etc / namedb / (версія 8) або / etc (версія 9). Як будь-яка прикладна програма, named дозволяє перевизначити місце положення свого файлу настройки за допомогою прапора b або c в командному рядку при своєму запуску:

> Named -c /etc/named.conf

Якщо Ви працюєте з Unix-системою, то потрібно уважно подивитися файли конфігурації скриптів початкового завантаження і самі скрипти (зазвичай щось типу rc. *, В різних клонах можуть бути розташовані в різних місцях, але коренем шляху до яких (місцях), зазвичай , є каталог / etc), щоб переконатися, що установки умовчання для named НЕ перевизначені.

І останнє зауваження перш, ніж приступити до опису прикладів. У всіх прикладах BIND 8-9 використовуються адреси, так званих, немаршрутізіруемих мереж. З цієї причини будьте уважні при копіюванні окремих фрагментів прикладів, якщо, звичайно, Ви вважаєте таке копіювання корисним J.

Кешируєтся сервер (Cache server)

Як вже зазначалося раніше (див. "Типи серверів доменних імен") це сервер, який не відповідає ні за одну з зон, але використовується для виконання запитів resolver-ів. Він виконує функції локального сервера доменних імен, тобто виконує рекурсивні запити від прикладних програм до системи DNS. При цьому в його кеш накопичується інформація про відповідності між доменними іменами та IP-адресами, що дозволяє істотно підвищити швидкість обробки запитів і розвантажити інші сервери доменних імен.

У відповідності зі своїми функціями кешуючий сервер буде мати всього три файли настройки: файл named.conf, файл з описом серверів які обслуговують кореневу зону і файл опису зворотної зони для зони 0.0.127.in-addr.arpa.

Формат, структуру і зміст двох останніх файлів обговоримо пізніше, а зараз зосередимося на named.conf. Візьмемо варіант з керівництва по адмініструванню BIND версії 9:

// Two corporate subnets we wish to allow queries from.
acl "corpnets" {192.168.4.0/24; 192.168.7.0/24};
options {
directory "/ etc / namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query { "corpnets";};
};
// Root server hints
zone "." {
type hint;
file "root.hint";
};
// Provide a reverse mapping for the loopback address 127.0.0.1
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};

В даному прикладі описана настройка кешуючого для двох підмереж. Вони перераховані в access control list (директива acl) і названі як "corpnet". Тепер в будь-якому місці файлу настройки можна посилатися на цей список просто як на "corpnet", що, власне і зроблено в директиві options.

У директиві "options" спочатку вказано робочий каталог named (опція directory). У ньому розташовуються всі файли, які програма використовує при своїй роботі, в тому числі і файли опису зон. Ця опція аналогічна команді directory з файлу налаштувань bind версій 4.х.

Потім опція pid-file вказує ім'я файлу в які буде поміщений ідентифікатор процесу named. Цей файл буде розташований в робочому каталозі named (тобто / etc / namedb)

Остання опція директиви options - allow-query. Вона визначає список IP-адрес, для яких дозволено звертатися із запитами до сервера. Інші хости обслуговуватися даними сервером доменних імен не будуть. Ще раз звертаємо увагу на те, що будь-які інші хости з будь-якими запитами не обслуговуватимуться, тобто не обслуговуватимуться як рекурсивні, так і нерекурсівние запити.

Директива "zone" дозволяє описати місце розташування і опції для обслуговування зони. Дві зони зазвичай завжди описують. Це зона "." (Коренева зона) і зворотна зона для адреси 127.0.0.1.

Опис зони "." (Кореня дерева доменних імен) необхідно для того, щоб сервер міг звертатися до "кореневих" серверам, із запитами на отримання довідки про те, де шукати "відповідального" за зону, з якої клієнт хоче отримати інформацію (IP-адреса або доменне ім'я) . З цієї причини тип зони визначений як "hint", тобто в буквальному перекладі - "довідковий", "контрольний", "наводка на", "натяк на", "рада" і т.п ..

Сам опис "кореневих" серверів знаходиться в файлі root.hint. Файл поставляється разом з дистрибутивом, але адміністратор повинен стежити за оновленнями цього файлу. Про те, як це робити ми розглянули детально при описі налаштувань BIND 4 (cache файл).

Опис зворотної зони для 127.0.0.1 необхідно для того, щоб можна було локально вирішувати (отримувати відповідність між IP-адресою та іменем) при зверненнях з реверсивними запитами до зони 0.0.127.in-addr.arpa. Про важливість реверсивних запитів буде сказано в розділі присвяченому опису зворотної зони для маршрутизуються мережі (підмережі). Тут ми тільки вкажемо, що описати цю зону потрібно в цілях дотримання однаковості, налагодження і акуратної роботи сервісу DNS.

Для зони 0.0.127.in-addr.arpa наш сервер буде первинним (primary), тому його тип опцією type буде визначено як master. Справді за цю зону відповідає тільки наш сервер. Адреса 127.0.0.1 за межі хоста НЕ маршрутизируется, тому у інших серверів буде своя зона 0.0.127.in-addr.arpa.

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

Опис зворотної зони для 0.0.127.in-addr.arpa знаходиться в файлі "0.0.127.in-addr.arpa". Взагалі кажучи, файл може мати будь-яке ім'я, яке допускається файлової системою. Насправді в документації по BIND 9.x для опису зони використовується ім'я "localhost.rev". Змінити ім'я в прикладі було потрібно для того, щоб відобразити таку поширену практику іменування файлів опису зон іменами самих зон. Ще раз підкреслимо, що ім'я може бути будь-яким допустимим в контексті конкретної файлової системи ім'ям.

Остання опція "notify" дозволяє реалізувати режим оповіщення про зміни інші сервера, які підтримують дану зону, зазвичай, вторинні (резервні, secondary, slave). Для нашої зворотного зони це в принципі не потрібно, тому опція встановлена ​​в значення "no". Якщо ж говорити взагалі, то не всі сервери підтримують цей режим. Загальна практика полягає в тому, що оновлення "розповзаються" по мережі відповідно до параметрів запису SOA з опису зони.

Офіційний (Authoritative) сервер зони

У керівництві по BIND дана конфігурація позначена як "Authoritative-only server". Сенс її полягає в тому, що демонструється настройка сервера, який обслуговує запити від будь-якого хоста Мережі, але тільки до тієї зоні, за яку він офіційно відповідає. У термінології BIND 4.х такий сервер іменувався як "primary" для зони, а в термінології BIND 8.х- 9.х він іменується як "master". Його файл настройки буде виглядати наступним чином:

options {
directory "/ etc / namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query {any; }; // This is default
recursion no; // Do not provide recursion service
};

zone "." {
type hint;
file "root.hint";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};

zone "example.com" {
type master;
file "example.com";
allow-transfer {192.168.4.14; 192.168.5.53; };
};

Спочатку звернемо увагу на відмінність в описі опцій директиви "options". По-перше, із запитами до даного сервера дозволено звертатися будь-якому хосту Мережі, що логічно, тому що ніхто інший крім офіційного сервера в повному обсязі за дану зону не відповідає (опція "allow-query"). Є, звичайно, допоміжні сервера, але вони тільки дублюють master сервер. Вносити зміни в опис зони можна тільки на primary master сервері. Саме тому при виході з ладу primary master сервера час обслуговування запитів допоміжними серверами обмежена. Передбачається, що при відмові primary master дані допоміжних серверів не відповідатимуть вихідного опису зони, а тому обслуговування запитів краще припинити.

По-друге, даний сервер не обслуговує запити рекурсивно. Він тільки відповідає на запити до своєї зоні (опція "recursion"). Останнє означає, що на відміну від кешуючого, який приймає запити від клієнтів (resolver-ів), опитує сервери доменних імен і потім відповідає клієнтам, наш сервер запити клієнтів, які не стосуються зони його відповідальності обслуговувати не буде.

Опис кореневих (root) серверів і зворотного зони для 127.0.0.1 таке ж, як і для кешуючого.

При описі зони відповідальності (директива "zone" example.com ") в якості першого параметра вказано ім'я зони (" example.com ") в фігурних дужках визначені опції: тип сервера - master, тобто офіційний сервер зони; файл опису зони - file "example.com"; список допоміжних серверів - "allow-transfer {192.168.4.14; 192.168.5.53}; ".

Власне, опція "allow-transfer" задає список серверів, яким дозволено копіювати зону. Офіційними допоміжними серверами вони стануть тільки в тому випадку, якщо вони такими були визначені в заявці (для доменів другого рівня - корпоративних доменів, наприклад), або приписані такими у разі делегування зони глибшого рівня.

Якщо не встановити обмеження на копіювання зони, або вказати "any", то будь-який сервер може скопіювати зону, і не тільки сервер. Задля вашої безпеки рекомендується прописувати адреси серверів, яким можна копіювати зону.

Допоміжний сервер (secondary, slave)

У документації по BIND опис master сервера доменних імен і slave сервера збігаються. Але методично правильніше їх рознести, що тут і зроблено.

options {
directory "/ etc / namedb"; // Working directory
pid-file "named.pid"; // Put pid file in working
allow-query {any; }; // This is default
recursion no; // Do not provide recursion service
};

zone "." {
type hint;
file "root.hint";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa";
notify no;
};

zone "eng.example.com" {
type slave;
file "eng.example.com";
masters {192.168.4.12;};
};

Те, що ми маємо справу з допоміжним сервером для зони "eng.example.com" визначено у відповідній директиві "zone". В якості типу сервера (type) вказано значення "slave", що і визначає сервер як допоміжний. В опції "masters" визначається список офіційних серверів, з яких допоміжний сервер може списувати зону в файл "eng.example.com". В даному випадку вказаний тільки один - 192.168.4.12.

Ми розглянули типові настройки файлу конфігурації named.Для того, щоб рухатися далі, потрібно розглянути файли опису зон.

Рекомендована література:

1. Альбітц П., Лі К .. DNS і BIND. - Пер. з англ. - СПб: Символ-Плюс, 2002. - 696 с.
2. BIND 9 Administrator Reference Manual. ( http://www.nominum.com/resources/documentation/Bv9ARM.pdf )
3. J. Postel. ASSIGNED NUMBERS. RFC 790. ( 0790.txt?number=790> http://www.ietf.org/rfc/rfc0790.txt?number=790 )
4. J. Postel .INTERNET PROTOCOL. RFC 791. ( 0791.txt?number=791> http://www.ietf.org/rfc/rfc0791.txt?number=791 )
5. P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. RFC 1035. ( 1035.txt?number=1035> http://www.ietf.org/rfc/rfc1035.txt?number=1035 )

Корисні посилання:

1. http://www.ludd.luth.se/~kavli/BIND-FAQ.html - FAQ спочатку написані Craig Richmond і в даний час підтримуються Ronny H. Kavli. Предназеачени головним чином для BIND версії 4.
2. http://www.die.net/doc/linux/man/man5/named.conf.5.html - сторінки документації по named.conf для любителів Linux.
3. cgi?section=5&topic=named.conf> http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=named.cont - те ж саме, що і пункт 2, але тільки для любителів FreeBSD.