[GTER] Appliances de DNS recursivo para Rede.

Evaldo Gardenal gardenal at google.com
Fri Aug 19 05:19:19 -03 2016


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



More information about the gter mailing list