DNS Recursivo Anycast Hyperlocal
Descrição
Um dos recursos extremamente importante para o acesso à Internet é o DNS (Domain Name System) e sem ele teríamos que decorar milhares de endereços IP para acessar sites e serviços na Internet. Basicamente temos 2 tipos de DNS, o recursivo e o autoritativo. O recursivo é um serviço que utilizamos para fazer consultas aos DNS(es) Autoritativos que são aqueles responsáveis pelas tabelas que associam o host name a um IP e no caso de resolução reversa, o IP ao host name. O exemplo mais comum de DNS reverso é o do Google, os IPs 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888 e 2001:4860:4860::8844. Se você está estranhando os 2 últimos endereços, é porque provavelmente ainda não ouviu falar de IPv6 e isso não é bom. Procure estudar sobre isso e um bom lugar para começar é aqui. O serviço de DNS deve ser levado muito a sério pelas empresas que o implementam, porque a sua falha pode literalmente parar a Internet para milhares de pessoas que confiam nele ou até pior, um DNS mal intencionado ou comprometido, pode ser usado para direcionar usuários a acessarem sites falsos. Esse artifício visa coletar as credenciais dos usuários e assim poderem aplicar golpes e outras formas danosas e prejudiciais à vítima. Ter um DNS recursivo é muito bom para o ISP, mas cuidar dele, mantê-lo atualizado e protegido, é mais importante ainda.
Nesse artigo mostrarei a configuração de um DNS recursivo anycast, diferente dos DNS recursivos unicast comumente encontrados pelos ISPs a fora. No modelo Unicast, normalmente se tem um ou mais servidores de DNS que são consultados e estão fisicamente em um local. O problema é que essa abordagem não poderia ter por exemplo, 5 servidores, e utilizar todos configurados ao mesmo tempo nos sistemas, porque muitos sistemas só aceitam até 3 servidores recursivos em suas configurações e mais que isso são ignorados. Você poderia então utilizar apenas 2 servidores, isso resolveria o problema mas eles precisariam estar em um determinado local. Mas e se lá na frente você resolver abrir seu negócio em uma outra cidade e em outro estado? Nesse caso poderia continuar usando os mesmos servidores mas aumentando um pouco a latência. Mas se acontecesse algo na interconexão desses servidores? Com o uso do DNS Anycast você poderia ter um servidor DNS recursivo em cada cidade e respondendo pelo mesmo IP. Em caso de problemas com qualquer servidor, o outro passaria a responder para todos os seus assinantes. Seria muito bom ter um cara como o "8.8.8.8" do Google, não é mesmo? Além desse recurso, usaremos o Hyperlocal que é uma técnica que faz uma cópia das tabelas dos DNS Root Servers e mantém localmente no seu servidor recursivo. Isso deixa rápida toda resposta que seria endereçada primeiramente aos DNS(es) Raiz da Internet, principalmente consultas de domínios inválidos ou digitados erradamente.
Diagrama
Para que possamos visualizar nossa configuração, abaixo temos um diagrama hipotético dos nossos servidores e da rede em si:
Explicando o cenário: cada servidor DNS fechará uma sessão iBGP com o seu router através dos endereços /30 IPv4 e /64 IPv6 (usando IPs de documentação RFC3849 e RFC5737 representando seus IPs públicos). Nessa sessão BGP serão anunciados os IPs privados RFC1918 e RFC4193 configurados nas loopbacks que serão: 10.10.10.10 e fc00::10:10:10:10. Divulgando esses IPs privados para os assinantes, você esconde o real IP público dos servidores, evitando que alguém de fora envie ataques para seus servidores DNS.
Servidores utilizados
- VM com 4 cores (Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz).
- 4Gb memória.
- 20Gb disco.
Softwares utilizados
Para instalação e configuração dos Servidores DNS Recursivos utilizaremos Software Livre, o que nos permite uma economia em licenças de sistemas fechados e proprietários. Abaixo a descrição deles:
- Debian Linux Buster (10.x).
- FRRouting 7.5.1.
- Unbound 1.9.0 (pacote da distribuição Debian). Obs.: essa versão do Unbound já possui suporte ao Hyperlocal nativo.
- IRQBalance (pacote do Debian).
- OpenNTPd.
- Shell script em bash, para checar se o DNS está OK e se não tiver retirar ele do anúncio.
Gráfico de utilização desse sistema em produção
Instalação e configuração do Servidor 1
Instale um sistema Debian 10 com o mínimo necessário, uma versão que costumo utilizar bastante é a que vem com firmwares e pode ser encontrado aqui. Atualmente está na versão 10.10, mas caso lancem uma versão mais recente, basta alterar o link. Não cobriremos a instalação do Debian, pois existem diversos vídeos no Youtube ensinando como proceder. Após a instalação faremos os ajustes na configuração para que possa então acomodar nosso serviço de DNS.
Instalação dos pacotes
FRR
Vamos configurar o repositório oficial do FRR e instalar os pacotes:
# echo "deb https://deb.frrouting.org/frr buster frr-stable" > /etc/apt/sources.list.d/frr.list # curl -s https://deb.frrouting.org/frr/keys.asc | sudo apt-key add - # apt update # apt install frr frr-doc frr-pythontools
Unbound
# apt install unbound
IRQBalance
# apt install irqbalance # systemctl enable irqbalance
OpenNTPd
# apt install openntpd Deixe o arquivo /etc/openntpd/ntpd.conf conforme abaixo e reinicie o serviço openntpd: # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ # sample ntpd configuration file, see ntpd.conf(5) # Addresses to listen on (ntpd does not listen by default) #listen on * #listen on 127.0.0.1 #listen on ::1 # sync to a single server #server ntp.example.org servers pool.ntp.br # use a random selection of NTP Pool Time Servers # see http://support.ntp.org/bin/view/Servers/NTPPoolServers #servers pool.ntp.org # Choose servers announced from Debian NTP Pool #servers 0.debian.pool.ntp.org #servers 1.debian.pool.ntp.org #servers 2.debian.pool.ntp.org #servers 3.debian.pool.ntp.org # use a specific local timedelta sensor (radio clock, etc) #sensor nmea0 # use all detected timedelta sensors #sensor *
Configurando a rede
/etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
auto lo:0
iface lo:0 inet static
address 10.10.10.10/32
iface lo:0 inet6 static
address fc00::10:10:10:10
netmask 128
# The primary network interface
auto ens160
iface ens160 inet static
address 192.0.2.2/30
gateway 192.0.2.1
iface ens160 inet6 static
address 2001:db8::192:0:2:2
netmask 64
gateway 2001:db8::192:0:2:1
Configurando o FRR e a sessão BGP com o router
Em /etc/frr/daemons modifique o valor bgpd=no para bgpd=yes, dessa forma habilitaremos o BGP no FRR. Feito isso precisaremos reiniciar o serviço frr:
# systemctl restart frr.service
Nosso arquivo /etc/frr/frr.conf ficará assim:
frr version 7.5 frr defaults traditional hostname unbound2 log syslog informational no ip forwarding no ipv6 forwarding service integrated-vtysh-config ! router bgp 65000 bgp router-id 192.0.2.2 no bgp ebgp-requires-policy no bgp network import-check neighbor 192.0.2.1 remote-as 65000 neighbor 2001:db8::192:0:2:1 remote-as 53135 ! address-family ipv4 unicast network 10.10.10.10/32 neighbor 192.0.2.1 prefix-list BLOQUEIA-TUDO in neighbor 192.0.2.1 prefix-list RECURSIVO out exit-address-family ! address-family ipv6 unicast network fc00::10:10:10:10/128 neighbor 2001:db8::192:0:2:1 activate neighbor 2001:db8::192:0:2:1 prefix-list BLOQUEIA-TUDO_V6 in neighbor 2001:db8::192:0:2:1 prefix-list RECURSIVO_V6 out exit-address-family ! ip prefix-list BLOQUEIA-TUDO seq 5 deny any ip prefix-list RECURSIVO seq 5 permit 10.10.10.10/32 ! ipv6 prefix-list BLOQUEIA-TUDO_V6 seq 5 deny any ipv6 prefix-list RECURSIVO_V6 seq 5 permit fc00::10:10:10:10/128 ! line vty !