Guia de processo · DNS recursivo
Como funciona implantação de DNS recursivo: etapas para provedores
Como funciona implantação de DNS recursivo: o servidor novo é medido, desenhado e instalado em paralelo ao DNS que a base usa hoje, e só depois o endereço entregue aos assinantes muda, um pool por vez. O assinante só percebe a troca na migração, e o servidor antigo fica ligado até o último grupo mudar.
Resumo
- O servidor recebe a pergunta do assinante, procura no cache e, se não achar, percorre raiz, domínio e site até a resposta.
- A medição do pico de consultas vem antes de tudo, porque dela saem o número de servidores e a memória de cache.
- Os testes de acesso, de DNSSEC e de carga são feitos com o servidor ainda sem nenhum cliente apontado para ele.
- A equipe recebe os números de antes e depois, a configuração comentada e o roteiro para atualizar sem parar a base.
O caminho de uma consulta dentro do servidor recursivo
Toda consulta passa por quatro decisões dentro do servidor: quem perguntou, se a resposta já está guardada, onde buscar o que falta e se a resposta é confiável. A implantação configura cada uma dessas decisões.
Quando o assinante digita um endereço, o roteador da casa pergunta ao DNS que recebeu na conexão. O servidor recursivo não sabe a resposta de antemão: ele a monta perguntando a outros servidores e guarda o resultado pelo tempo que o dono do domínio autorizou, o TTL.
Origem
Quem está perguntando?
O servidor confere se o endereço de origem é do provedor, incluindo a faixa do CGNAT e o IPv6. Se não for, recusa.
Cache
A resposta já está guardada?
Se outro assinante pediu o mesmo nome há pouco e o TTL não venceu, a resposta sai da memória na hora.
Recursão
Raiz, domínio e site
Sem cache, o servidor pergunta à raiz quem cuida do .br, depois ao servidor do domínio e por fim ao do site.
Validação
A resposta é verdadeira?
Se o domínio é assinado com DNSSEC, o servidor confere a assinatura e descarta a resposta falsificada.
Resposta
Entrega e guarda
O endereço volta ao assinante e fica no cache, pronto para quem perguntar o mesmo nome em seguida.
Num DNS bem dimensionado, a maior parte das consultas para na segunda etapa. A taxa de acerto do cache é um dos números medidos antes e depois da implantação.
A Táquion Tech configura essas quatro decisões num software livre, como o Unbound, e prova cada uma com teste antes de qualquer cliente mudar, no serviço de implantação de DNS recursivo.
Pré-busca e resposta vencida
Dois ajustes fazem o assinante quase nunca esperar a recursão completa. A pré-busca renova os nomes mais pedidos pouco antes de o TTL vencer, e a resposta vencida entrega o último endereço conhecido quando o servidor do site não responde.
A segunda opção é descrita na RFC 8767 [CONFIRMAR na norma] e evita que uma falha num servidor de domínio de fora vire chamado no seu suporte.
Como funciona implantação de DNS recursivo, etapa por etapa
São cinco etapas, e as três primeiras acontecem sem nenhum assinante apontado para o servidor novo. Cada uma tem um sinal claro de que algo saiu do esperado.
A implantação de DNS recursivo exige medir antes de configurar, porque o tamanho do servidor sai do pico de consultas, e não do número de assinantes. Os prazos em dias vão na proposta: [PREENCHER prazo típico por etapa].
1. Medição do DNS que a base usa hoje
O Especialista lê de onde cada pool recebe o endereço de DNS e mede as consultas por segundo no horário de pico. Se a base usa DNS de fora, a medição sai do tráfego na porta 53 do concentrador ou da borda.
- Peso no calendário: curto, mas precisa pegar pelo menos um pico de uso, à noite.
- Sinal de problema: a soma dos pools não fecha com o total de assinantes; algum concentrador ficou de fora.
2. Desenho: servidores, faixas e regras
Com o pico medido, define-se quantos servidores, onde cada um fica, quanta memória de cache e quais faixas podem consultar. Entram também o limite de consultas por origem e a estrutura de lista de bloqueio.
- Peso no calendário: curto, termina com o desenho aprovado pelo provedor.
- Sinal de problema: a lista de faixas não traz o CGNAT ou o bloco IPv6, que são os esquecimentos mais comuns.
3. Instalação em paralelo e testes sem cliente
Os servidores sobem com endereços próprios, ao lado do DNS atual, e passam por teste de acesso, de validação e de carga. Ninguém da base usa o servidor novo nessa fase.
- Peso no calendário: médio, cresce com o número de servidores.
- Sinal de problema: o teste feito de uma rede externa recebe resposta, sinal de que o controle de acesso está aberto.
4. Migração por grupos de assinantes
O endereço novo vai primeiro para um pool pequeno, pelo PPPoE, pelo DHCP ou pelo anúncio IPv6. Com os números estáveis por alguns dias, os outros pools seguem, e o DNS antigo continua respondendo.
- Peso no calendário: a etapa mais longa, porque o assinante só pega o endereço novo ao reconectar.
- Sinal de problema: chamados de sites que não abrem concentrados num pool só, logo depois da troca.
5. Conferência e entrega
O tempo de resposta e a taxa de acerto do cache são comparados com a medição da primeira etapa. O DNS antigo só é desligado quando ele para de receber consultas.
- Peso no calendário: curto, depois que o último pool migrou.
- Sinal de problema: o servidor antigo ainda recebe consultas, de equipamentos com DNS fixo ou de pools esquecidos.
Erros que só aparecem depois da troca e como confirmar
Alguns problemas passam pelos testes e só surgem com assinante de verdade. A tabela liga o sintoma à etapa em que ele nasceu.
| Sintoma | Onde nasceu | Como confirmar |
|---|---|---|
| Parte da base sem abrir site, link normal | Desenho, faixa do CGNAT fora da lista | Consulta feita de um endereço 100.64.x.x volta recusada |
| Celulares e notebooks lentos para começar a carregar | Migração, IPv6 sem o DNS novo | O anúncio IPv6 ainda entrega o endereço antigo |
| Um domínio específico não abre | Instalação, validação DNSSEC | O nome responde com a validação desligada e falha com ela ligada |
| Servidor lento só no pico | Desenho, cache pequeno | Taxa de acerto cai e o uso de memória chega ao limite |
| Aviso de abuso depois da entrega | Instalação, acesso aberto | Consulta feita de fora da rede recebe resposta |
Que dados e acessos o provedor entrega no começo?
O provedor entrega a lista de blocos e pools, acesso aos servidores e leitura nos concentradores. Com isso, a medição começa no primeiro dia.
| O que separar | Para que a implantação usa |
|---|---|
| Blocos IPv4 e IPv6 e a faixa do CGNAT | Montar a lista de quem pode consultar |
| Usuário de leitura nos concentradores | Ver de onde cada pool recebe o DNS e medir as consultas |
| Acesso administrativo às máquinas novas | Instalar e testar o software de DNS |
| Acesso ao DNS antigo, se houver | Medir o uso atual e planejar o desligamento |
| Painel de monitoramento existente | Ligar os gráficos do DNS ao que a equipe já olha |
| Janelas fora do pico | Trocar o endereço de cada pool com a equipe avisada |
Se o endereço do DNS vem do perfil do assinante no servidor de autenticação, a troca passa também pelo RADIUS, e esse acesso entra na lista. Na faixa do CGNAT, o guia sobre como funciona o CGNAT explica por que os assinantes consultam a partir de endereços 100.64.x.x.
Na prática: a configuração e os testes de cada servidor
A configuração cabe em poucas linhas, e os testes provam que ela faz o que promete. O exemplo abaixo usa Unbound e endereços de documentação.
# /etc/unbound/unbound.conf (trecho)
server:
interface: 198.51.100.53
interface: 2001:db8:53::53
access-control: 0.0.0.0/0 refuse
access-control: ::/0 refuse
access-control: 203.0.113.0/24 allow # bloco público do provedor
access-control: 100.64.0.0/10 allow # faixa do CGNAT
access-control: 2001:db8::/32 allow # bloco IPv6 do provedor
prefetch: yes
serve-expired: yes
ip-ratelimit: 200 # consultas por segundo por origem
msg-cache-size: 256m
rrset-cache-size: 512m
auto-trust-anchor-file: "/var/lib/unbound/root.key"
# De dentro da rede: deve responder NOERROR
dig @198.51.100.53 example.com
# Validação DNSSEC: a resposta deve trazer a flag "ad"
dig @198.51.100.53 example.com +dnssec
# De uma rede externa: deve voltar REFUSED
dig @198.51.100.53 example.com
# Acerto do cache depois da migração
unbound-control stats_noreset | grep -E "num.queries|num.cachehits"
Os tamanhos de cache e o limite por origem do exemplo são ilustrativos e saem da medição de cada rede. O teste de fora da rede é o que mais importa: um servidor aberto vira amplificador de ataque, e o guia de IP do provedor em blacklist mostra o que acontece depois.
Quer o DNS novo testado antes de qualquer cliente mudar?
Um Especialista mede o pico da sua base, instala os servidores em paralelo e entrega os testes de acesso, de validação e de carga antes da primeira migração.
O que muda o valor do projeto, como tamanho da base e ponto de partida, está explicado no guia sobre quanto custa implantação de DNS recursivo.
Exemplo: como funciona implantação de DNS recursivo num provedor com CGNAT
Um provedor hipotético entrega aos assinantes um DNS público de terceiros, tem dois concentradores e CGNAT em parte da base. O caminho até o DNS próprio segue as cinco etapas, sem queda.
- Medição: a leitura dos concentradores mostra os dois entregando o mesmo DNS de fora, e o tráfego na porta 53 dá o pico de consultas da noite.
- Desenho: dois servidores em máquinas físicas diferentes, com os endereços 198.51.100.53 e 198.51.100.54, liberando o bloco 203.0.113.0/24, a faixa do CGNAT e o IPv6.
- Paralelo: os servidores sobem, o cache é aquecido com consultas de teste e o teste feito de fora da rede volta recusado nos dois.
- Migração: o pool menor do primeiro concentrador recebe o DNS novo; com os números estáveis, seguem o restante dele e depois o segundo concentrador.
- Ajuste no caminho: os primeiros chamados mostram celulares ainda usando o DNS de fora pelo IPv6, e o anúncio do roteador passa a entregar o endereço 2001:db8:53::53.
- Entrega: o relatório compara o tempo de resposta antes e depois e traz a taxa de acerto do cache, a configuração comentada e o roteiro de atualização.
O ajuste do IPv6 é o tropeço mais frequente nesse tipo de troca. O guia de configuração de SLAAC mostra onde o endereço do DNS entra no anúncio do roteador, pela opção RDNSS.
O que a equipe recebe e quando pensar em redundância
A equipe recebe o DNS rodando, os números de antes e depois e a documentação para operar sozinha. A redundância entre POPs é o passo seguinte, quando o DNS já está estável.
- Relatório comparativo: tempo de resposta e acerto do cache medidos antes e depois da troca.
- Configuração comentada: cada linha explicada, com as faixas liberadas e o motivo de cada limite.
- Painel e alertas: consultas por segundo, erros por tipo e aviso quando um servidor para de responder.
- Roteiro de atualização: como aplicar uma versão nova do software um servidor por vez, sem parar a base.
Os gráficos podem ficar no sistema que o provedor já usa; o guia de implantação de Prometheus mostra uma forma de coletar esses números junto com o resto da rede.
Quando a implantação deve vir junto com a redundância?
Vale juntar os dois quando a rede tem mais de um POP e todo o DNS ficaria num só. Nesse caso, desenhar a redundância desde o começo evita uma segunda virada de endereço meses depois.
Em rede com um POP só, dois servidores em máquinas diferentes resolvem a maior parte do risco. O guia sobre como funciona alta disponibilidade de DNS mostra o passo seguinte, com anycast entre POPs.
Perguntas frequentes
O assinante precisa reiniciar o roteador para pegar o DNS novo?
Não precisa fazer nada de propósito. O endereço novo chega na próxima reconexão do PPPoE ou na renovação do DHCP, e é por isso que o DNS antigo fica ligado durante a migração.
Por quanto tempo o DNS antigo fica ligado depois da migração?
Até parar de receber consultas, o que a própria medição mostra. Equipamentos com DNS digitado à mão costumam ser os últimos, e vale avisar esses clientes antes do desligamento.
Dá para instalar o DNS recursivo em máquina virtual?
Dá, desde que os dois servidores fiquem em hospedeiros físicos diferentes e a máquina tenha memória para o cache desenhado. O que derruba o DNS virtual quase sempre é a disputa de recurso com outras máquinas no mesmo equipamento.
O DNS próprio guarda registro das consultas dos assinantes?
Só se for configurado para isso, e o volume de registro cresce rápido. O que guardar e por quanto tempo segue regras próprias de privacidade e de guarda de dados [CONFIRMAR na norma].
Como saber se o cache está funcionando depois da entrega?
Pela taxa de acerto do cache, que o painel mostra ao lado das consultas por segundo. Se ela cai no pico, o cache ficou pequeno para a base e precisa de mais memória.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 5358, Preventing Use of Recursive Nameservers in Reflector Attacks: recomenda que o servidor recursivo atenda só aos clientes da própria rede
- RFC 8767, Serving Stale Data to Improve DNS Resiliency: descreve a entrega de resposta vencida do cache quando o servidor do domínio não responde
- Documentação do Unbound (NLnet Labs): opções access-control, prefetch, serve-expired e ip-ratelimit usadas no exemplo
