- Загальні відомості
- Вихідні дані
- установка BIND9
- Параметри (синтаксис) named.conf
- розділ Acl
- розділ Options
- розділ Zone
- Розширені можливості пошуку конфігурації
- Налаштування кешуючого DNS сервера
- Головний (master) сервер зони
- Вторинний (secondary, slave) авторитетний сервер зони
Загальні відомості
Named - це демон, що входить до складу пакету bind9 і є сервером доменних імен. Демон named може реалізовувати функції серверів будь-якого типу: master, slave, cache. На наведеній схемі я постарався максимально прозоро відобразити основний принцип роботи DNS сервера BIND. Бінарник, який виконує основну роботу, розташований в / usr / sbin / named. Він бере настройки з основного конфігураційного файлу, який називається named.conf і розташований в каталозі / etc / bind. В основному конфіге описується робочий каталог асервера, найчастіше це каталог / var / cache / bind, в якому лежать файли опису зон та інші службові файли. Відповідність назви зони і файлу опису зони задає розділ zone з параметром file. Розділ zone так само задає тип відповідальності даного сервера за зону (master, slave і ін.), А так само визначає особливі параметри для поточної зони (наприклад, на якому інтерфейсі обробляти запити для поточної зони). У файлах опису зон містяться параметри зон і записи ресурсів (шляху, зазначені в цьому абзаці можуть відрізнятися, це залежить від дистрибутива Linux або параметрів збірки сервера з початкових кодів).
Ця загальна схема роботи, яка допоможе в подальшому не заплутатися, при розгляді конкретних конфігурацій.
Формат файлу конфігурації для 4-ої версії програми відрізняється від того, який застосовується в восьмою і дев'ятою версіях BIND. З огляду на, що я розраховую на установку нового DNS сервера, а стару версію сенсу ставити не бачу, тому буду розглядати конфиг нової версії.
Вихідні дані
Для коректної роботи DNS ньому необхідно мати настроєну мережу. DNS в поточній статті буде налаштований на дистрибутиві FreeBSD, Конфиг мережі стенду наступний:
root @ ns1: / usr / local / etc / namedb # cat /etc/rc.conf ... hostname = "ns1.disnetern.lan" keymap = "ru.koi8-r.win.kbd" ifconfig_em1 = "inet XXX .XXX.XXX.XXX netmask 255.255.255.240 "defaultrouter =" XXX.XXX.XXX.XXX "firewall_enable =" YES "firewall_type =" open "named_enable =" YES "....де XXX.XXX.XXX.XXX - зовнішній інтерфейс (підмережа, виділена провайдером). Настроюється зона матиме ім'я disnetern.lan.
установка BIND9
Для роботи DNS сервера необхідно встановити пакет bind9 (в деяких дистрибутивах - bind). Як зазначено на схемі - основним конфігураційним файлом BIND є файл named.conf (даний файл може бути розміщений в каталозі / usr / local / etc / named /).
Параметри (синтаксис) named.conf
Синтаксис файлу named.conf дотримується наступних правил:
IP-адреси - список IP повинен бути розділений символом ";", може свідчити підмережа в форматі 192.168.1.1/24 або 192.168.1.1/255.255.255.0, (для виключення IP перед ним потрібно поставити знак!), Може свідчити імена "any "," none "," localhost "в подвійних лапках.
Коментарі - рядки починаються на #, // і укладені в / * і * / вважаються коментарями.
У файлах опису зон - символ @ є "змінної" зберігає ім'я зони, зазначеної в файлі конфігурації named.conf або в директиві @ $ ORIGIN поточного опису зони.
Кожна завершена рядок параметрів повинна завершуватися символом; .
розділ Acl
Acl (access control list) - дозволяє задати іменований список мереж. Формат розділу: acl "імя_сеті" {ip; ip; ip; };
розділ Options
Розділ Options задає глобальні параметри конфігураційного файлу, керівники всіма зонами. Даний розділ має формат: options {оператори_раздела_Options}; . Options може бути "вкладений" в розділ Zone, при цьому він перевизначає глобальні параметри. Часто використовувані оператори options:
- allow-query {спісок_ip} - Дозволяє відповіді на запити тільки з спісок_ip. При відсутності - сервер відповідає на всі запити.
- allow-recursion {спісок_ip} - На запити з спісок_ip будуть виконуватися рекурсивні запити. Для інших - ітеративні. Якщо не заданий параметр, то сервер виконує рекурсивні запити для всіх мереж.
- allow-transfer {спісок_ip} - Вказує список серверів, яким дозволено брати зону з сервера (в основному тут вказують slave сервера)
- directory / path / to / work / dir - вказує абсолютний шлях до робочого каталогу сервера. Цей оператор допустимо тільки в розділі options.
- forwarders {ip порт, ip порт ...} - вказує адреси хостів і якщо потрібно порти, куди переадресовувати запити (зазвичай тут вказуються DNS провайдерів ISP).
- forward ONLY або forward FIRST - параметр first вказує, DNS-сервера намагатися вирішувати імена за допомогою DNS-серверів, зазначених в параметрі forwarders, і лише в разі, якщо дозволити ім'я за допомогою даних серверів не вдалося, то буде здійснювати спроби дозволу імені самостійно.
- notify YES | NO - YES - повідомляти slave сервера про зміни в зоні, NO - не повідомляють.
- recursion YES | NO - YES - виконувати рекурсивні запити, якщо просить клієнт, NO - не виконувати (тільки ітеративні запити). Якщо відповідь знайдена в кеші, то повертається з кешу. (Може використовуватися тільки в розділі Options)
розділ Zone
Визначає опис зон (и). Формат розділу: zone {оператори_раздела_zone}; Оператори, які найбільш часто використовуються:
- allow-update {спісок_ip} - вказує системи, яким дозволено динамічно оновлювати дану зону.
- file "имя_файла" - вказує шлях до файлу параметрів зони (повинен бути розташований в каталозі, визначеному в розділі options оператором directory)
- masters {спісок_ip} -зазначає список майстер-серверів. (Припустимо тільки в підлеглих зонах)
- type "тіп_зони" - вказує тип зони, описуваної в поточному розділі, тіп_зони може набувати таких значень:
- forward - вказує зону переадресації, яка переадресовує запити, які прийшли в цю зону.
- hint - вказує допоміжну зону (даний тип містить інформацію про кореневих серверах, до яких сервер буде звертатися в разі неможливості знайти відповідь в кеші)
- master - вказує працювати в якості майстер сервера для поточної зони.
- slave - вказує працювати в якості підлеглого сервера для поточної зони.
Розширені можливості пошуку конфігурації
Значення часу в файлах зон за замовчуванням вказується в секундах, якщо за ними не стоїть одна з наступних букв: S - секунди, M - хвилини, H- годинник, D - дні, W - тижні. Відповідно, запис 2h20m5s матиме значення 2 години 20 хвилин 5 секунд і відповідати 8405 секунд.
Будь-яке ім'я хоста / записи, які не закінчуються точкою вважається неFQDN ім'ям і буде доповнено ім'ям поточної зони. Наприклад, запис domen в файлі зони examle.com буде розгорнуто в FQDN-имя domen.examle.com. .
У конфігураційних файлах BIND можуть застосовуватися такі директиви:
- $ TTL - визначає TTL за замовчуванням для всіх записів в поточній зоні.
- $ ORIGIN - змінює ім'я зони з зазначеного в файлі named.conf. При цьому, область дії даної директиви не поширюється "вище" (тобто якщо файл включений директивою $ INCLUDE, то область дії $ ORIGN не поширюється на батьківський)
- $ INCLUDE - включає вказаний файл як частина файлу зони.
Для того щоб локальний Резолвер сервера теж використовував локальний DNS, необхідно привести файл resolv.conf до наступного вигляду:
dns: ~ # cat /etc/resolv.conf nameserver 127.0.0.1Якщо в імені ресурсної записи зустрічається символ "*", то це він означає що замість нього можна мати на увазі будь-яку дозволену послідовність символів. Такий запис називають "wildcard запис". Однак, символ "*" не може бути використаний будь-де. Це може бути тільки перший символ в поле Name поточного домену, відокремлений від решти символом "."
Налаштування кешуючого DNS сервера
Після установки bind, він повністю готовий працювати як кешуючий DNS сервер без додаткової настройки. Єдиний недолік - він обробляє запити на всіх інтерфейсах, що нам абсолютно не потрібно, тому ми трохи подредактіруем настройки сервера.
Для того, щоб BIND працював в якості кешуючого, необхідно мати конфігураційні файли заповнені необхідною інформацією:
- named.conf;
- опис серверів кореневої зони (зона типу hint);
- опис зони 127.in-addr.arpa.
В даному прикладі наведено кешуючий DNS сервер, що обробляє запити зі списку мереж lan, в яку входить тільки одна локальна мережа 192.168.1.1/24 і петлевий інтерфейс. При необхідності можна включити туди і інші мережі. Після визначення списку мереж в директиві acl, в будь-якому місці конфіга можна буде посилатися на цей список по імені (в нашому прикладі ім'я - lan), що, власне і зроблено в розділі options. Більшість параметрів я прокоментував, але окремої уваги вимагає розділ, що описує зону кореневих серверів. У параметрі file заданий відносний шлях до файлу опису кореневих серверів (шлях, щодо робочого каталогу сервера). За оновленнями даного файлу необхідно стежити, хоча він оновлюється досить рідко (звідки брати оновлений файл я писав в теорії DNS). Як ви помітили, є так само два записи для зони localhost і два записи зворотних зон для броадкаст доменів. Призначення цих зон полягає в тому, щоб уникнути трансляції випадкових запитів імен відповідних IP-адрес на сервери, які обслуговують кореневу зону.
Щоб не вносити плутанину в купі конфігураційних файлів, в статті я наводжу приклади на основі єдиного конфігураційного файлу. Насправді, в останніх версіях Debian (та інших дистрибутивах Linux), файл named.conf виглядає наступним чином:
root @ master: ~ # cat /usr/local/etc/named/named.conf // This is the primary configuration file for the BIND DNS server named. // // Please read /usr/share/doc/bind9/README.Debian.gz for information on the // structure of BIND configuration files in Debian, * BEFORE * you customize // this configuration file. // // If you are just adding zones, please do that in /etc/bind/named.conf.local include "/usr/local/etc/named/named.conf.options"; include "/usr/local/etc/named/named.conf.local"; include "/usr/local/etc/named/named.conf.default-zones";Тобто основний файл не містить змін, а включає в себе більш вузько спеціалізовані файли, які відповідають за свої завдання, наприклад named.conf.options - містить глобальні параметри конфігурації, named.conf.default-zones - містить опис localhost і broadcast зон, а named.conf.local містить опису зон, за які відповідає даний сервер.
Перший рядок задає параметр $ TTL, який визначає час кешування позитивних відповідей (відповідь у вигляді знайденого IP-адреси). Тут і далі, час може здаватися в секундах або за допомогою скорочень: m - хвилини, h - годинник, d - дні, w - тижні.
У записі SOA вказується primary NS для домену та e-mail контактної особи. У дужках, по порядку:
- Serial - Серійний номер. Кожен раз при зміні будь-яких даних його потрібно обов'язково міняти. Коли змінюється серійний номер, зона оновлюється на всіх серверах. Використовуйте наступний формат: ГГГГММДДнн (рік, місяць, день, нн - порядковий номер зміни за день). Якщо ви вже вдруге за день вносите измения в файл зони, вкажіть "нн" рівним 01, якщо третій - 02, і т.д.
- Refresh - інтервал, через який slave сервера повинні звертатися до primary сервера і перевіряти оновлення зони.
- Retry - якщо slave сервера не вдалося звернеться до primary сервера, через цей час він повинен повторити свій запит.
- Expiry - якщо протягом цього часу slave сервер так і не зміг відновити зону з primary сервера, то slave повинен припинити обслуговувати цю зону.
- TTL - час кешування негативних відповідей (відповідь "домен неможливо вирішити в IP адреса")
У секції NS задаються NS сервера, які обслуговують даний домен. Мінімально їх необхідно два, причому вони повинні знаходиться в різних подсетях, а краще - в географічно різних місцях. Першим вказуйте primary сервер.
Секція MX описує поштові шлюзи (зазвичай один), на які буде доставлятися вся пошта цього домену. Для кожного шлюзу встановлюється пріоритет (за замовчуванням - 10). Зазвичай ім'я домену поштового шлюзу виглядає так: mx.example.com.
У секції A вказуються субдомени (A) і синоніми (CNAME). У прикладі домен example.com вказує на IP адресу 192.168.1.1, а домен www.example.com є синонімом example.com.
Зверніть увагу:
- Якщо ви вказуєте повне ім'я домену, пишіть в його кінці точку.
- Записи NS, MX і A для основного домену (НЕ субдомена) не повинні починатися з початку рядка.
- Якщо поштова шлюз належить цьому ж домену, що не забувайте вказувати його в секції A.
Перевірити файл зони на помилки можна за допомогою команди:
$ Named-checkzone example.com ./example.com zone example.com/IN: loaded serial 2007022600 OKДалі, хочу звернути увагу на наявність файлів зон в каталозі, вказаному в розділі options в параметрі directory з іменами, відповідними параметрами file в розділах, що описують зони:
dns: ~ # ls -l / var / cache / bind / разом 24 -rw-r - r-- 1 root root 237 Май 28 1:28 0.in-addr.arpa -rw-r - r-- 1 root root 271 Май 28 1:28 127.in-addr.arpa -rw-r - r-- 1 root root 237 Май 28 1:28 255.in-addr.arpa -rw-r - r-- 1 root root 2994 Май 28 1:28 db.root -rw-r - r-- 1 root root 270 Май 28 1:28 localhost dns: ~ # cat /var/cache/bind/127.in-addr.arpa ; ; BIND reverse data file for local loopback interface; $ TTL 604800 @ IN SOA localhost. root.localhost. (1; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800); Negative Cache TTL; @ IN NS localhost. 1.0.0 IN PTR localhost.Розглядати файли "петльових" і бродкастових зон не бачу сенсу, тому що після установки пакета bind настройки задані за замовчуванням в цих файлах цілком прийнятні. Далі, при організації майстер сервера ми розглянемо приклад опису файлу зони. Хочу звернути увагу, що ми налаштовуємо кешуючий сервер, а визначаємо ми його і як master для деяких з зон. У нашому випадку "кешуючий" говорить про те, що наш сервер не підтримує жодну з реально існуючих зон, тобто йому не делеговане прав на таке обслуговування.
На цьому настройка кешуючого DNS завершена. Всі запити, які потрапляють в кеш DNS сервера він зберігає в оперативній пам'яті комп'ютера і при перезапуску демона ці дані обнуляються. Для перевірки роботи кеша можна виконати команду nslookup mail.ru example.com. , Якщо у відповіді міститься рядок Non-authoritative answer, то адреса прийшов з кешу, а так само якщо виконати dig www.ru. (Або інший домен, якого ще немає в кеші) і через деякий час повторити команду, то час відповіді повинно бути набагато менше.
Головний (master) сервер зони
Основний конфиг містить наступні настройки:
dns: ~ # cat /etc/bind/named.conf acl "lan" {192.168.1.1/24; 127.0.0.1; }; options {directory "/ var / cache / bind"; allow-query {any; }; // відповідати на зпроси з усіх інтерфейсів recursion no; // заборонити рекурсивні запити auth-nxdomain no; // для сумісності RFC1035 listen-on-v6 {none; }; // IPv6 нам не потрібен version "unknown"; // не відображати версію DNS сервера при відповідях / * * Розкоментуйте рядки нижче, якщо * хочете дозволити рекрусівние запити * з локальної мережі. * (Так само, необхідно закомментировать * recursion no;) * / # forwarders {// вказуємо DNS сервера для пересилання # 83.239.0.202; // надані провайдером # 213.132.67.110; // бо до них ближче ніж до кореневих #}; # Allow-recursion {lan; }; // рекурсивні запити теж тільки з локальної}; // опис налаштувань кореневих серверів zone "." {Type hint; file "db.root"; }; // описані надалі зони визначають сервер авторитетним для петльових // інтерфейсів, а так само для броадкаст-зон (згідно RFC 1912) zone "localhost" {type master; file "localhost"; }; zone "127.in-addr.arpa" {type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" {type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" {type master; file "255.in-addr.arpa"; }; // опис основної зони zone "example.com" {type master; file "example.com"; allow-transfer {10.0.0.191; }; }; // опис зворотних зон zone "0.0.10.in-addr.arpa" {type master; file "0.0.10.in-addr.arpa"; allow-transfer {10.0.0.191; }; }; zone "1.168.192.in-addr.arpa" {type master; file "1.168.192.in-addr.arpa"; # Allow-transfer {10.0.0.191; }; // зона описує локальну мережу тому її не передали}; // настройки логування logging {channel "misc" {file "/var/log/bind/misc.log" versions 4 size 4m; print-time yes; print-severity yes; print-category yes; }; channel "query" {file "/var/log/bind/query.log" versions 4 size 4m; print-time yes; print-severity no; print-category no; }; category default { "misc"; }; category queries { "query"; }; };Давайте коротко розберемо конфігураційний файл і настройки master сервера: ми налаштовуємо майстер сервер для зони example.com. . Згідно конфіга, наш BIND має робочий каталог / var / cache / bind, сервер відповідає на запити з усіх інтерфейсів (allow-query {any;};), рекурсивні запити обробляє як ітеративні (recursion no), є майстер-сервером для зони example .com і локальних службових зон (type master). При цьому, якщо необхідно дозволити кешування (тобто рекурсивні запити) для локальної мережі, то необхідно розкоментувати параметри forwarders і allow-recursion і закомментировать recursion no ;.
Так само, для прикладу, я прівів возможности BIND Залогуватися все, что відбувається при работе сервера (можна для цієї мети використовуват syslog). У розділі logging задаються 2 параметра channel (можна и более двох - на ваш розсуд), ЦІ Параметри дослівно можна назваті "канал" записи. КОЖЕН канал візначає имя каналу та налаштування параметрів запису (что запісуваті, а що - ні и куди писати). Директива category задає якові категорію Повідомлень в Який канал відправляті. Віходячі з цього, ми маємо: записи стандартної информации в канал misc, а приходять Предложения надсілаються в канал query. При цьом, если файли журналу досягають 4Мб (size 4m), ВІН перейменовується Додавання до імені .1 и почінається записів у новий журнал, числа в кінці других журналів збільшуються. Журнали з номером, більш зазначеним в version (в нашому випадка 4) відаляються (Керувати ротацією логів можна так само с помощью logrotate). Параметри print * визначаються заносіті в журнал годину з'явився, важлівість и категорію информации. Більш докладно про налаштування розділу logging можна почитати в man (5) named.conf.
Окремо хочеться описати параметр allow-transfer {10.0.0.191; }; . Даний параметр описує сервери, яким дозволено завантажувати копію зони - т.зв. slave серверів. У наступному прикладі ми розберемо настройку slave DNS.
Для коректної роботи логування необхідно створити відповідний каталог і привласнити необхідні права:
dns: ~ # mkdir / var / log / bind / dns: ~ # chmod 744 / var / log / bind / dns: ~ # ps aux | grep named bind 4298 0.0 3.4 46792 13272? Ssl Jul05 0:00 / usr / sbin / named -u bind root 4815 0.0 0.1 3304 772 pts / 4 S + 18:19 0:00 grep named dns: ~ # chown bind / var / log / bind / dns: ~ # ls -ld / var / log / bind / drwxr - r-- 2 bind root 4096 Лип 6 18:18 / var / log / bind /Давайте далі розглянемо наш файл опису зони example.com. :
dns: ~ # cat /var/cache/bind/example.com $ TTL 3D @ IN SOA ns.example.com. root.example.com. (2011070601; serial 8H; refresh 2H; retry 2W; expire 1D); minimum @ IN NS ns.example.com. @ IN NS ns2.example.com. @ IN A 10.0.0.152 @ IN MX 5 mx.example.com. ns IN A 10.0.0.152 ns2 IN A 10.0.0.191 mx IN A 10.0.0.152 www IN CNAME @а так само в домені in-addr.arpa.
dns: ~ # cat /var/cache/bind/0.0.10.in-addr.arpa $ TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; Serial 3600; Refresh 900; Retry 3600000; Expire 3600); Minimum IN NS ns.examle.com. IN NS ns2.example.com. 152 IN PTR examle.com. 191 IN PTR ns.example.com. * IN PTR examle.com. dns: ~ # cat /var/cache/bind/1.168.192.in-addr.arpa $ TTL 3600 @ IN SOA ns.examle.com. root.example.com. (2007042001; Serial 3600; Refresh 900; Retry 3600000; Expire 3600); Minimum IN NS ns.examle.com. IN NS ns2.example.com. * IN PTR examle.com.Наша мережа невелика, передбачається, що в мережі зовсім мало машин. Всі сервіси мережі розміщені на одному хості example.com., Тому і master DNS (ns.example.com.) І поштовий сервер (mx.example.com.) Вказує на одну машину (10.0.0.152).
Вторинний (secondary, slave) авторитетний сервер зони
Основна функція slave сервера - автоматична синхронізація опису зони з master сервером. Дане завдання регламентується документом RFC 1 034 в розділі 4.3.5. Згідно з цим документом обмін даними між серверами рекомендовано проводити по протоколу TCP, за допомогою запиту AXFR. За цим запитом за одне TCP з'єднання повинна передаватися вся зона цілком (RFC 1035).
Так само, slave DNS-сервер ділить навантаження з master сервером або приймає на себе все навантаження в разі аварії па першому сервері.
Перш ніж приступити до налаштування slave DNS сервера, необхідно перевірити можливість отримання зони вручну із вторинного сервера за допомогою наступної команди:
root @ debian: ~ # dig @ 10.0.0.152 example.com. axfr; << >> DiG 9.7.3 << >> @ 10.0.0.152 example.com. axfr; (1 server found) ;; global options: + cmd example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 example.com. 259200 IN NS ns.example.com. example.com. 259200 IN NS ns2.example.com. example.com. 259200 IN A 10.0.0.152 example.com. 259200 IN MX 5 mx.example.com. mx.example.com. 259200 IN A 10.0.0.152 ns.example.com. 259200 IN A 10.0.0.152 ns2.example.com. 259200 IN A 10.0.0.191 www.example.com. 259200 IN CNAME example.com. example.com. 259200 IN SOA ns.example.com. root.example.com. 2011070801 28800 7200 1209600 86400 ;; Query time: 14 msec ;; SERVER: 10.0.0.152 # 53 (10.0.0.152) ;; WHEN: Fri Jul 8 15:33:54 2011 ;; XFR size: 11 records (messages 1, bytes 258)Отримання зони пройшло успішно. Далі, для настройки підлеглого сервера, алгоритм наступний:
- Скопіювати конфігураційний файл named.conf з master сервера;
- Замінити параметр type master на type slave в тих зонах, для яких він буде вторинним;
- Параметр allow-transfer {10.0.0.191; }; замінити на masters {10.0.0.152;}; в тих зонах, для яких він буде вторинним;
- Видалити зони, що не буде обслуговувати поточний сервер, в тому числі і кореневу, якщо slave не відповідатиме на рекурсивні запити;
- Створити каталоги для логів, як в попередньому прикладі.
Разом, ми отримуємо конфіг slave сервера:
root @ debian: ~ # cat /etc/bind/named.conf options {directory "/ var / cache / bind"; allow-query {any; }; // відповідати на запити з усіх інтерфейсів recursion no; // заборонити рекурсивні запити auth-nxdomain no; // для сумісності RFC1035 listen-on-v6 {none; }; // IPv6 нам не потрібен version "unknown"; // не відображати версію DNS сервера при відповідях}; // описані надалі зони визначають сервер авторитетним для петльових // інтерфейсів, а так само для броадкаст-зон (згідно RFC 1912) zone "localhost" {type master; file "localhost"; }; zone "127.in-addr.arpa" {type master; file "127.in-addr.arpa"; }; zone "0.in-addr.arpa" {type master; file "0.in-addr.arpa"; }; zone "255.in-addr.arpa" {type master; file "255.in-addr.arpa"; }; // опис основної зони zone "example.com" {type slave; file "example.com"; masters {10.0.0.152; }; }; // опис зворотного зони zone "0.0.10.in-addr.arpa" {type slave; file "0.0.10.in-addr.arpa"; masters {10.0.0.152; }; }; // настройки логування logging {channel "misc" {file "/var/log/bind/misc.log" versions 4 size 4m; print-time YES; print-severity YES; print-category YES; }; channel "query" {file "/var/log/bind/query.log" versions 4 size 4m; print-time YES; print-severity NO; print-category NO; }; category default { "misc"; }; category queries { "query"; }; };після перезапуску наш slave сервер благополучно скопіює необхідну йому інформацію з головного сервера, про що буде говорити наявність файлів в каталозі:
root @ debian: ~ # ls -la / var / cache / bind / разом 28 drwxrwxr-x 2 root bind 4096 Лип 8 18:47. drwxr-xr-x 10 root root 4096 Лип 8 15:17 .. -rw-r - r-- 1 bind bind 416 Лип 8 18:32 0.0.10.in-addr.arpa ...... - rw-r - r-- 1 bind bind 455 Лип 8 18:32 example.com ........В принципі, / stroallow-transfer {pngp slave сервер може не зберігати копію зони у себе в файлової системі. Ця копія потрібна тільки в момент старту DNS. Наявність копії зони в файлової системі може позбавити від збою при недоступності master сервера під час запуску slave DNS. Якщо не вказати опцію file в розділі zone, то копія не створюється.
резюме
У поточній статті описана настройка основних конфігурацій DNS сервера BIND. Метою статті було - дати уявлення про роботу сервера BIND в UNIX. Практично не торкнулися питання безпеки ДНС і мало порушені такі специфічні настройки, як робота сервера в прикордонний режим, коли в різні мережі віддається різна інформація про зону (нах). Для більш глибокого освоєння нижче є список додаткових джерел, в яких вдасться отримати потрібну інформацію.
Що читати:
Система доменних імен: http://citforum.ru/internet/dns/khramtsov/
RFC 1034 - Domain Names - Concepts and Facilities: http://tools.ietf.org/html/rfc1034
RFC 1035 - Domain Names - Implementation and Specification: http://tools.ietf.org/html/rfc1035
RFC +1537 - Common DNS Data File Configuration Errors: http://tools.ietf.org/html/rfc1537
RFC тисяча п'ятсот дев'яносто одна - Domain Name System Structure and Delegation: http://tools.ietf.org/html/rfc1591
RFC 1713 - Tools for DNS Debugging: http://tools.ietf.org/html/rfc1713
RFC 2606 - Reserved Top Level DNS Names: http://tools.ietf.org/html/rfc2606
Безпека DNS (DNSSEC): http://book.itep.ru/4/4/dnssec.htm
BIND 9 Administrator Reference Manual: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
Secure BIND Template: http://www.cymru.com/Documents/secure-bind-template.html
Добре розписані параметри конфіга російською: http://www.bog.pp.ru/work/bind.html
Автоматичне створення файлу зони: http://www.zonefile.org/?lang=en#zonefile
за матеріалом сайту
Org/?