[GTER] RES: Servidor DNS

Douglas Fischer fischerdouglas at gmail.com
Wed Dec 19 15:57:21 -02 2018 

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
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

More information about the gter mailing list