[GTER] Appliances de DNS recursivo para Rede.

Jonatas M. Victor jonatasmv at gmail.com
Thu Aug 25 09:46:48 -03 2016


 Meu ambiente hoje eu rodo vms c/ FreeBSD rodando unbound e está atendendo
tranquilamente a rede. Só preciso melhorar
são questões de gerência e informativas de ter quantidades de hit ratios e
poder coletar informações de uso.

   Obrigado pelas dicas,

2016-08-19 10:24 GMT-03:00 Guilherme Domingues <
guilherme.domingues.oliveira at gmail.com>:

> 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
>



-- 
.:Abraços:.

<<< Jonatas M. Victor >>>
jonatas at jmv.eti.br
jonatasmv at gmail.com



More information about the gter mailing list