Dovrei usare / etc / bind / zone / o / var / cache / bind /?

Ogni tutorial sembra avere un'opinione diversa su questo. Per le mie zone ISC BIND, devo usare /etc/bind/zones/o /var/cache/bind/? Nell'ultima installazione, ho usato /var/cache/bind/ma solo perché sono stato guidato a farlo; tuttavia ho appena individuato un file pid lì per questa nuova installazione di Debian, quindi ho pensato che usare la "directory di lavoro" per archiviare i file di zona probabilmente non era la migliore idea. Sembra che molti amministratori lo utilizzino in modo da non dover digitare il percorso completo quando dichiarano una nuova zona.

Per esempio:

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

Invece di:

file "db.foobar.com";

È ovviamente più facile da scrivere, ma è una pratica buona o cattiva?

Alcuni potrebbero anche suggerire di impostare la directory di lavoro su /etc/bind/zones:

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

... ma qualcosa mi dice che questa non è una buona pratica, dato che il file pid sarebbe stato creato lì presumo (a meno che non sia solo /var/cache/bindper coincidenza).

Ho dato un'occhiata alla manpage ma non sembrava dire a cosa servisse l'opzione di directory, qualche idea esattamente per cosa fosse stata progettata?

Per le tue zone principali, dovrebbero entrare /etc/bind/zonesperché sono configurate. Le zone secondarie (slave) dovrebbero trovarsi all'interno /var/cache/bind/secondaryo simili, perché sono solo i dati memorizzati nella cache che possono essere recuperati dal master se i dati vengono persi.

Proprio come il womble , sono d'accordo con il fatto che /var/cache/bindè buono per le zone secondarie (slave). D'altra parte, non penso che le zone principali dovrebbero essere sotto /etc. Sono file di configurazione tanto quanto il contenuto offerto da Apache, quindi dovrebbero essere archiviati da qualche parte sotto /var, ma non sotto /var/cache.

Solo per la cronaca, i sistemi basati su Red Hat memorizzano le zone in /var/named(da dove potrebbero essere copiate automaticamente /var/named/chroot/var/named). Il file di configurazione è /etc/named.conf.

/ var / lib / bind / - zone master e dinamiche

/ var / cache / bind / - zone secondarie

/ etc / bind / - zone che non dovrebbero cambiare per la durata del server.

Una risposta breve è che non ha importanza e funzionerà.

Prima usavo /var/cache/bind, ma ora uso sempre /etc/bindcome di /var/cachesolito è escluso dai backup (secondo l' FHS /var/cache deve essere possibile ricreare automaticamente).

Tutte le zone secondarie o dinamiche continuano a vivere /var/cache.

Questa non è davvero una domanda Bind: la risposta dipende da come gestisci i tuoi box Linux / Unix.

Ho lavorato in luoghi con gestione delle modifiche / standard di sicurezza che richiedono un'approvazione specifica per apportare modifiche nella struttura / etc su un server di produzione e utilizzo Tripwire o strumenti simili per monitorare le modifiche. In quei luoghi, i file con un tempo di cambiamento elevato (ad es. File di zona, ecc.) Vivrebbero in / var e sarebbero soggetti a un diverso livello di revisione delle modifiche.

Se il processo di controllo delle modifiche non è un problema, la posizione effettiva non ha molta importanza, ma è necessario mantenerla coerente. Personalmente, penso che appartenga all'albero / var, ma è più un'abitudine unix della vecchia scuola che ho.

Penserei che / var / cache sia qualcosa che potresti eliminare, e quindi userei qualcos'altro.

Ciò che è, non è né uno standard né un requisito per esserlo. A BIND non importa, fintanto che sei coerente al riguardo non andrai alla cieca modifica dei file di configurazione.

Non considererei esattamente i file di zona come dati di configurazione. name.conf e keys.conf sono configurati per me, i dati di zona sono, beh, i dati di zona. Basta scegliere un posto - forse anche una directory utente dedicata allo scopo - ed eseguire con esso.

Nella mia configurazione specifica, uso / local / named, che potrebbe essere un collegamento simbolico altrove sulla macchina. Ho inserito named.conf in / local / named / e ho impostato anche l'opzione directory su / local / named. Dò quindi nomi di file come pri / example.com o sec / example.com per mantenere le zone in cui sono autorevole per quelle distinte da quelle che desidero da altre fonti. Questo mi consente di rimuovere tutti i secondari e di riprenderli senza preoccupazioni, se necessario.