Должен ли я использовать / 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.

Это на самом деле не вопрос 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, чтобы сохранить зоны, на которые у меня есть полномочия, отличные от тех, которые я извлекаю из других источников. Это позволяет мне удалить все вторичные файлы и повторно загружать их, не беспокоясь о необходимости.