[GTER] RES: Servidor DNS

Fri Dec 21 11:30:49 -02 2018

Bom dia

Douglas como sempre fazendo observações minuciosas (e puxões de orelha 
haha) creio que não haver o que acrescentar.

Em 19/12/2018 14:57, Douglas Fischer escreveu:
> Perfeita colocação Pacheco!
>
> Vou aproveitar e fazer algumas colocações sobre minha experiência com
> servidores de DNS:
>
> Algumas práticas que considero desrespeitáveis:
> -----------------------------------------------
> a- Um ISP não ter servidor de DNS Recursivo próprio.
>     INCONCEBÍVEL! Se tá assim você tem 3 opções:
>      1) Vai estudar um pouco sobre Docker/Jail e/ou virtualização e instalar
> 2 NS recursivos próprios.
>      2) Contrata alguém que saiba o que está fazendo.
>      3) Vai fazer suas arti com miçanga...
>
> b- UM ISP não ter servidor Autoritativo.
>     Nomes até dá para usar o autoritativo do próprio Registro.BR(muito bom
> por sinal).
>     Mas como é que ficam as consultas de registros reversos de DNS dos IPs
> daquele ASN?
>
> c- Usar a função de Autoritativo e de Recursivo no mesmo server.
>     São duas criticíssimas, cada um do seu jeito, e que podem um atrapalhar
> o outro e gerar impactos terríveis.
>     SEPARE!
>
> d- Usar Servidores de DNS Recursivo e Autoritativo no mesmo Server.
>     Seja no mesmo hardware físico, seja na mesma VM, seja no mesmo
> Docker/Container/Jail/Etc.
>
> e- Colocar dois IPs no mesmo server Autoritativo.
>     Fazem isso só para passar nos testes do RIR/NIR(no caso do Brasil, o
> Registro.BR).
>     Esse merece o prêmio vômito. Vergonhoso.
>     Essa sugestão da HE é MUITO boa... Aprendi com um amigo não tem muito
> tempo.
>     O que eu geralmente recomendo é que largue mão de ser turrão e besta, e
> faça um acordo com um amigo que é dono de ISP.
>     Hospede uma VM de um autoritativo dele na tua infra, e ele hospeda um
> Autoritativo teu na infra dele.
>
> f- Deixar os dois servidores na mesma rede /24.
>     Esse é algo menos grave, mas ainda assim é errado.
>     Se esse /24 morrer, você ficou sem os dois servidores? Parabéns Pedro Bó!
>     P.S.: Esse é um dos motivos pelo qual sou contrário à política de
> alocação de /24.
>
> g- Deixar os dois servidores (primário e secundário), seja para o recursivo
> seja para o autoritativo, na mesma máquina física.
>     Isso é algo meio complicado se você é pequeno. Mas se você tem mais de
> um server físico, é recomendável que cada uma dessas máquina estejam em um
> serve físico.
>     Se você for "maiorzinho" pode até colocar cada um deles em uma
> localidade física distinta.
>     Caso você tenha um cluster de virtualização descente, definir restrições
> de co-residência nessa ferramenta de virtualização dizendo "ns1" nunca pode
> estar junto com "ns2" não é difícil.
>
> h- Usar encaminhador(indiscriminadamente) nos servidores recursivos.
>     Use os benditos dos RootServers! Eles existem para isso!
>     Argumentação desse está no próximo item.
>
> i- Não usar IPs do próprio Bloco de IPs do ASN para as consultas dos NS
> Recursivos.
>     Tem uns "Jênios" que resolvem jogar as consultas de CDN saindo por Links
> ADSL.
>     Outros "inteligência rara" fazem um NAT de saída usando o IP do link da
> Operadora.
>
>     Argumentação H e I:
>     A base da inteligência de Balanceamento das CDNs está no IP de origem
> que os NameServers Recursivos chegam para fazer perguntas para os
> NameServers Autoritativos das CDNs.
>     Juntando esse IP de Origem, uma análise da tabela de roteamento, um
> pouco de GeoIP, e mais alguns temperos personalizados de cada empresa de
> CDN, isso dá no algoritmo de balanceamento de carga dos nodos de CDN.
>     Se usar um IP que esteja usando a mesma política de roteamento que os
> IPs de seus clientes, certamente o cache de resposta que estará alimentando
> seus clientes será adequada com a sua realidade de roteamento.
>     P.S.: Você que faz gambiarra e anuncia 2x /24 prum lado e 2x /24 pro
> outro, ESTÁ FAZENDO CAQUINNHA! É por isso que a metade da tua rede tem
> problema para receber certos conteúdos.
>
> j- Sequestro de NXDomain
>     Algumas operadoras fazem a SAFADEZA de injetar respostas inexistentes
> para perguntas que receberiam timeout...
>     Fazem isso por diversos motivos. Começou com "boa fé" para reduzir
> latência, mas o verdadeiro motivo disso é redirecionar para páginas d
> propaganda...
>     Isso é um ENORME problema! Bagunça os mecanismos de disponibilidade de
> diversos protocolos.
>     Tem um a grande operadora, inclusive em recuperação judicial, que tem
> essa prática. DEPLORÁVEL.
>
> k- Não ter IPv6 nos NS recursivos e NS autoritativos.
>     Quem não tem IPv6, está fadado a ser tirado do mercado! E ter IPv6
> significa ter TODOS os recursos que são necessários a uma rede Internet em
> IPv6.
>     Não custa nada! Não gera problema! E só traz solução!
>     Uma observação importante é fazer tudo o que for necessário para
> entregar/ensinar os NS recursivos de sua rede em IPv6 também.
>
> Algumas práticas que considero recomendáveis:
> ---------------------------------------------
> r- Usar o Master Autoritativo como Hidden(aprendi com o Kühl-bot)
>     Aquele cara que vai ser aonde você vai fazer as alterações manuais, ou
> que vai receber os comandos em bash ou API para sincronizar as informações
> das Zonas diretas e reversas?
>     Não publique ele para o seu RIR/NIR e nem abra ele para consultas
> externas.
>     Geralmente ele precisa de quase nada de performance, e separar ele
> garante uma boa integridade nessas consultas e alterações.
>     Importante lembrar que é só nesse cara que você vai precisar de uma
> interface gráfica para fazer alterações. A replicação vai se encarregar de
> levar essas informações para os Slaves.
>
> s- Use um "RootServer" dentro de seu próprio NS Recursivo.
>     Isso acelera MUITO as respostas, desonera a rede e a performance dos
> RootServers, não é complicado de fazer, e é uma RFC.
>     https://tools.ietf.org/html/rfc7706
>     Para domínios que já estão cacheados, isso não faz tanta diferença assim.
>     Mas para domínios inexistente(Ex.:
> http:\\umnomemaluco.umdominioqueeuinventei\index.htm ), isso faz MUITA
> diferença.
>
>
> P.S.1: Eu ia entrar no escopo de Sequestro de IPs de NSs recursivos
> conhecidos, ou então nat de tudo que é destinado a UDP/53 ou TCP/53...
>         Mas a polêmica seria demasiada. Tem tem boas intenções(visando
> segurança dos usuários), e tem safadeza nessa parada.
>         É por causa de gente safada assim que essa DISGRAMA de DnsOverHTTP
> está nascendo e crescendo.
>         Mas deixa baixo.... Minha intenção é resolver a parada com essa
> galera safada através de alguma RFC em conjunto com políticas nos RIRs.
>
> P.S.2: Percebam que não falei de qual mecanismo de DNS, nem de S.O..
>         Essas regrinhas valem para todos os ambientes.
>
> P.S.3: Também não falei de Hardware, mas uma boa quantidade de memória, e
> SSD para armazenar os caches ajudam bastante.
>
> Em ter, 18 de dez de 2018 às 17:49, Elizandro Pacheco [ NextHop Solutions ]
> <elizandro at pachecotecnologia.net> escreveu:
>
>> Vou mais longe, configure máster e slave e não apenas 2 ips no mesmo dns.
>>
>> Deixe o máster dentro da sua rede e o slave fora. Como citado
>> anteriormente, o da HE é ótimo ( e grátis ) pra isso. Inclusive para
>> reversos.
>>
>> Elizandro Pacheco
>>
>>
>>
>> -----Mensagem original-----
>> De: gter <gter-bounces at eng.registro.br> Em nome de Eduardo Rigler
>> Enviada em: terça-feira, 18 de dezembro de 2018 12:22
>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
>> gter at eng.registro.br>
>> Assunto: Re: [GTER] Servidor DNS
>>
>> Em ter, 18 de dez de 2018 às 12:04, Marcelo Gondim <gondim at bsdinfo.com.br>
>> escreveu:
>>
>>> Boa noite,
>>>
>>> Se tiver DNS autoritativo e recursivo, separe os dois. Não coloque
>>> tudo rodando num mesmo servidor com BIND.
>>> Faça um recursivo para os seus assinantes e somente para eles.
>>> Recomendo o unbound [1] Faça separadamente o DNS autoritativo primário
>>> e feche o secundário com alguém que você conheça. Eu uso aqui o NSD.
>>> Muito bom, só faz o que tem que fazer e nada mais e é da mesma empresa
>>> do unbound, a NLnet Labs [1]
>>>
>>> [1] https://nlnetlabs.nl/
>>
>>
>> +1 Bind para autoritativos e Unbound para recursivos em estruturas
>> separadas.
>>
>> E caso não haja possibilidade de manter um autoritativo em uma rede
>> independente recomendo o da Hurricane Electric [1], o utilizo em alguns
>> domínios e eventualmente demora um pouco mais para atualizar as alterações
>> mas de modo geral funciona super bem e nunca me deixou na mão, além de ser
>> gratuito.
>>
>> [1] https://dns.he.net/
>>
>>
>>
>>
>>>
>>> Em 09/12/2018 20:46, Maycon Vieira escreveu:
>>>> Me envie um contato no e-mail maycon at microwebnet.com.br sobre o dns
>>> anycast
>>>> Em qua, 14 de nov de 2018 17:28, listas <listas at rbsti.com.br escreveu:
>>>>
>>>>> Bom dia, Tenho um solução que desenvolvi para DNS Anycast, onde
>>>>> conseguimos ter um resultado muito bom com DNS, além de balancear a
>>>>> carga, e prover redundância, caso tenha interesse me chame em PVT.
>>>>>
>>>>> Em 09/05/2018 11:38, Fabio Junio Nascimento Santos escreveu:
>>>>>> Bom dia senhores,
>>>>>>
>>>>>> Venho através deste para verificar com os membros da GTER sobre
>>>>>> qual a
>>>>> melhor forma de implementar em uma rede, um servidor DNS.
>>>>>> Se através de algum Router ou mesmo em Distribuição Linux.
>>>>>>
>>>>>> Atenciosamente,
>>>>>>
>>>>>> Fábio Junio Santos
>>>>>> IT Manager
>>>>>> E. S. SOUZA TELECOMUNICAÇÕES
>>>>>>
>>>>>> Enviado do Email para Windows 10
>>>>>>
>>>>>> --
>>>>>> 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
>>
>