[GTER] RES: Appliances de DNS recursivo para Rede.

Fri Aug 19 11:10:17 -03 2016

Tbm com boa experiência com Anycast, principalmente quando ocorreu falha em uma das máquinas ao ter o trafego redirecionado para outra sem que os usuários sequer notassem problemas.

Recomendo.

Agradeço o pessoal da RNP que deu a ideia em um dos Fórum do NIC.Br

-----Mensagem original-----
De: gter [mailto:gter-bounces at eng.registro.br] Em nome de Guilherme Domingues
Enviada em: sexta-feira, 19 de agosto de 2016 10:25
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: Re: [GTER] Appliances de DNS recursivo para Rede.

Rafael, usei este template:
https://github.com/Rikbruggink/Zabbix-templates/tree/master/2.0/DNS/Unbound%20Recursor

Jonatas, montei meu ambiente em anycast em Linux.

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-19 5:19 GMT-03:00 Evaldo Gardenal via gter <gter at eng.registro.br>:

> Senhores
>
> Sugiro levar em conta os seguintes fatores para planejar um novo 
> serviço de DNS (Caching Resolver):
> - Latência e perda de pacotes são seus inimigos. Minimize.
>   * Virtualização, dependendo da tecnologia, prioritização e carga do 
> host, pode influenciar negativamente ambos.
>   * Instalações regionais e próximas aos usuários podem propiciar 
> ganho substancial
> - rfc7871 EDNS Client Subnet melhora em muito o controle de trafego 
> para CDNs que utilizam DNS para distribuição de carga. Prefira 
> implementar um serviço que suporte essa extensão.
> - Dimensionamento apropriado do cache para maximizar hit-ratio. Quanto 
> mais eficiente seu cache, mais rápido os usuarios recebem resposta, 
> evitando consulta upstream.
> - DNS é um dos principais fatores no tempo para o primeiro byte, já 
> que avanços significativos ocorreram com HTTP/2 e QUIC.
>   * Isso afeta a percepção de *velocidade* para os seus usuários, uma 
> vez que diferença em largura de banda pode não ser perceptível ao 
> carregar conteudo pequeno.
>
>
> On Thu, Aug 18, 2016 at 5:47 PM Guilherme Domingues < 
> guilherme.domingues.oliveira at gmail.com> wrote:
>
> > 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter