Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

Tutorial DNS Hyperlocal

2019-08-22T15:10:21Z

Fabio Julian Ortlieb:

=== 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 [https://root-servers.org/ 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 [[rfc:7706/|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 <nowiki>RFC 7706</nowiki> 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:
<pre>
yum install bind bind-utils
</pre>

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.
<pre>
view root {
<nowiki>#</nowiki> 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
   };
   };
};
</pre>

Obs: Os servidores utilizados devem permitir transferência de zona (axfr), como nem todos os root server permitem o axfr, sendo assim deve ser verificada na versão atual da RFC no link a seguir <nowiki>https://tools.ietf.org/html/rfc7706</nowiki> os root servers que estão preparados para a sincronização do Hyperlocal.

O processo de atualização acontece uma vez ao dia, e ela requer que seja baixada toda a zona raiz que atualmente chega a ~1.5Mb.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

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.
<pre>
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 {
<nowiki>#</nowiki> 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 {
<nowiki>#</nowiki> 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;
<nowiki>#</nowiki> 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; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback.

};
};
</pre>

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.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É 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.

[[Categoria:Infraestrutura]]
[[Categoria:DNS]]

Tutorial DNS Hyperlocal

2019-08-21T19:57:26Z

Fabio Julian Ortlieb:

=== 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 [https://root-servers.org/ 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 [[rfc:7706/|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 <nowiki>RFC 7706</nowiki> 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:
<pre>
yum install bind bind-utils
</pre>

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.
<pre>
view root {
<nowiki>#</nowiki> 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
   };
   };
};
</pre>

Obs.: Os servidores utilizados como sendo as atuais fonte de replicação da zona raiz neste exemplo são os que estavam especificados na <nowiki>https://tools.ietf.org/html/rfc7706</nowiki>, na data da publicação deste artigo.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

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.
<pre>
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 {
<nowiki>#</nowiki> 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 {
<nowiki>#</nowiki> 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;
<nowiki>#</nowiki> Esta é parte aonde instruímos o Bind sobre os servidores serem utilizado para consulta de zona Raiz.
zone "." {
type static-stub;
server-addresses { 127.0.0.1; ::1; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback.

};
};
</pre>

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 um 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.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É 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.

[[Categoria:Infraestrutura]]
[[Categoria:DNS]]

Tutorial DNS Hyperlocal

2019-08-21T19:50:32Z

Fabio Julian Ortlieb:

=== 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 [https://root-servers.org/ 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 [[rfc:7706/|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 <nowiki>RFC 7706</nowiki> 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:
<pre>
yum install bind bind-utils
</pre>

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.
<pre>
view root {
<nowiki>#</nowiki> 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
   };
   };
};
</pre>

Obs.: Os servidores utilizados como sendo as atuais fonte de replicação da zona raiz neste exemplo são os que estavam especificados na <nowiki>https://tools.ietf.org/html/rfc7706</nowiki>, na data da publicação deste artigo.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

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.
<pre>
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 {
<nowiki>#</nowiki> 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 {
<nowiki>#</nowiki> 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;
<nowiki>#</nowiki> Esta é parte aonde instruímos o Bind sobre os servidores serem utilizado para consulta de zona Raiz.
zone "." {
type static-stub;
server-addresses { 127.0.0.1; ::1; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback.

};
};
</pre>

Com essa configuração é possível já sentir os benefícios do Hyperlocal em sua rede, no exemplo acima, os endereços 172.16.1.1 e 172.16.1.2 são servidores recursivos externos rodando Unbound, para completar a configuração adicione ao Unbound a seguinte configuração 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.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É 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.

[[Categoria:Infraestrutura]]
[[Categoria:DNS]]

Tutorial DNS Hyperlocal

2019-08-21T19:42:46Z

Fabio Julian Ortlieb:

=== 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 [https://root-servers.org/ 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 [[rfc:7706/|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 <nowiki>RFC 7706</nowiki> 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:
<pre>
yum install bind bind-utils
</pre>

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.
<pre>
view root {
<nowiki>#</nowiki> 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
   };
   };
};
</pre>

