[GTER] RES: BIND DNS View apenas 1 entrada

[Patrick Tracanelli]

Boa noite.

O que vocês querem se chama DNS RPZ, e realmente é difícil viver sem esse tipo de recurso em um ambiente intranet com mais de meia dúzia de domínios em views internas. Numa zona RPZ você simplesmente cria as entradas:

FQDN IN <RR> <valor> 

E já era. Só faz recursão se o FQDN não existir na zona RPZ. Segue especificação:

https://tools.ietf.org/html/draft-vixie-dns-rpz-00

Segue documentação:

http://www.zytrax.com/books/dns/ch7/rpz.html

Mais completo que unbound e mais estruturado, sem falar que local-data no unbound tem limite de número de entradas.

Abcs.

Sent from my iPhone

> On Dec 27, 2016, at 2:13 PM, André Carlim <andre at stubnet.info> wrote:
> 
> Já passei por isso, é fácil resolver, ao invés de você ter as zones no mesmo arquivo onde configura as views, faça diferente, crie dois arquivos, um para zones internas e outro para zones externas, depois é só dar um include dentro da view, no arquivo que tiver as zones que você precisa.
> 
> Atenciosamente,
> André Carlim
> StubNetwork
> 
> 
> On terça-feira, 27 de dezembro de 2016 às 12:14 Luzemário Dantas <luzemario at luzehost.com.br> wrote:
> Prezado,
> 
> Isso não é um probema do BIND. O mecanismo de DNS não foi pensado para 
> funcionar dessa forma. Na verdade, entende-se que uma determinada zona 
> deve estar em pelo menos dois NS para efeito de redundância. O trecho 
> abaixo da RFC 1035 resume bem esse comportamento:
> 
> "From the resolver's point of view, the database that makes up the domain
> space is distributed among various name servers. Different parts of the
> domain space are stored in different name servers, although*a particular data item will be stored redundantly in two or more name 
> servers*. The
> resolver starts with knowledge of at least one name server. When the
> resolver processes a user query it asks a known name server for the
> information; in return, the resolver either receives the desired
> information or a referral to another name server. Using these
> referrals, resolvers learn the identities and contents of other name
> servers. Resolvers are responsible for dealing with the distribution of
> the domain space and dealing with the effects of name server failure by
> consulting redundant databases in other servers."
> 
> 
> Assim, o mecanismo entende que uma vez conectado a um NS, ou ele recebe 
> o dado que precisa, ou recomenda alguém que saiba resolver. Isso faz com 
> que você tenha que ter zonas inteiras, não parte delas.
> 
> Alguns sistemas operacionais implementam mecanismos de round-robin, mas 
> mesmo nessa ótica, se um determinado NS estiver online, sendo acessado 
> diretamente ou por indicação de outro NS, espera-se que ele possua todas 
> as informações para aquele domínio.
> 
> Outros resolvers podem até ter algum mecanismo para implementar o que 
> você deseja, mas será um gambiarra se formos seguir à risca a RFC.
> 
> Luzemário