Cada tutorial parece ter uma opinião diferente sobre isso. Para minhas zonas ISC BIND, devo usar /etc/bind/zones/ ou /var/cache/bind/ ? Na última instalação, usei /var/cache/bind/ , mas apenas porque fui orientado a fazer isso; no entanto, acabei de ver um arquivo pid lá para essa nova instalação do Debian, então imaginei que usar o "diretório de trabalho" para armazenar arquivos de zona provavelmente não era a melhor idéia. Parece que muitos administradores usam isso para que não precisem digitar o caminho completo ao declarar uma nova zona.
Por exemplo:
file "/etc/bind/zones/db.foobar.com";
Em vez de:
file "db.foobar.com";
É obviamente mais fácil digitar, mas é uma prática boa ou ruim?
Alguns também podem sugerir configurar o diretório de trabalho para /etc/bind/zones :
options {
// directory "/var/cache/bind";
directory "/etc/bind/zones";
}
... mas algo me diz que isso não é uma boa prática, já que o arquivo pid seria criado lá, presumo (a menos que seja apenas em /var/cache/bind por coincidência).
Eu dei uma olhada no manpage mas não parecia dizer qual a opção do diretório foi para alguma idéia exatamente o que era design?
Uma resposta curta é que isso não importa e também funcionará.
Eu costumava usar /var/cache/bind , mas agora sempre uso /etc/bind , já que /var/cache é excluído dos backups (por FHS /var/cache deve poder ser recriado automaticamente).
Quaisquer zonas secundárias ou dinâmicas ainda vivem em /var/cache .
Esta não é realmente uma questão de vinculação - a resposta depende de como você gerencia suas caixas Linux / Unix.
Trabalhei em locais com padrões de gerenciamento de mudança / segurança que exigem aprovação específica para fazer modificações na árvore / etc em um servidor de produção e uso o Tripwire ou ferramentas semelhantes para monitorar as alterações. Nesses locais, arquivos com um alto tempo de mudança (ou seja, arquivos de zona, etc.) viveriam em / var e estariam sujeitos a um nível diferente de revisão de alterações.
Se o processo de controle de alterações não for um problema, a localização real não importa muito, mas você deve mantê-lo consistente. Pessoalmente, acho que pertence à árvore / var, mas isso é mais um hábito antigo da unix que eu tenho.
Assim como womble , eu concordo com o fato de que /var/cache/bind é bom para zonas secundárias (escravas). Por outro lado, não acho que as zonas mestras devam estar abaixo de /etc . Eles são arquivos de configuração tanto quanto o conteúdo servido pelo Apache, portanto devem ser armazenados em algum lugar abaixo de /var , mas não abaixo de /var/cache .
Apenas para registro, os sistemas baseados no Red Hat armazenam as regiões em /var/named (de onde elas podem ser copiadas automaticamente para /var/named/chroot/var/named ). O arquivo de configuração é /etc/named.conf .
/ var / lib / bind / - zonas mestre e dinâmica
/ var / cache / bind / - zonas secundárias
/ etc / bind / - zones que não devem mudar durante a vida útil do servidor.
Eu acho que / var / cache seria algo que você poderia excluir e, portanto, usaria outra coisa.
O que é isso, não é um padrão nem um requisito para ser assim. O BIND não se importa, contanto que você seja coerente com isso, você não ficará cego editando arquivos de configuração.
Eu não consideraria os arquivos de zona como dados de configuração exatamente. named.conf e keys.conf são config para mim, dados de zona são, bem, dados de zona. Basta escolher um lugar - talvez até mesmo um diretório de usuários dedicado para o propósito - e executá-lo.
Na minha configuração específica, eu uso / local / named, que pode ser um symlink em outro lugar na máquina. Eu coloquei o named.conf em / local / named /, e configurei a opção de diretório para / local / named também. Em seguida, forneço nomes de arquivos como pri / example.com ou sec / example.com para manter as zonas em que sou autoritativo, distintas daquelas que utilizo de outras fontes. Isso me permite remover todos os secundários e buscar novamente sem preocupação, se necessário.
Tags bind named-conf