Чи повинен я використовувати / etc / bind / zone / або / var / cache / bind /?

Кожен підручник, схоже, має іншу думку з цього приводу. Для моїх зон ISC BIND я повинен використовувати /etc/bind/zones/або /var/cache/bind/? В останній інсталяції я використовував, /var/cache/bind/але тільки тому, що я керувався цим; однак я щойно помітив там pid-файл для цієї нової установки Debian, тому я зрозумів, що використання «робочої каталоги» для зберігання зонних файлів, мабуть, не найкраща ідея. Здається, що багато адміністраторів використовують це, тому їм не потрібно вводити повний шлях при оголошенні нової зони.

Наприклад:

file "/etc/bind/zones/db.foobar.com";

Замість:

file "db.foobar.com";

Це, очевидно, простіше набрати, але це хороша чи погана практика?

Деякі можуть також запропонувати встановити робочий каталог на /etc/bind/zones:

options {
    // directory "/var/cache/bind";
    directory "/etc/bind/zones";
}

... але щось підказує мені, що це не є хорошою практикою, оскільки файл Pid буде створений там, я припускаю (якщо тільки це не /var/cache/bindвипадково).

Я подивився на сторінках керівництва , але це , схоже, не сказати , що варіант каталогу був для, будь-яких ідей , що саме це було дизайн для?

Для ваших основних зон вони повинні зайти, /etc/bind/zonesоскільки вони налаштовані. Вторинні (підлеглі) зони повинні бути в /var/cache/bind/secondaryподібних або подібних, оскільки це просто кешовані дані, які можна отримати у головного, якщо дані втрачені.

Як і вродливий , я погоджуюся з тим, що /var/cache/bindдобре для вторинних (рабовласницьких) зон. З іншого боку, я не думаю, що майстерні зони не повинні знаходитись під /etc. Вони є файлами конфігурації стільки ж, скільки вміст, який обслуговує Apache, тому їх слід зберігати десь під /var, а не під /var/cache.

Тільки для запису системи на базі Red Hat зберігають зони під /var/named(звідки вони можуть бути скопійовані автоматично /var/named/chroot/var/named). Файл конфігурації є /etc/named.conf.

/ var / lib / bind / - основні та динамічні зони

/ var / cache / bind / - вторинні зони

/ etc / bind / - зони, які не повинні змінюватися протягом життя сервера.

Коротка відповідь - це не має значення і те, і інше буде працювати.

Раніше я використовував /var/cache/bind, але тепер я завжди використовую так, /etc/bindяк /var/cacheце зазвичай виключається із резервного копіювання (за FHS /var/cache потрібно мати можливість відтворити автоматично).

Будь-які вторинні або динамічні зони все ще живуть /var/cache.

Це насправді не обов'язкове запитання - відповідь залежить від того, як ви керуєте своїми полями Linux / Unix.

Я працював у місцях зі стандартами управління змінами / безпекою, які вимагають спеціального схвалення для внесення змін у дерево / etc на виробничому сервері та використовую Tripwire або подібні інструменти для моніторингу змін. У цих місцях файли з високим темпом змін (тобто файли зон тощо) будуть жити в / var і підлягатимуть різному перегляду змін.

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

Я думаю, що / var / cache буде чимось, що ви можете видалити, і тому використовуєте щось інше.

Що це є, це ні стандарт, ні вимога бути таким. BIND не хвилює, до тих пір, поки ви будете послідовні з цим, ви не будете сліпого редагування конфігураційних файлів.

Я б не вважав зонні файли точно даними конфігурації. name.conf та keys.conf конфігуруються для мене, дані про зону - це ну, дані про зону. Просто виберіть місце - можливо, навіть користувальницький каталог, призначений для цієї мети - і запустіть його.

У моїй конкретній настройці я використовую / local / name, що може бути символьним посиланням в іншому місці машини. Я поставив name.conf в / local / named / і встановив параметр каталогу у / local / named. Потім я даю назви файлів, наприклад, pri / example.com або sec / example.com, щоб зберігати зони, які я авторитетний для відмінних від тих, які я отримую з інших джерел. Це дозволяє мені видаляти всі вторинні та повторно забирати, якщо мені потрібно.