1. параметри
2. Зони в named.conf
3. коренева зона
4. локальні зони
5. Налаштування вторинного сервера імен
6. Налаштування первинного сервера імен
7. Сховище файлів зон для основного та додаткового серверів імен

Вміст файлу named.conf нагадує код на мові С. Якщо вам не знайомий мову С, не хвилюйтеся. Правила дуже прості, а приклади пояснюють все, що вам потрібно знати. Якщо рядок починається з двох символів слеша (//), то це коментар. А будь-який текст між старими добрими знаками коментарів С (/ * і * /) - це багаторядковий коментар. Все інше в named.conf - це або параметри, або зони. Зона - це химерна назва домену (строго кажучи, вони не ідентичні, але для наших цілей можна зробити таке припущення). Параметри керують роботою BIND.

параметри

Якщо не брати до уваги коментарі, файл named.conf, що поставляється за замовчуванням, починається зі списку параметрів. Основна їх частина неясна і за замовчуванням закоментований. Для застосування параметрів їх потрібно розмістити у відповідному розділі, який обмежений словом options і фігурними дужками ({і}). Самі параметри розташовуються між дужками і відокремлюються один від одного крапкою з комою. Ось дуже простий розділ параметрів з файлу named.conf:

options {
directory "/ etc / namedb";
pid-file "/ var / run / named / pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on {127.0.0.1; 192.168.0.5; };
};

У цьому прикладі значеннями більшості параметрів є каталоги або файли, і тільки параметр listen-on містить два IP-адреси.

Спочатку розглянемо параметр directory. Він задає каталог конфігурації, в якому демон named шукає і зберігає файли DNS. Значення за замовчуванням - дуже непоганий вибір, особливо якщо врахувати, що каталог / etc / namedb насправді таким не є. (Дивно звучить? Читайте далі, і незабаром все проясниться.)

Параметр pid-file - це ім'я файлу, в якому зберігається числовий ідентифікатор основного процесу named. Вміст цього файлу використовується різними інструментами адміністрування сервера імен.

Параметр dump-file - це кеш відповідей демона named. Всі відповіді, надіслані named, зберігаються в кеші на диску. Файл кешу часто використовується при пошуку несправностей в DNS.

Якщо від named потрібно, щоб він зберігав статистику та інші відомості про запити, ці дані зберігаються у файлі statistics-file.

Параметр listen-on визначає, на яких IP-адреси named приймає запити. Якщо за однією мережевою картою закріплені десятки IP-адрес, named можна прив'язати тільки до одного адресою. Якщо в системі застосовуються клітини, таке рішення особливо цінно, оскільки запобігає неправильну настройку клієнтів.

BIND підтримує набагато більше параметрів, але ці застосовуються, мабуть, частіше за інших. Повний список параметрів і опис їх застосування можна знайти в документації BIND на сайті http://www.isc.org.

Зони в named.conf

Незмінений named.conf описує три зони, або домену, які сервер імен обслуговує за замовчуванням: кореневу зону (root zone), локальну зону для IPv4 (IPv4 localhost) і локальну зону для IPv6 (IPv6 localhost). Змінювати зони не треба, інакше напевно будуть проблеми. Ми тільки розглянемо їх призначення.

коренева зона

Сервер імен звертається до кореневої зоні, коли у нього немає інформації про запитуваній домені або хост. Такі запити перенаправляються кореневого сервера імен. Ось запис в named.conf для кореневої зони:

Перший елемент (1) говорить, для якого домену призначена ця запис. Точка в лапках означає, що запис відповідає всьому Інтернету.

Поле type (2) визначає тип домена. Коренева зона - особлива: тільки вона має тип hint. Всі інші записи можуть мати тип або master, або slave.

Нарешті, ключове слово file (3) повідомляє демона named, в якому файлі зберігається інформація для цього домену. Демон звертається до каталогу, зазначеного в параметрі directory, знаходить файл з цим ім'ям і призначає його вміст даній зоні. Ці файли будуть розглянуті пізніше.

локальні зони

Пам'ятайте, в чолі 6 говорилося, що кожен комп'ютер використовує «зворотний петлю» (loopback) з IP-адресою 127.0.0.1 для звернення до самого себе? Сервер імен повинен містити записи для цього IP-адреси. Без них кожен системний виклик, запитувач ім'я локального хоста, переходив би в режим очікування, істотно уповільнюючи роботу системи, що дратувало б користувачів.

Нижче наводиться конфігурація для локальної зони IPv4. У файлі named.conf вона розташована відразу після кореневої зони:

Досить схоже на блок options і кореневу зону з попереднього розділу, чи не так?

Ім'я зони (1) представлено в лапках після слова zone. Оскільки ця зона застосовується для зворотного DNS, ми бачимо IN-ADDR.ARPA. Якщо даний IP-адреса записати в зворотному порядку, вийде фактична група IP-адрес 127.0.0.

Поле type (2) вказує, чи є даний сервер первинним або вторинним для цього домену. Кожен сервер імен є первинним для локальних зон.

Нарешті, ключове слово file (3) повідомляє серверу імен, в якому файлі можна знайти інформацію про цей домен. Інформація про цій зоні знаходиться в підкаталозі каталогу конфігурації named в файлі /etc/namedb/master/localhost.rev.

Версія локальної зони для IPv6 мало чим відрізняється від цього блоку. Якщо IPv6 у вас не використовується, як і на більшості інших серверів в Інтернеті, її можна просто закомментировать.

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

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

Запис виглядає дуже знайомою. Тут є ім'я домену (1), тип зони (2) і ім'я файлу (3), в якому зберігається інформація про домен. Крім первинного сервера, у якого можна отримати інформацію про спільно обслуговуваній зоні, не менш важливо знати, за які записи ви дійсно відповідаєте і які з них можна отримати у первинного сервера. Крім того, сервер імен повинен мати право на запис у файли вторинних зон, але не в файли первинних зон. За традицією імена файлів вторинних зон утворюються додаванням розширення .db до імені домена. Всупереч очікуванням ці файли не є двійковими файлами бази даних. named (8) створює їх, коли вторинний сервер завантажує дані про домен з первинного сервера.

Далі слід запис про первинному сервері домену (4) зі списком його IP-адрес (5). Вторинний сервер запитує інформацію про домен з первинного сервера через постійні інтервали часу. Первинний сервер імен повинен бути представлений своїми IP-адресами; в кінці кінців, DNS-сервера повинен мати можливість завантажувати свої записи ще до того, як він дізнається IP-адреса чого-небудь!

Налаштування первинного сервера імен

Конфігурація named.conf, необхідна для первинного сервера, навіть простіше конфігурації для вторинної зони:

Отже, ще раз: є ім'я домену (1), тип зони (2) і ім'я файлу (3). На відміну від файлу опису домену для вторинного сервера імен, даний файл треба створити. Створення цього файлу зони розглядається нижче в цьому розділі.

Сховище файлів зон для основного та додаткового серверів імен

Якщо ви керуєте великими серверами імен Інтернету, то відповідаєте за тисячі доменів і мільйони користувачів. Помилитеся - і на вас обрушиться гнів цих мільйонів. Тому перед налаштуванням сотень зон обміркуйте, як їх розмістити.

Завжди відокремлюйте файли зон, для яких ваш сервер є первинним, від файлів зон, для яких сервер є вторинним. Конфігурація сервера імен за замовчуванням вже включає два таких каталогу, але багато початківці адміністратори DNS звалюють все в каталог конфігурації / etc / namedb і потім гірко жалкують про це. Файли в каталозі первинного сервера священні, і їх резервні копії слід зберігати в безпечному місці, бажано в репозитарії RCS ( глава 4 ). Файли з каталогу вторинного сервера теж не сміття, але вони не вимагають такого ж дбайливого ставлення та обов'язкового резервного копіювання.

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

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