[GTER] Appliances de DNS recursivo para Rede.

[Guilherme Domingues]

Ricardo e Evaldo, concordo com todos pontos citados.

A questão de hit ratio não está ligado a um número mágico de memória. Mas a
demanda de queries que elencam a proporção de hit ratio, e que
consequentemente todos os fatores de capacidade nos servidores/appliances
serão promovidos.

Em bancada não obtive resultados suficientes de hit ratio, enquanto não
"povuei" os 12Gbytes de um servidor em homologação.

Em produção estou com 88% de hit ratio sem sobrescrever o TTL de nenhuma
zona. Mas claro que este fator de hit ratio varia de acordo com o ambiente.



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