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