¿Debo usar / etc / bind / zones / o / var / cache / bind /?

Cada tutorial parece tener una opinión diferente sobre esto. Para mis zonas ISC BIND, ¿debo usar /etc/bind/zones/o /var/cache/bind/? En la última instalación, lo usé /var/cache/bind/pero solo porque me guiaron para hacerlo; sin embargo, acabo de ver un archivo pid allí para esta nueva instalación de Debian, así que pensé que usar el "directorio de trabajo" para almacenar archivos de zona probablemente no era la mejor idea. Parece que muchos administradores usan esto para no tener que escribir la ruta completa al declarar una nueva zona.

Por ejemplo:

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

En vez de:

file "db.foobar.com";

Obviamente es más fácil de escribir, pero ¿es buena o mala práctica?

Algunos también pueden sugerir configurar el directorio de trabajo para /etc/bind/zones:

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

... pero algo me dice que esto no es una buena práctica, ya que supongo que el archivo pid se crearía allí (a menos que sea /var/cache/bindpor coincidencia).

Eché un vistazo a la página de manual pero no parecía decir para qué era la opción de directorio, ¿alguna idea exactamente para qué fue diseñada?

Para sus zonas maestras, deberían entrar /etc/bind/zonesporque son config. Las zonas secundarias (esclavas) deben estar en /var/cache/bind/secondaryo similares, porque solo los datos en caché se pueden recuperar del maestro si se pierden los datos.

Al igual que womble , estoy de acuerdo con el hecho de que /var/cache/bindes bueno para las zonas secundarias (esclavas). Por otro lado, no creo que las zonas maestras deberían estar debajo /etc. Son archivos de configuración tanto como el contenido servido por Apache, por lo que deben almacenarse en algún lugar debajo /var, pero no debajo /var/cache.

Solo para el registro, los sistemas basados ​​en Red Hat almacenan zonas en /var/named(desde donde podrían copiarse automáticamente /var/named/chroot/var/named). El archivo de configuración es /etc/named.conf.

/ var / lib / bind / - zonas maestras y dinámicas

/ var / cache / bind / - zonas secundarias

/ etc / bind /: zonas que no deberían cambiar durante la vida útil del servidor.

Una respuesta corta es que no importa y que tampoco funcionará.

Solía ​​usar /var/cache/bind, pero ahora siempre uso, /etc/bindya /var/cacheque generalmente está excluido de las copias de seguridad (según el FHS /var/cache debe poder recrearse automáticamente).

Cualquier zona secundaria o dinámica aún vive /var/cache.

Esta no es realmente una pregunta vinculante: la respuesta depende de cómo gestione sus cajas Linux / Unix.

He trabajado en lugares con estándares de gestión / seguridad de cambios que requieren aprobación específica para realizar modificaciones en el árbol / etc en un servidor de producción, y uso Tripwire o herramientas similares para monitorear los cambios. En esos lugares, los archivos con un alto ritmo de cambio (es decir, archivos de zona, etc.) vivirían en / var y estarían sujetos a un nivel diferente de revisión de cambios.

Si su proceso de control de cambios no es un problema, la ubicación real no importa mucho, pero debe mantenerla constante. Personalmente, creo que pertenece al árbol / var, pero ese es más un hábito de Unix de la vieja escuela que tengo.

Creo que / var / cache sería algo que podría eliminar, por lo que usaría algo más.

Lo que eso es, no es un estándar ni un requisito para ser así. A BIND no le importa, siempre y cuando sea coherente al respecto, no se quedará ciego editando archivos de configuración.

No consideraría los archivos de zona como datos de configuración exactamente. named.conf y keys.conf son config para mí, los datos de zona son, bueno, datos de zona. Simplemente elija un lugar, tal vez incluso un directorio de usuarios dedicado para ese propósito, y ejecútelo.

En mi configuración específica, uso / local / named, que puede ser un enlace simbólico en otra parte de la máquina. Puse named.conf en / local / named /, y configuro la opción de directorio a / local / named también. Luego doy nombres de archivo como pri / example.com o sec / example.com para mantener las zonas que tengo autoridad para distinguir de las que obtengo de otras fuentes. Esto me permite eliminar todas las secundarias y volver a buscarlas sin preocupaciones si es necesario.