Кажется, что каждый учебник имеет свое мнение по этому поводу. Следует ли мне использовать для зон 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 потому что они config. Вторичные (подчиненные) зоны должны быть в /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.
Это не совсем вопрос Bind - ответ зависит от того, как вы управляете своими Linux / Unix-системами.
Я работал со стандартами управления изменениями / безопасности, которые требуют специального разрешения для внесения изменений в дерево / etc на производственном сервере, и использую Tripwire или аналогичные инструменты для отслеживания изменений. В этих местах файлы с высокой скоростью изменения (например, файлы зон и т. Д.) Будут находиться в / var и будут подвергаться другому уровню проверки изменений.
Если процесс управления изменениями не является проблемой, фактическое местоположение не имеет большого значения, но вы должны поддерживать его согласованность. Лично я считаю, что он принадлежит к дереву / var, но у меня это скорее старая школьная привычка.
Я бы подумал, что / var / cache - это то, что вы можете удалить, и поэтому использовал бы что-то еще.
То, что это такое, не является ни стандартом, ни требованием. BIND это не волнует, пока вы последовательны в этом, вы не будете слепо редактировать файлы конфигурации.
Я бы не стал рассматривать файлы зон как данные конфигурации. named.conf и keys.conf для меня являются конфигурацией, данные зоны - это, ну, данные зоны. Просто выберите место - возможно, даже пользовательский каталог, выделенный для этой цели - и запускайте его.
В моей конкретной настройке я использую / local / named, что может быть символической ссылкой в другом месте на машине. Я поместил named.conf в / local / named / и также установил параметр каталога в / local / named. Затем я даю имена файлов, такие как pri / example.com или sec / example.com, чтобы сохранить зоны, в отношении которых я имею право, отличные от тех, которые я извлекаю из других источников. Это позволяет мне удалять все вторичные файлы и повторно получать данные, если мне это нужно.