Obs.: Os servidores utilizados como sendo as atuais fonte de replicação da zona raiz neste exemplo são os que estavam especificados na <nowiki>https://tools.ietf.org/html/rfc7706</nowiki>, na data da publicação deste artigo.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

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.
<pre>
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 {
<nowiki>#</nowiki> 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 {
<nowiki>#</nowiki> 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;
<nowiki>#</nowiki> Esta é parte aonde instruímos o Bind sobre os servidores serem utilizado para consulta de zona Raiz.
zone "." {
type static-stub;
server-addresses { 127.0.0.1; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback.

};
};
</pre>

Com essa configuração é possível já sentir os benefícios do Hyperlocal em sua rede, no exemplo acima, os endereços 172.16.1.1 e 172.16.1.2 são servidores recursivos externos rodando Unbound, para completar a configuração adicione ao Unbound a seguinte configuração para que ele consulte o Hyperlocal:
<pre>
stub-zone:
name: "."
stub-prime: no
stub-addr: 198.51.100.1
</pre>

=== 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.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É 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.

[[Categoria:Infraestrutura]]
[[Categoria:DNS]]

Tutorial DNS Hyperlocal

2019-08-21T17:10:07Z

Fabio Julian Ortlieb: Melhorias na descrição do tutorial

=== 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 [https://root-servers.org/ 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 [[rfc:7706/|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 <nowiki>RFC 7706</nowiki> 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:
<pre>
yum install bind bind-utils
</pre>

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.
<pre>
view root {
<nowiki>#</nowiki> 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
   };
   };
};
</pre>

Obs.: Os servidores utilizados como sendo as atuais fonte de replicação da zona raiz neste exemplo são os que estavam especificados na <nowiki>https://tools.ietf.org/html/rfc7706</nowiki>, na data da publicação deste artigo.

Iniciando o serviço do Bind você pode conferir a criação da base com o comando:
<pre>
ls /var/named/rootzone.db
</pre>

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.
<pre>
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::/64;
};

acl "ServidorRecursivo_A" {
203.0.113.10;
2001:db8::10;
};

acl "ServidorRecursivo_B" {
203.0.113.20;
2001:db8::20;
};

view root {
<nowiki>#</nowiki> 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 {
<nowiki>#</nowiki> 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;
<nowiki>#</nowiki> Esta é parte aonde instruímos o Bind sobre os servidores serem utilizado para consulta de zona Raiz.
zone "." {
type static-stub;
server-addresses { 127.0.0.1; };
<nowiki>#</nowiki> Aqui definimos o IP do servidor Hyperlocal aonde serão feitas as consultas recursivas da zona Raiz.
<nowiki>#</nowiki> Como neste exemplo o Hyperlocal roda neste mesmo servidor, especificamos o endereço de loopback.

};
};
</pre>

Com essa configuração é possível já sentir os benefícios do Hyperlocal em sua rede, no exemplo acima, os endereços 172.16.1.1 e 172.16.1.2 são servidores recursivos externos rodando Unbound, para completar a configuração adicione ao Unbound a seguinte configuração para que ele consulte o Hyperlocal:
<pre>
stub-zone:
name: "."
stub-prime: no
stub-addr: 198.51.100.1
</pre>

=== 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.
<pre>
// Teste 1 servidor público Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 29 msec

// Teste 2 servidor publico Google
dig @8.8.8.8 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 27 msec

// Teste 1 no Unbound recursivo sem o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 21 msec

// Teste 2 (cached) no Unbound recursivo sem o hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 2 (cached) direto no Hyperlocal
dig @192.168.0.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec

// Teste 1 no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 2 msec

// Teste 2 (cached) no Unbound recursivo apontando para o Hyperlocal
dig @172.16.1.1 domaininvalid.com.br.xxxxxxx
<nowiki>;;</nowiki> Query time<nowiki>:</nowiki> 0 msec
</pre>

É possível portanto visualizar o melhor desempenho quando feitas consultas utilizando o Hyperlocal, sendo essa uma ótima implementação para manter no provedor.
[[Categoria:Infraestrutura]]
[[Categoria:DNS]]