[GTER] RES: BIND DNS View apenas 1 entrada

[Luzemário Dantas]

Isso sim é uma solução prática. Pena que ainda está em draft.

Luzemário


Em 01-01-2017 19:28, Patrick Tracanelli escreveu:
> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
Equipe LuzeHOST
LuzeHOST Team