Devo usar / etc / bind / areas / ou / var / cache / bind /?

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 fazê-lo; no entanto, apenas localizei um arquivo pid para esta nova instalação do Debian, então achei 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 não precisar digitar o caminho completo ao declarar uma nova zona.

Por exemplo:

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

Ao invés de:

file "db.foobar.com";

É obviamente mais fácil digitar, mas é uma boa ou má prática?

Alguns também podem sugerir a configuração do 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 /var/cache/bindpor coincidência).

Dei uma olhada na página de manual, mas ela não parecia dizer para que servia a opção de diretório, alguma idéia exatamente para o que era design?

Para suas zonas principais, elas devem entrar /etc/bind/zonesporque são de configuração. As zonas secundárias (escravas) devem estar dentro /var/cache/bind/secondaryou semelhantes, porque são apenas dados armazenados em cache que podem ser recuperados do mestre se os dados forem perdidos.

Assim como as mulheres , 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 principais devam estar abaixo /etc. Eles são arquivos de configuração tanto quanto o conteúdo fornecido pelo Apache, portanto devem ser armazenados em algum lugar abaixo /var, mas não abaixo /var/cache.

Apenas para constar, os sistemas baseados no Red Hat armazenam zonas em /var/named(de onde eles podem ser copiados 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 / - zonas que não devem mudar durante a vida útil do servidor.

Uma resposta curta é que isso não importa e que também funcionará.

Eu costumava usar /var/cache/bind, mas agora sempre uso /etc/bindcomo /var/cachegeralmente é excluído dos backups (de acordo com o FHS /var/cache deve poder ser recriado automaticamente).

Qualquer zona secundária ou dinâmica ainda vive /var/cache.

Esta não é realmente uma pergunta vinculativa - a resposta depende de como você gerencia suas caixas Linux / Unix.

Trabalhei em locais com padrões de gerenciamento / segurança de mudanças 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 alterações. Nesses locais, os arquivos com um ritmo de mudança alto (por exemplo, arquivos de zona, etc.) permaneceriam 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 é um problema, o local real não importa muito, mas você deve mantê-lo consistente. Pessoalmente, acho que pertence à árvore / var, mas esse é mais um hábito unix da velha escola que eu tenho.

Eu acho que / var / cache seria algo que você poderia excluir e usaria outra coisa.

O que é isso, não é um padrão nem um requisito para ser assim. O BIND não se importa, desde que você seja consistente com isso, não ficará cego na edição de arquivos de configuração.

Eu não consideraria os arquivos de zona exatamente como dados de configuração. named.conf e keys.conf são configurações para mim, dados de zona são, bem, dados de zona. Basta escolher um local - talvez até um diretório de usuários dedicado para esse fim - e executar com ele.

Na minha configuração específica, eu uso / local / named, que pode ser um link simbólico em outro lugar da máquina. Coloquei o named.conf em / local / named / e defino a opção de diretório como / local / named também. Em seguida, dou nomes de arquivos como pri / example.com ou sec / example.com para manter as zonas que tenho autoridade para serem distintas daquelas que retiro de outras fontes. Isso permite remover todos os secundários e buscar novamente sem preocupações, caso eu precise.