[GTER] Appliances de DNS recursivo para Rede.

Thu Aug 18 14:30:45 -03 2016

Resposta curta: você pode definir a quantidade de memória cache em função
do hit ratio mas não sei se o Unbound disponibiliza esta informação.

Resposta longa:
Tamanho de memória cache é um problema clássico de cache e se aplica não
apenas a DNS. Se o cache for muito pequeno, a informação desejada
provavelmente não estará disponível. Se for muito grande, pode-se demorar
mais tempo para se descobrir que a informação não está disponível além de
gerar maior custo computacional para gerenciar o cache.

Não sei se os colegas concordam mas ao menos três elementos são críticos no
serviço DNS:
- Correção, ou seja, se proteger de ataques de envenenamento de cache mesmo
em caso de domínios que não estejam assinados com DNSSEC.
- Disponibilidade, ou seja, o serviço não cair mesmo quando é alvo de
ataques DDoS.
- Tempo de resposta, ou seja, latência das respostas DNS. Neste quesito, o
gerenciamento inteligente do cache é parte do segredo do servidor DNS.

Capacidade de processamento é importante mas não é crítico. Precisa atender
mais consultas por segundo? Colocar mais servidores resolve o problema de
capacidade mas não resolve os três pontos críticos acima. Por isso que
capacidade de processamento é importante, mas não é crítico. E, obviamente,
colocar mais servidores é apenas uma das opções para aumentar a capacidade
de processamento.

Dito isso, uma abordagem para definir o tamanho do cache é analisar o hit
ratio, ou seja, o percentual de consultas (não necessariamente de clientes)
que são respondidas com a informação do cache sem enviar uma consulta aos
servidores autoritativos. A partir de determinado ponto, aumento da memória
cache trará benefício adicional praticamente nulo ao hit ratio. Por outro
lado, quanto maior o número de usuários e consultas DNS, maior o hit ratio.

Não trabalho em produção com BND, Unbound ou qualquer appliance que use
estes softwares para o serviço DNS, portanto não saberia dizer qual hit
ratio você conseguiria com estas soluções.

Abs,
Ricardo

Disclaimer: trabalho na Nominum.

Em 18 de agosto de 2016 12:20, Guilherme Domingues <
guilherme.domingues.oliveira at gmail.com> escreveu:

> Fernando, não há um número mágico. Mas pode começar com duas vm's com
> 4Gbytes e o teto do Unbound bem configurado com o link passado.
>
> Outra dica no momento de configurar deixe uma margem para rotação correta
> do Unbound, algo de 80% na soma total da VM. Por aqui estou usando template
> do Unbound no zabbix e me ajudou bastante no ajuste fino.
>
>
>
>
> LPI 201
> LPI000161013
> https://cs.lpi.org/caf/Xamman/certification/process_verify
> code verification:  v8bwxqzja7
> Linux ID #425752
> ---
> "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> original."  Albert Einstein
>
> 2016-08-17 18:21 GMT-03:00 Marcelo Gardini do Amaral <mgardini at gmail.com>:
>
> > Jonatas,
> >
> > por curiosidade: você pode dizer quantas consultas por segundo (ou
> > outra unidade de tempo)
> > seu servidor de DNS recursivo recebe em um rede de 10k usuários?
> >
> > []'s
> > Gardini
> >
> >
> >
> > 2016-08-17 14:42 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com>:
> > > Obrigado pelas referências Guilherme.
> > >
> > > Minha dúvida é quando é muito memória  pra um servidor DNS Recursivo.
> > > Imagibei que alguns poucos GB de RAM ja seria o bastante para armazenar
> > > muita informação em cache mesmo para um recursivo de uso médio pra
> alto.
> > >
> > > Fernando
> > >
> > > On 17 Aug 2016 13:00, "Guilherme Domingues" <
> > > guilherme.domingues.oliveira at gmail.com> wrote:
> > >
> > >> Fernando, utilizo mais memória para aumentar o teto de cache de rrsets
> > do
> > >> UNBOUND, aumentado a possibilidade de hits locais para meus usuários.
> > >>
> > >> Danton, segue um guia oficial:
> > >> https://www.unbound.net/documentation/howto_optimise.html. A respeito
> > de
> > >> benchmark, em bancada utilizei uma destas ferramentas:
> > >> https://www.grc.com/dns/benchmark.htm
> > >>
> > >>
> > >>
> > >> LPI 201
> > >> LPI000161013
> > >> https://cs.lpi.org/caf/Xamman/certification/process_verify
> > >> code verification:  v8bwxqzja7
> > >> Linux ID #425752
> > >> ---
> > >> "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> > >> original."  Albert Einstein
> > >>
> > >> 2016-08-17 12:08 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com>:
> > >>
> > >> > Por que bastante memória para um servidor DNS recursivo ?
> > >> >
> > >> > Fernando
> > >> >
> > >> > 2016-08-17 11:43 GMT-03:00 Guilherme Domingues <
> > >> > guilherme.domingues.oliveira at gmail.com>:
> > >> >
> > >> > > Recomendo DNS próprio mesmo virtualizado, pórem com bastante
> > mémoria e
> > >> o
> > >> > > tunning de performace para o kernel e o Unbound.
> > >> > >
> > >> > > LPI 201
> > >> > > LPI000161013
> > >> > > https://cs.lpi.org/caf/Xamman/certification/process_verify
> > >> > > code verification:  v8bwxqzja7
> > >> > > Linux ID #425752
> > >> > > ---
> > >> > > "A mente que se abre a uma nova idéia jamais voltará ao seu
> tamanho
> > >> > > original."  Albert Einstein
> > >> > >
> > >> > > 2016-08-17 11:34 GMT-03:00 Rubens Kuhl <rubensk at gmail.com>:
> > >> > >
> > >> > > > 2016-08-17 9:17 GMT-03:00 Jonatas M. Victor <
> jonatasmv at gmail.com
> > >:
> > >> > > >
> > >> > > > > Srs,
> > >> > > > >
> > >> > > > >    Até hoje sempre montei meus DNS. Mas devido ao crescimento
> e
> > a
> > >> > > > automação
> > >> > > > > estou procurando appliances prontos para atender pedaços de
> rede
> > >> com
> > >> > > até
> > >> > > > > 10k de usuários. Alguém já viu algum equipamento assim?
> > >> > > > >
> > >> > > >
> > >> > > > Se forem 10k usuários de conectividade Internet, continue
> montando
> > >> seus
> > >> > > > DNS...
> > >> > > > ... se for ambiente corporativo, algum DDI possivelmente
> > integrado a
> > >> > IPAM
> > >> > > > pode ser legal. Infoblox, Appliansys etc.
> > >> > > >
> > >> > > >
> > >> > > > Rubens
> > >> > > > --
> > >> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >> > > >
> > >> > > --
> > >> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >> > >
> > >> > --
> > >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >> >
> > >> --
> > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> > --
> > Marcelo Gardini do Amaral
> > www.spin.blog.br
> >
> > --
> > $>cd /pub
> > $>more beer
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>