Dois-je utiliser / etc / bind / zones / ou / var / cache / bind /?

Chaque tutoriel semble avoir une opinion différente à ce sujet. Pour mes zones ISC BIND, dois-je utiliser /etc/bind/zones/ou /var/cache/bind/? Dans la dernière installation, j'ai utilisé /var/cache/bind/mais uniquement parce que j'étais guidé pour le faire; cependant, je viens de repérer un fichier pid là-dedans pour cette nouvelle installation Debian, donc je me suis dit que l'utilisation du "répertoire de travail" pour stocker les fichiers de zone n'était probablement pas la meilleure idée. Il semble que de nombreux administrateurs l'utilisent pour ne pas avoir à taper le chemin complet lors de la déclaration d'une nouvelle zone.

Par exemple:

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

Au lieu de:

file "db.foobar.com";

Est évidemment plus facile à taper, mais est-ce une bonne ou une mauvaise pratique?

Certains peuvent également suggérer de définir le répertoire de travail sur /etc/bind/zones:

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

... mais quelque chose me dit que ce n'est pas une bonne pratique, car le fichier pid serait créé là, je suppose (sauf si c'est juste /var/cache/bindpar coïncidence).

J'ai jeté un coup d'œil à la page de manuel, mais elle ne semblait pas dire à quoi servait l'option de répertoire, des idées exactement à quoi elle était destinée?

Pour vos zones principales, elles doivent entrer /etc/bind/zonescar elles sont configurées. Les zones secondaires (esclaves) doivent être dans /var/cache/bind/secondaryou similaires, car ce sont juste des données mises en cache qui peuvent être récupérées du maître si les données sont perdues.

Tout comme le ventre , je suis d'accord avec le fait que /var/cache/bindc'est bon pour les zones secondaires (esclaves). D'un autre côté, je ne pense pas que les zones principales devraient être en dessous /etc. Ce sont des fichiers de configuration tout autant que le contenu servi par Apache, ils doivent donc être stockés quelque part sous /var, mais pas sous /var/cache.

Pour mémoire, les systèmes basés sur Red Hat stockent des zones sous /var/named(d'où ils pourraient être copiés automatiquement /var/named/chroot/var/named). Le fichier de configuration est /etc/named.conf.

/ var / lib / bind / - zones maîtres et dynamiques

/ var / cache / bind / - zones secondaires

/ etc / bind / - zones qui ne devraient pas changer pendant la durée de vie du serveur.

Une réponse courte est que cela n'a pas d'importance et que l'un ou l'autre fonctionnera.

J'avais l'habitude d'utiliser /var/cache/bind, mais maintenant j'utilise toujours /etc/bindcomme il /var/cacheest généralement exclu des sauvegardes (le FHS /var/cache doit pouvoir être recréé automatiquement).

Toutes les zones secondaires ou dynamiques vivent toujours /var/cache.

Ce n'est pas vraiment une question de Bind - la réponse dépend de la façon dont vous gérez vos boîtes Linux / Unix.

J'ai travaillé dans des endroits avec des normes de gestion des changements / sécurité qui nécessitent une approbation spécifique pour apporter des modifications dans l'arborescence / etc sur un serveur de production, et utiliser Tripwire ou des outils similaires pour surveiller les changements. À ces endroits, les fichiers avec un rythme élevé de changement (c'est-à-dire les fichiers de zone, etc.) vivraient dans / var et seraient soumis à un niveau différent de révision des changements.

Si votre processus de contrôle des modifications n'est pas un problème, l'emplacement réel n'a pas beaucoup d'importance, mais vous devez le garder cohérent. Personnellement, je pense qu'il appartient à l'arborescence / var, mais c'est plus une habitude Unix de la vieille école que j'ai.

Je pense que / var / cache serait quelque chose que vous pourriez supprimer, et donc utiliserait autre chose.

Ce qui est, n'est ni une norme ni une exigence de l'être. BIND s'en fiche, tant que vous êtes cohérent à ce sujet, vous n'allez pas modifier en aveugle les fichiers de configuration.

Je ne considérerais pas exactement les fichiers de zone comme des données de configuration. named.conf et keys.conf me sont config, les données de zone sont, eh bien, les données de zone. Choisissez simplement un endroit - peut-être même un répertoire utilisateur dédié à cet effet - et exécutez-le.

Dans ma configuration spécifique, j'utilise / local / named, qui peut être un lien symbolique ailleurs sur la machine. J'ai mis named.conf dans / local / named / et défini également l'option de répertoire sur / local / named. Je donne ensuite des noms de fichiers comme pri / example.com ou sec / example.com pour garder les zones pour lesquelles je fais autorité distinctes de celles que je tire d'autres sources. Cela me permet de supprimer tous les fichiers secondaires et de les récupérer sans souci si j'en ai besoin.