Tutorial DNS Hyperlocal
Introdução
A Zona Raiz do Sistema de Nomes de Domínios (DNS) é servida por 12 organizações que operam instâncias anycast de servidores de nomes autoritativos provendo respostas para a raiz do DNS. Estas instâncias estão distribuídas em mais de 1000 localidades ao redor do mundo. Apesar deste grande número de servidores e alta capacidade provisionada para a resolução da raiz de nomes, ainda existe a possibilidade de que um grande ataque coordenado de negação de serviço (DDoS) possa comprometer o acesso à internet para muitos usuários.
Para minimizar e prevenir esta ameaça, existe a possibilidade de adicionar um fator de resiliência na configuração dos servidores recursivos do provedor de internet através do uso de uma cópia local da zona raiz, chamada de Hyperlocal. Hyperlocal é apresentado em detalhes na RFC7706 e, resumidamente, consiste em executar uma cópia da zona raiz no mesmo servidor de serviços de resolução recursiva. Desta forma, as consultas à zona raiz dos clientes são respondidas localmente sem necessidade comunicação externa entre os servidores. Isso resulta em maior robustez do serviço em caso de ataques e ganhos na velocidade de provimento de respostas às consultas ao DNS dos usuários.
Este tutorial foi criado para compartilhar a prática de implementação de um sistema Hyperlocal para a configuração de servidores de DNS do tipo BIND9. Outras configurações e softwares mencionados na RFC 7706 não são abordados neste tutorial.
Implementação - CentOS
Requisitos para instalação do Hyperlocal:
- Instalação básica CentOS Linux 7
- 1vCPU
- 1GB de RAM
- 20GB de Disco
Baixe o ISO do Sistema Operacional no link http://isoredirect.centos.org/centos/7/isos/x86_64/
Sistema operacional instalado e atualizado, agora devemos instalar o Bind9 com o comando:
yum install bind bind-utils
A configuração para o funcionamento da zona raiz é bem simples como podemos ver abaixo.
Os arquivos de configuração do Bind no Centos7 por padrão estão no arquivo /etc/named.conf.
No exemplo de configuração abaixo, o servidor Hyperlocal foi configurado com o IPv4 198.51.100.1 e IPv6 2001:db8::1 em sua interface de rede.
view root { # IPs das interfaces onde chegarão as requisições para cópia loca da zona raiz match-destinations { 198.51.100.1; 2001:db8::1; }; zone "." { type slave; file "rootzone.db"; notify no; masters { 192.228.79.201; # b.root-servers.net 192.33.4.12; # c.root-servers.net 192.5.5.241; # f.root-servers.net 192.112.36.4; # g.root-servers.net 193.0.14.129; # k.root-servers.net 192.0.47.132; # xfr.cjr.dns.icann.org 192.0.32.132; # xfr.lax.dns.icann.org 2001:500:84::b; # b.root-servers.net 2001:500:2f::f; # f.root-servers.net 2001:7fd::1; # k.root-servers.net 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 2620:0:2d0:202::132; # xfr.lax.dns.icann.org }; }; };
Obs: Os servidores utilizados como sendo as atuais fontes de replicação da zona raiz neste exemplo são os que estavam especificados na https://tools.ietf.org/html/rfc7706, na data da publicação deste artigo.
Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
ls /var/named/rootzone.db
Segue abaixo um exemplo de arquivo de configuração para o BIND já contendo as configurações de Hyperlocal e de recursividade .
É possível melhorar de diversas formas esse exemplo de configuração.
O configuração padrão do Bind com o adicional de views no exemplo seguinte já é bem funcional.
options { listen-on port 53 { any; }; listen-on-v6 port 53 { any; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; }; logging { channel default_debug { file "data/named.run"; severity dynamic; }; }; acl "MinhaRede_v4" { 127.0.0.0/8; 198.51.100.0/24; }; acl "MinhaRede_v6" { ::1; 2001:db8::/32; }; acl "ServidorRecursivo_A" { 203.0.113.10; 2001:db8::10; }; acl "ServidorRecursivo_B" { 203.0.113.20; 2001:db8::20; }; view root { # Como exemplo, especificamos abaixo os dois servidores recursivos autorizados a fazer consulta na copia local de zona Raiz match-clients { 127.0.0.1; ServidorRecursivo_A; ServidorRecursivo_B; } ; zone "." { type slave; file "rootzone.db"; notify no; masters { 192.228.79.201; # b.root-servers.net 192.33.4.12; # c.root-servers.net 192.5.5.241; # f.root-servers.net 192.112.36.4; # g.root-servers.net 193.0.14.129; # k.root-servers.net 192.0.47.132; # xfr.cjr.dns.icann.org 192.0.32.132; # xfr.lax.dns.icann.org 2001:500:84::b; # b.root-servers.net 2001:500:2f::f; # f.root-servers.net 2001:7fd::1; # k.root-servers.net 2620:0:2830:202::132; # xfr.cjr.dns.icann.org 2620:0:2d0:202::132; # xfr.lax.dns.icann.org }; }; }; view "externa" { match-clients { any; }; recursion no; }; view clientes-recursivos { # Esta é a view que permite que clientes façam consultas recursivas a este servidor dnssec-validation auto; allow-recursion { MinhaRede_v4; MinhaRede_v6; }; recursion yes; # Esta é parte aonde instruímos o Bind sobre os servidores a serem utilizados para consulta de zona Raiz. zone "." { type static-stub; server-addresses { 127.0.0.1; ::1; }; # Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz. # Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback. }; };
Com essa configuração é possível já sentir os benefícios do Hyperlocal em sua rede, no exemplo acima, configuramos o Hyperlocal e o servidor recursivo na mesma instancia do Bind, para usuários do Unbound é possível fazer a consulta em uma instância Hyperlocal Bind com um pequeno ajuste na configuração, adicione ao final do arquivo de configuração do "unbound.conf" o seguinte trecho para que ele consulte o Hyperlocal:
stub-zone: name: "." stub-prime: no stub-addr: 198.51.100.1 stub-addr: 2001:db8::1
Conclusão
Em testes o desempenho ficou muito bom. Abaixo algumas comparações consultando domínios inválidos para forçar o recursivo a procurar nos Root Servers.
// Teste 1 servidor público Google dig @8.8.8.8 domaininvalid.com.br.xxxxxxx ;; Query time: 29 msec // Teste 2 servidor publico Google dig @8.8.8.8 domaininvalid.com.br.xxxxxxx ;; Query time: 27 msec // Teste 1 no Unbound recursivo sem o Hyperlocal dig @172.16.1.1 domaininvalid.com.br.xxxxxxx ;; Query time: 21 msec // Teste 2 (cached) no Unbound recursivo sem o hyperlocal dig @172.16.1.1 domaininvalid.com.br.xxxxxxx ;; Query time: 0 msec // Teste 1 direto no Hyperlocal dig @192.168.0.1 domaininvalid.com.br.xxxxxxx ;; Query time: 0 msec // Teste 2 (cached) direto no Hyperlocal dig @192.168.0.1 domaininvalid.com.br.xxxxxxx ;; Query time: 0 msec // Teste 1 no Unbound recursivo apontando para o Hyperlocal dig @172.16.1.1 domaininvalid.com.br.xxxxxxx ;; Query time: 2 msec // Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal dig @172.16.1.1 domaininvalid.com.br.xxxxxxx ;; Query time: 0 msec
É possível portanto visualizar o melhor desempenho quando feitas consultas utilizando o Hyperlocal, sendo essa uma ótima implementação para manter no provedor.
É importante lembrar que em caso haver somente um Hyperlocal na rede, o recomendado é deixar somente o servidor primário apontando para o mesmo afim de evitar ponto único de falha, ou fazer dupla implementação um para cada servidor recursivo.